Configuration des serveurs de messagerie et filtrage des destinataires

Quel paramétrage mettre en place pour gérer la réception d’emails provenant d’utilisateurs inexistants ? Deux options sont aujourd’hui généralement possibles pour traiter les cas des utilisateurs inexistants sur un serveur de messagerie.

La première option, que l’on nommera « bounce », était historiquement celle proposée par défaut par tous les serveurs de messagerie. Lors de la communication entre serveur émetteur et serveur destinataire, le message est systématiquement accepté par le serveur destinataire, pour être traité dans un second temps. La vérification du destinataire se faisant a posteriori, en cas d’échec de délivrance du mail, le serveur doit créer et envoyer un email appelé bounce ayant pour but d’informer l’émetteur du message d’origine que son email n’a pu aboutir.

La seconde option est l’analyse dans le protocole pour le filtrage des destinataires. Durant la phase d’émission d’email, le serveur destinataire indique directement au serveur émetteur que le destinataire n’existe pas. Pour cela, lors de la transaction SMTP, après le RCPT TO, il envoie simplement un code de refus type 500. Dans ce cas, c’est le serveur émetteur qui s’occupe directement d’informer son utilisateur que le message n’a pu être délivré.

Un grand nombre d’arguments existent en faveur du second paramétrage, nous allons en dresser une liste, certainement non exhaustive.

1. Dans le cas du bounce, le fait d’accepter tout email pour le traiter seulement dans un second temps sature le serveur de messagerie du client inutilement. En effet, dans ce cas, il faut traiter et stocker le mail entrant, mais, de plus, le serveur de messagerie doit utiliser des ressources machines supplémentaires pour générer le bounce. Pour un mail erroné reçu, le serveur doit consommer deux fois plus de ressources que pour un email classique !

2. Certainement à cause de la recrudescence du nombre de spams, les bounces sont de plus en plus considérés comme du spam. Il s’agit, tout comme les spams, de messages non sollicités. D’autant plus qu’il est courant de recevoir des bounces concernant des emails dont nous ne sommes pas à l’origine, tout simplement parce qu’un spammeur a utilisé notre adresse email pour envoyer des spams. Comme de plus en plus de logiciels antispam refusent ces emails, l’expéditeur n’est finalement jamais informé que son message n’a pas abouti.

3. Pour chaque adresse erronée, un bounce est envoyé. Le serveur de messagerie génère donc un flux d’email inutile. On se plaint que désormais plus de 80% du flux de messagerie mondial est constitué de spams, la proportion de bounces n’est pas négligeable.

4. Comme précisé plus haut, certains spammeurs utilisent des adresses de messagerie usurpées à des tiers pour envoyer leurs spams. C’est pourquoi des utilisateurs se retrouvent, quelquefois, inondés par des bounces alors qu’ils ne sont pas à l’origine du message initial. Il arrive que certaines personnes se retrouvent ainsi réellement bombardées et saturées d’emails dont elles n’ont que faire.

5. Pire encore, ces bounces peuvent très bien être renvoyés à des faux émetteurs étant en réalité des spamtraps de blacklists. Un grand nombre de blacklists notoires utilise des spamtraps pour générer leurs listes d’adresses. Dans ce cas, ces spamtraps reçoivent depuis l’IP de votre serveur de messagerie un grand nombre d’emails. C’est pourquoi très rapidement votre serveur de messagerie pourrait se retrouver blacklisté.

Inversement, le seul argument avancé pour conserver la configuration de type bounce consiste à dire qu’il serait facile pour une personne mal intentionnée de reconstituer la liste des adresses emails actives dans l’entreprise, en essayant, par « brut-force », toutes les combinaisons possibles. Cependant, c’est oublier que cela reste également possible en mode bounce, il suffit alors d’analyser les emails retournés en erreur, les bounces ! Les adresses pour lesquelles on ne reçoit pas de bounces sont des adresses valides. Il est ainsi aisé de constituer une liste d’adresses valides.

Comme précisé ci-dessus, auparavant la plupart des serveurs de messagerie étaient configurés pour faire du bounce, car il n’y avait pas trop de trafic et surtout il n’y avait pas ou peu de spams. Aujourd’hui, tous les principaux éditeurs de logiciels de messagerie sont revenus sur cette configuration et intègrent en standard notre seconde option, l’analyse du destinataire à la volée dans le protocole SMTP. Sous Lotus, le paramétrage associé à cette configuration est nommé : « Vérifier que les destinataires de domaine local existent dans l’annuaire Domino », sous Exchange il s’agit de : « Filtrage des destinataires » et sous MDeamon de : « Refuser le courrier destiné à des utilisateurs locaux inconnus ».

Si vous êtes postmaster, nous vous invitons à tout faire afin d’éviter un paramétrage de votre serveur en mode bounce. Pour vérifier simplement la configuration de votre serveur, utilisez notre outil en ligne présent à l’adresse : https://www.altospam.com/outil/ et effectuez une analyse sur une adresse invalide (par exemple: cetteadressenexistepas@votredomaine.com ). Si le retour génère un code 500 après le RCPT TO, votre serveur effectue bien l’analyse du destinataire pendant la transaction SMTP.

Attention cependant, ce n’est pas parce qu’un serveur accepte des emails à destination de tous les utilisateurs qu’il est forcément configuré en bounce, il peut également s’agir de l’utilisation de ‘CATCH-ALL’. Cette fonctionnalité implémentée sur certains serveurs permet de spécifier une adresse email servant de réceptacle pour tous les emails d’un domaine donné. Si c’est le cas, nous déconseillons d’utiliser ce type de configuration.

MAJ du 24/01/2012: Voici les pages de deux blacklistes spécifiques identifiant les serveurs légitimes expéditeurs de bounces, sur lesquels ils expliquent pourquoi le bounce est à éviter :
http://www.backscatterer.org/?target=bounces
http://www.spamcop.net/fom-serve/cache/329.html