Mon blog

Ce RFC enregistre officiellement deux nouveaux codes de retour SMTP (qui étaient déjà largement utilisés), 521 (« I do not accept mail ») et 556 (« The remote domain does not accept mail »). Tous les deux sont prévus pour le cas où un serveur ou un domaine n'acceptent jamais de courrier, en aucune circonstance (par opposition aux codes de rejet plus généraux comme 554).

Petit rappel au passage : les codes de retour SMTP, spécifiés dans la section 4.2 du RFC 5321, ont un premier chiffre qui indique notamment si l'erreur est temporaire (si le premier chiffre est un 4) ou permanente (si le premier chiffre est un 5). Dans le second cas, pas la peine de réessayer plus tard. Ici, le 521 dit bien « ne t'embête pas à revenir, demain, ce sera comme aujourd'hui, je n'accepterai jamais ton message »).

SMTP avait été prévu au début dans un monde où tout le monde acceptait du courrier. Dans les années 1980, toute station de travail Unix venait avec un sendmail activé qui pouvait recevoir des messages. Le paysage aujourd'hui est très différent (section 2 de notre RFC) avec un grand nombre de machines qui ne reçoivent pas de courrier. De même, certains domaines ne sont pas utilisés pour le courrier et il serait pratique de pouvoir indiquer cela à l'avance (RFC 7505).

Dans le premier cas (machine qui ne veut pas recevoir de courrier), le plus simple semble être de ne pas avoir de serveur SMTP du tout. Mais l'impossibilité de se connecter (réponse TCP RST, ou bien timeout, si le pare-feu jette les requêtes TCP) va être interprétée par le client SMTP comme temporaire, et celui-ci va alors réessayer pendant des jours. Si, par la suite d'une erreur de configuration, un client SMTP tente de se connecter à une machine sans serveur, il faudra donc attendre avant de détecter le problème. Avoir un simple serveur SMTP qui ne fait rien d'autre que dire tout de suite « arrête d'insister, ça ne sert à rien » pourrait être plus efficace.

Pour le second cas, le domaine qui n'a pas du tout de service de courrier, le RFC 7505 fournit un moyen simple de l'indiquer dans le DNS, avec le « MX nul ». Il ne manquait qu'un code de retour adapté, pour que le premier relais SMTP de l'utilisateur puisse dire « je ne peux pas envoyer de courrier à ce domaine, ils ne veulent pas ».

Le code 521 est décrit dans la section 3 du RFC. Il est renvoyé au début de la connexion puisqu'il décrit un refus général (pas d'exceptions). Si le refus du courrier est dû à certaines caractéristiques du courrier (par exemple l'emploi de tel émetteur), il ne faut pas utiliser 521 mais plutôt 554. Voici à quoi pourrait ressembler l'accueil d'un serveur SMTP simple, qui ne fait que rejeter imédiatement :

% telnet mail.example.net smtp
Trying 2001:db8:666::1...
Connected to mail.example.net.
Escape character is '^]'.
521 I hate everybody, do not come back
[Connexion fermée]

Le serveur peut clore la connexion immédiatement, ou bien la laisser ouverte et renvoyer des 521 systématiquement. Un message moins pittoresque pourrait être « Server does not accept mail ».

À noter que le code 521 avait déjà été décrit dans le RFC 1846 mais pas normalisé.

La section 4 décrit l'autre code, 556. Le premier code était prévu pour un serveur qui refusait le courrier, le second pour un relais qui essaie d'envoyer au serveur suivant mais découvre que le domaine de destination n'a pas l'intention d'accepter du courrier. Cette découverte se fait typiquement en voyant le « MX nul » du domaine en question (RFC 7505). En faisant une requête MX pour connaître le serveur suivant, le relais peut découvrir que le domaine n'accepte pas de courrier, et il renvoie alors un 556 à son client.

Les deux codes sont désormais enregistrés à l'IANA.