Mon blog

Le protocole SMTP de transport du courrier électronique, normalisé dans le RFC 5321, prévoit depuis le RFC 3463 des codes d'erreur à trois nombres très détaillés. Mais il n'existait pas de registre de ces codes et des doublons commençaient à apparaître. Ce RFC spécifie donc un registre des codes de retour SMTP, où tout le monde pourra vérifier que 4.3.1 signifie « Mail system full ».

Parmi les scénarios que résolvent ces codes de retour figure celui de l'internationalisation. SMTP est asynchrone et indirect. L'expéditeur du message n'a pas de contact direct avec les serveurs SMTP sur le trajet. Cela rend donc difficile des problèmes comme celui de la génération de messages d'erreur dans la langue de l'expéditeur. Actuellement, le serveur SMTP typique génère des messages d'erreur dans sa langue à lui (en général de l'anglais), pas dans celle de l'expéditeur qui va le recevoir. Plusieurs approches complémentaires ont été tentées pour résoudre ce problème, celle permise par notre RFC 5248 étant d'envoyer un code de statut numérique, que le MUA de l'expéditeur aura la charge de traduire. Ainsi, recevant « 5.2.2 - User's mailbox is too large - over ten gigabytes », le MUA pourra afficher « Pas assez de place dans la boîte aux lettres du destinataire » (et ignorer les détails en anglais).

Les codes SMTP (RFC 5321, section 4.2.1) originaux, dits « de base » sont composés de trois chiffres écrits sans séparateur (par exemple 554 pour Transaction failed). Les codes « améliorés » du RFC 3463 comportent, eux, trois nombres, la classe (2 : tout va bien, 4 : erreur temporaire, 5 : erreur définitive, etc), le second le sujet (6 : problème avec le contenu du message, 7 : problème avec la politique de sécurité, etc) et le troisième le détail. Ils s'écrivent avec un point comme séparateur. Ainsi, 5.5.2 signifie « Commande non reconnue » (erreur de classe 5, permanente, puisque le serveur SMTP ne va pas spontanément accepter de nouvelles commandes, erreur de sujet 5, problème de protocole). Dans cette session SMTP, on voit le code de base, 502 et le code amélioré 5.5.2 :

% telnet MYSERVER smtp
220 myserver.example.com ESMTP Postfix (Ubuntu)
XMPA <me@foobarfr>
502 5.5.2 Error: command not recognized

Dans ce cas précis, le gain apporté par les codes améliorés est faible, le code de base était déjà suffisamment spécifique. Mais, dans le futur, des codes améliorés supplémentaires pourront être enregistrés (comme ce fut le cas pour ceux du RFC 7372). Ainsi, il n'y a pas actuellement de code pour le greylisting (RFC 6647, notamment la section 5)) et les serveurs SMTP renvoient donc un code générique :

RCPT TO:<foobar@langtag.net>
450 4.7.1 <foobar@langtag.net>: Recipient address rejected: Greylisted by greyfix 0.3.2,\
    try again in 3480 seconds.\
    See http://projects.puremagic.com/greylisting/ for more information.

Un futur RFC pourra donc créer un code pour cette utile technique anti-spam.

Notre RFC demande donc à l'IANA (section 2) de créer un registre, le SMTP Enhanced Status Codes, précisant les codes et leur signification.

Ce registre, dit la section 2.3, sera rempli, en suivant les règles du RFC 5226, selon la règle « Specification required » qui impose l'existence d'un texte écrit (pas forcément un RFC). La section 2.4 décrit les valeurs initiales contenues dans ce registre.