Problèmes

Quelques problèmes que nous avons rencontrés sont suffisamment notables pour qu'il soit nécessaire de modifier l'approche simple présentée ci-dessus.

L'un des problèmes vient de que certains agents (par exemple Exim) tentent de limiter les fausses adresses d'émission par un contrôle de la validité de l'adresse. Ce contrôle se fait par le biais d'un rappel (au sens SMTP) vers l'adresse d'émission. Notre objectif étant de minimiser le trafic, la meilleure option est de déclencher les rejets dès la commande RCPT. Cependant, un tel rejet exécuté pour un rappel SMTP provoquerait des délais inutiles dans l'acheminement du message initial.

Cela dit, la majorité des systèmes qui mettent en place cette vérification de l'adresse de l'émetteur utilisent, dans leur message de rappel, l'émetteur nul . La solution est simple, puisque nous pouvons modifier le traitement, dans le cas d'un tel émetteur nul, pour ne renvoyer de rejet temporaire qu'après la phase DATA. Or, lors d'un rappel SMTP, l'agent émetteur du rappel met un terme à la transaction SMTP avant d'arriver à cette phase DATA. Du point du vue de l'agent qui procède au rappel, ce dernier s'est bien déroulé. De notre point de vue, notre message sortant peut être accepté sans délais inutiles.

Postfix est un autre agent présentant des difficultés semblables. Ce dernier s'éloigne des procédures habituelles d'utilisation de l'émetteur nul pour les rappels SMTP, et utilise à la place une adresse modifiable. J'ai cherché une explication à ce comportement, et ai appris que cela vient de certains agents non-conformes qui rejettent l'émetteur nul quand bien même il est requis par les RFC traitant de SMTP.

Malheureusement, cela pose un problème d'adaptation à ce comportement de Postfix. Par chance, la valeur par défaut de l'émetteur utilisé dans ce cas semble être postmaster, ce qui permet de définir une solution adéquate.

Un autre problème apparaît avec les sites disposant de plusieurs serveurs d'émission, lorsqu'ils envoient un message vers un serveur utilisant le Greylisting. Si le groupe de serveurs est configuré afin que le même système (même adresse IP) fasse les réémissions lors du rejet temporaire d'un message, il n'y a aucune difficulté.

Mais si les serveurs sont configurés de telle manière que l'un quelconque d'entre eux peut réémettre un message qui a été rejeté temporairement, alors les acheminements de messages à destination d'un système utilisant le Greylisting peuvent souffrir de délais particulièrement élevés. Le délai maximal dépend du nombre de serveurs dans le groupe d'émission, et de la gestion des tentatives de réémission. Dans le pire scénario, le délai peut être tel que l'émission du message sera abandonnée.

La première solution à ce problème est de placer ces serveurs en liste blanche. Une autre solution est de contrôler le sous-réseau de l'adresse IP de l'émetteur plutôt que l'adresse IP exacte. La majorité des sites concernés ayant tous leurs serveurs sur le même sous-réseau (/24), cette méthode est relativement efficace et automatique. Malheureusement, elle facilite un peu la vie des spammeurs.

Un autre problème potentiel vient des listes de diffusion se servant d'adresses d'émission uniques pour les messages envoyés à un certain utilisateur. Cela permet de mieux gérer les erreurs et les rejets (dont le format n'est pas normalisé, rendant la détermination de l'adresse en erreur particulièrement difficile).

Cette gestion des rejets et erreurs est appelée VERP, pour Variable Envelope Return Paths (adresses de retour variables). La majorité des listes de diffusion met le VERP en oeuvre d'une manière proche de celle décrite dans ce document, et utilise la même adresse d'émission pour tous les messages envoyés à un utilisateur particulier.

Certains gestionnaires de listes (comme Ezmlm) tentent d'aller plus loin et de garder unitairement trace des messages rejetés, plutôt que de manière globale pour un même destinataire. Il s'agit d'une variante de la méthode VERP, chaque message émis par la liste ayant une adresse d'émission unique. Chaque message émis par ces outils sera retardé, puisque le système récepteur ne trouvera jamais un triplet portant la même adresse d'émetteur, par nature unique.

S'il peut sembler a priori intéressant de garder une trace des rejets individuels de messages, cette idée ne paraît pas très pertinente aujourd'hui, où l'on essaye d'authentifier les émetteurs. Nous espérons que les mainteneurs d'Ezmlm corrigeront ce point.

Il existe une solution manuelle, qui est de placer en liste blanche tous les systèmes qui génèrent ce type de trafic. Toutefois, même sans une telle configuration, l'impact reste faible. Les listes de diffusion sont rarement utilisées pour des messages urgents, et le délai reste acceptable par la majorité des utilisateurs.