Inconvénients de la méthode

La tactique du retard, qui est au coeur du Greylisting, peut provoquer des délais indésirables si le serveur sur lequel ces outils sont utilisés accepte des messages de clients dont l'adresse IP change souvent. Ainsi, si des clients provenant d'autres réseaux peuvent relayer des messages sur un serveur, par exemple après une authentificaiton POP ou IMAP, nos outils ne permettent pas un acheminement rapide de ces messages.

Il existe des solutions à ce problème, mais elles ne sont pas mises en oeuvre dans le code d'exemple fourni. A la base, il suffit, en même temps que l'on autorise le relayage, d'injecter dans la base de données du Greylisting un enregistrement (avec une faible durée de vie) indiquant l'adresse IP du client. Ce dernier pourra alors émettre, pendant la durée de vie de cet enregistrement, ses messages sans délais inutiles.

La réception de messages provenant de systèmes qui ne gèrent pas correctement les rejets temporaires, ou qui ne ré-émettent jamais les messages, est plus problématique. On peut simplement espérer que les outils qui présentent ce genre de dysfonctionnements seront corrigés lorsque le Greylisting commencera à être utilisé par beaucoup de sites.

Malheureusement, nos tests ont détecté plusieurs systèmes de ce genre. Ils respectent très mal les RFCs concernant SMTP, quant ils ne les ignorent pas totalement. SMTP étant, par nature, une méthode de transport non-fiable, les systèmes incapables de réémettre des messages devraient être corrigés.

Voici une session SMTP provenant d'un tel système :

-> HELO undomaine.com
<- 250="" hello="" br="">-> MAIL FROM: 
<- 250="" 2="" 1="" 0="" sender="" ok="" br="">-> RCPT TO: 
<- 451="" 4="" 7="" 1="" please="" try="" again="" later="" br="">-> DATA
<- 551="" no="" valid="" recipients="" br="">

Il est clair que le système émetteur n'a pas contrôlé le retour de sa commande RCPT, et a poursuivi par la commande DATA. Cette dernière provoque un rejet définitif du message. Dans le cas précis de ce serveur, il traite correctement le code 551, qui est considéré comme une erreur "permanente". Le message a été renvoyé à son émetteur avec l'erreur idoine. Ce comportement n'est pas correct, puisqu'il faudrait tenir compte de l'erreur "temporaire" qui a précédé, et mettre un terme à la transaction à ce moment.