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.
