Nous avons effectué en fin de semaine dernière une modification
importante sur l’infrastructure de messagerie, elle fait
suite à  l’article suivant sur notre blog.

Les règles de filtrage ayant été allégées, le volume de
mails/spams à  traiter a quasiment doublé. Bien que mise en
production en janvier 2008, la baie de disques sur lesquels sont
physiquement stockés vos emails est arrivée en limite de capacité
d’écriture.

Nous avions planifié son remplacement par une baie
Hewlett-Packard plus puissante et équipée de disques SAS.
L’opération était prévue dans les nuits du week-end du 24 et 25 mai,
mais la situation se dégradant, nous avons dû intervenir plus vite dès
jeudi 22 mai.

Les comptes ont été transférés vers la nouvelle architecture, les
services ont été basculés sur la nouvelle baie puis tous les e-mails
présents dans les boîtes ont été récupérés et réinjectés. Les e-mails
arrivant ont été progressivement réacheminés.

L’opération est terminée, la situation est à  ce jour normale.

Vous aurez certainement constaté que ce changement a eut un effet
positif sur la vitesse d’accès à  vos emails via le protocole
IMAP, la lecture des mails contenus sur un compte étant
beaucoup plus rapide.

Nous reprenons donc actuellement le cours normal de notre opération, à 
savoir :

- Travail sur les règles Antispam : l’objectif est
de remplacer Bitdefender par Spamassassin afin de gagner en souplesse
d’utilisation. Vous pourrez ainsi notamment personnaliser vos règles de
filtrage, et ce par domaine,

- Mise en place d’un nouveau Webmail, plus
ergonomique et comportant de nouvelles fonctionnalités souvent réclamées
sur le support (partage d’agenda, synchronisation des contacts avec
Outlook, calendrier…),

- Modifications des zones mails ; elles devront en
effet être activées depuis l’interface client. Cette modification peut
paraître mineure mais elle a cependant son importance ; de fait aucun
mail ne pourra être envoyé sur un domaine non activé. Notre système ne
traitera ainsi plus de spams envoyé vers des zones non utilisées.

Nous avons mis en place un antivirus sur les fichiers webs de vos sites, ce dernier analyse après la sauvegarde le contenu de votre site il y a quelques semaines, un email est généré si des fichiers frauduleux sont détectés.

Le système fonctionne dans l’ensemble assez bien mais a butté cette nuit sur au moins deux CMS (Joomla et Wordpress), pour lesquels certains fichiers Javascripts ont été identifiés comme hackés alors que de toute évidence tel n’est pas le cas.

Nous travaillons sur le sujet, si vous avez reçu un mail cette nuit n’en tenez pas compte, merci

Le virus détecté est Trojan.JS.Downloader-1.

Edit : Dotclear est également concerné.

Edit du 24/05/2008 : Le problème est corrigé, nous avons placé des filtres sur l’analyse des fichiers.

Depuis fin 2007 nous avons apporté énormément de modifications à  nos plateformes messagerie mutualisées afin d’en assurer le bon fonctionnement :

- ajout de serveurs MX (réception des mails et traitement antispam et antivirale),
- ajout de serveurs de traitement (serveur mettant physiquement un mail reçu dans votre boite aux lettres),
- changement de la baie de disques stockant les mails afin de permettre un plus grand nombre d’écritures,
- remplacement du serveur Imap par un plus puissant,
- modification des règles de filtrage.

Le résultat obtenu est très satisfaisant, moins de spams, aucun retard dans la réception, pas de plantage de l’imap (si ce n’est dimanche matin pour me faire mentir).

Aujourd’hui nous sommes face à  une situation que je trouve personnellement regrettable liée au fait que nous respections la RFC 2821 (bonne lecture !).

Lorsque deux serveurs de messagerie communiquent, le serveur expéditeur annonce son nom via la commande EHLO. Par exemple smtp.messagerie.com, le serveur réceptionnant la demande vérifie alors que ce nom existe sur internet, si oui le mail est accepté, si non, le mail est refusé.

Cette règle nous l’avons mise en place, le résultat a été extrêmement positif puisqu’il mettait les infrastructures de messagerie de Celeonet à  l’abri des attaques de spams.

Aujourd’hui nous faisons marche arrière, pourquoi ? Tout simplement car certains serveurs expéditeurs de mails disposent de bannière EHLO fausses, toto.local, messagerie.serveur etc… Conclusion intermédiaire, de toute évidence lorsqu’on administre un serveur exchange on ne se sent pas obligé de le configurer proprement, enfin bon.

Si dans la plupart des cas les administrateurs que nous avons contacté ont fait les modifications nécessaires pour respecter la RFC 2821, d’autres n’en ont très clairement rien à  faire.

Nous nous trouvons donc dans une situation o๠nous devons nous justifier de respecter les RFC auprès de certains de nos clients, c’est aberrant.

Soyons réalistes, nous n’avons pas le poids d’un Orange ou d’un Free pour faire le forcing sur le respect des RFCs, nous faisons donc à  ce jour marche arrière sur ce point de configuration.

Spammeurs vous venez de gagner une bataille mais pas la guerre.