Résumé

  • La RFC 2034 préfixe le texte de presque toutes les réponses SMTP 2xx, 4xx et 5xx par un code class.subject.detail. Sa classe doit rester cohérente avec celle de la réponse principale.
  • Le serveur envoie ce code même si le client n’a pas utilisé EHLO. Ce choix sans demande ni refus possible est présenté comme une exception de compatibilité étroitement délimitée.
  • Le code facilite tri, nouvelles tentatives et explications localisées. Il atteste ce qu’un serveur a déclaré lors d’un échange, non la cause réelle, la livraison finale, la lecture ou la justesse de la politique.

Un logiciel de messagerie ne devrait pas avoir à comprendre la phrase « boîte inconnue » dans toutes les langues du monde pour décider quoi faire. Avant la RFC 2034, le code SMTP à trois chiffres donnait déjà une direction générale aux automates, tandis que le texte précisait le problème pour une personne. Mais plusieurs situations différentes pouvaient partager un même code principal, et le texte libre résistait mal aux agrégations.

Publiée en octobre 1996, la RFC 2034 ne supprime aucun de ces deux éléments. Elle insère au début du texte un repère plus fin, composé d’une classe, d’un sujet et d’un détail. C’est un compromis élégant : la machine obtient une catégorie transportable, l’être humain conserve une explication qui peut varier selon le contexte et la langue.

Une précision emboîtée, pas un nouveau dialogue

L’extension s’appelle Enhanced-Status-Codes et apparaît dans EHLO sous ENHANCEDSTATUSCODES. Elle ne prend aucun paramètre et n’introduit aucune nouvelle commande. La modification reste dans une réponse que le client savait déjà recevoir.

La classe est 2, 4 ou 5 ; le sujet et le détail comprennent chacun de un à trois chiffres. Surtout, la classe enrichie doit correspondre à celle du code principal. Une réponse 4xx porte donc un 4.X.X, jamais un 5.X.X. Cette redondance contrôlée rend une contradiction observable au lieu de laisser deux signaux concurrents guider le client.

Le bénéfice apparaît dans les opérations. Deux refus permanents peuvent être dirigés vers des équipes différentes sans analyser la formulation propre à chaque serveur. Un tableau de bord peut agréger des catégories communes. L’interface destinée à l’expéditeur peut produire une explication française à partir du code et garder le texte original comme preuve. Les règles de reprise deviennent explicites et testables.

Mais l’accord entre les chiffres n’est qu’une cohérence interne. 550 5.1.1 montre qu’un serveur a déclaré un problème permanent d’adresse de destination. Il ne prouve ni l’état réel d’une base distante, ni l’identité de celui qui a fixé la politique, ni le résultat qu’aurait donné un autre chemin autorisé.

Les exceptions font partie du contrat

Les codes enrichis apparaissent sur les lignes 2xx, 4xx et 5xx, sauf le message d’accueil initial et les réponses à HELO ou EHLO. Les réponses 3xx sont expressément exclues. Dans l’exemple de la RFC, la réponse intermédiaire 354 invitant le client à transmettre le contenu ne porte donc pas de code enrichi.

Cette précision protège contre une mauvaise métrologie. Un test qui exige un code sur chaque réponse SMTP déclarera non conforme un comportement correct. Une collecte qui ne conserve pas la commande et la position dans la session mélangera exception légitime et omission réelle.

L’exemple déroule plusieurs catégories — acceptation de l’expéditeur, destinataire valable, boîte absente, transfert interdit, message accepté, fermeture de session. Il illustre la structure, pas l’issue ultime. « Accepté » décrit le passage d’un état du serveur ; rien dans cette ligne ne prouve l’arrivée en boîte, l’affichage sur un appareil ou la lecture par une personne.

Une extension active sans choix du client

La singularité de la RFC 2034 tient à son activation. Un serveur conforme joint les codes enrichis même si le client n’emploie pas EHLO. Aucun mécanisme ne permet de les demander ou de les refuser.

Le changement reste compatible parce qu’il occupe la zone textuelle qu’un ancien client devait déjà tolérer. Celui-ci peut ignorer le découpage et traiter l’ensemble comme du texte. Les auteurs estimaient aussi que la mise en œuvre médiocre des erreurs SMTP justifiait d’apporter une meilleure classification à tous les clients.

Ils ferment aussitôt la porte à une généralisation : il s’agit d’un cas très spécial, qui ne doit pas autoriser de futures extensions à modifier fortement l’interaction sans annonce du serveur et commande d’activation du client. Autrement dit, l’absence de négociation n’est sûre ici que parce que la syntaxe existante enferme le changement et que son effet demeure restreint.

Une réponse multiligne ne porte qu’une déclaration

Quand une réponse se poursuit sur plusieurs lignes, le même code enrichi doit ouvrir le texte de chaque ligne. L’exemple répète 5.7.1 sur deux lignes 551. La règle générale de SMTP impose également le même code principal sur toutes les lignes.

Cette répétition permet de traiter des journaux ligne par ligne sans perdre la catégorie et interdit qu’une même réponse se transforme, à mi-chemin, d’échec de politique en autre chose. Le texte peut ajouter des nuances ; le statut déclaré reste unique.

La place disponible pour les nuances a cependant un coût. La section de sécurité de la RFC observe que davantage de détails donnent forcément davantage d’informations sur le serveur et peuvent aider à contourner ses protections. Noms d’hôtes internes, existence d’un compte, règle antispam, route de transfert ou seuil opérationnel ne deviennent pas sûrs simplement parce qu’ils figurent dans un message de diagnostic.

Le bon objectif est donc double : conserver une catégorie stable et une explication utile, tout en révélant le minimum. La cohérence syntaxique n’accorde aucun droit à l’indiscrétion.

Conserver le témoignage sans inventer sa cause

Un statut 4 peut légitimement placer un travail dans une file de reprise. Un statut 5 peut arrêter les tentatives automatiques selon la politique locale. Sujet et détail peuvent orienter l’incident vers l’administration des adresses, la capacité, la sécurité ou la configuration. Ces décisions reposent sur une observation réelle : la déclaration reçue.

Elles ne doivent pas être reformulées comme une expertise du système distant. Le code n’explique pas pourquoi une recherche a échoué, ne garantit pas la constance de la politique et n’authentifie pas l’exactitude du diagnostic. Même une réponse positive ne franchit pas les étapes suivantes de la chaîne de livraison.

La RFC montre ensuite comment une notification peut être produite et note que le MTA rapporteur a omis les codes enrichis de certains champs pour alléger le résultat. Cela rappelle que la réponse en direct, le journal de file, le rapport ultérieur et le résumé visible par l’utilisateur sont des objets distincts. Une transformation peut perdre de l’information sans que le lecteur le voie.

La RFC 5248 a plus tard créé un registre IANA afin d’éviter les conflits d’attribution. Le registre coordonne un vocabulaire ; il ne certifie pas les faits d’un incident. Le même principe de réalité s’applique à la RFC elle-même : un document décrit une règle commune, tandis que l’exécution réelle se trouve dans les octets émis, l’analyse locale et l’action observée.

Une preuve opérationnelle solide garde donc ensemble le pair, l’heure, la commande, le code principal, le code enrichi, le texte complet, les limites de lignes, le résultat du parseur et la décision locale. La syntaxe et la cohérence peuvent être vérifiées. La cause, la légitimité de la politique et l’issue finale exigent d’autres sources.

Sources