Résumé

  • Le RFC 5248 répartit la maîtrise du vocabulaire SMTP enrichi entre trois tables, des références publiques, des responsables de modification et une politique d’enregistrement.
  • Cette gouvernance évite les collisions sémantiques ; elle ne vérifie ni le diagnostic d’un serveur, ni l’interprétation d’un client, ni la pertinence d’une relance, ni la livraison finale.

Une carte du vocabulaire, pas du trajet

Le trajet d’un message traverse plusieurs autorités : le serveur qui répond, le client qui reçoit la réponse, la file qui décide d’attendre, le relais suivant qui accepte et, éventuellement, la boîte qui remet le contenu à une application. Le registre IANA n’observe aucune de ces transitions. Il fournit la carte de mots dont elles peuvent se servir.

Cette carte est devenue nécessaire parce que le RFC 3463 avait prévu un espace extensible sans définir de procédure explicite pour enregistrer et suivre les extensions. Des définitions incompatibles ont alors commencé à se croiser. Le RFC 5248, publié comme Best Current Practice 138, a placé les attributions dans un registre et a mis à jour, entre autres, les RFC 4468 et 4954 qui avaient ajouté leur propre vocabulaire.

La correction porte donc sur la coordination. Une organisation peut désormais déterminer quelle signification publique appartient à un code, retrouver sa référence et identifier qui peut le modifier. Elle ne reçoit pas, en même temps, la preuve que le code décrit fidèlement l’événement survenu dans sa propre chaîne de messagerie.

Les trois positions n’ont pas la même fonction

La forme classe.sujet.détail invite à lire le code comme un verdict compact. Le registre la décompose pourtant en trois tables : sous-codes de classe, sous-codes de sujet et codes énumérés. Dans la dernière table, le sujet et le détail sont associés tandis que la classe reste générique. Une même condition peut en effet être compatible avec plusieurs classes si sa spécification le prévoit.

Chaque entrée conserve le code, un résumé ou texte d’exemple, une description, une référence avec son statut, l’auteur de la demande et le responsable du changement. Pour les entrées énumérées, elle indique aussi un code SMTP élémentaire à trois chiffres. Cette richesse décrit la provenance sémantique. Elle n’est pas un rapport d’exécution.

Le champ du code élémentaire est expressément non exclusif. Une valeur indiquée ne chasse pas toutes les autres associations possibles ; le registre peut même afficher Any ou Not given. Un moteur de conformité qui rejette automatiquement toute autre combinaison ferait d’un renseignement une règle bijective que le RFC a refusé d’établir.

Le cas X.0.0 illustre la même retenue. Il s’agit du seul code indéfini, utilisable lorsque seule la classe de la réponse est connue. Il préserve l’incertitude au lieu de l’habiller d’un faux détail. Une base d’incidents devrait faire de même.

L’examen protège l’espace partagé

Pour une nouvelle valeur, le RFC 5248 retient Specification Required. Les spécifications non normatives doivent être accessibles, et l’objectif principal consiste à prévenir la confusion et les collisions sans dresser des barrières inutiles. Le cadre actuel du RFC 8126 associe une spécification publique durable à l’examen d’un expert désigné, attentif notamment à la clarté, à la stabilité et à la qualité technique.

Cet expert examine une proposition de sens. Il n’inspecte pas la file d’attente d’un opérateur, ne reproduit pas l’échec d’un destinataire et ne certifie ni l’émetteur ni le parseur. Un excellent enregistrement peut être mal utilisé par un logiciel ; un diagnostic réel peut être résumé par un code trop général. L’acceptation dans le registre ne franchit pas cette distance.

Les droits de modification rendent la frontière plus visible. Une attribution issue de la voie normative change normalement avec la norme. Une attribution non normative relève de son responsable déclaré. Les corrections ordinaires portent sur la description ou la référence, plutôt que sur un recyclage discret du nombre ou du texte d’exemple. L’IESG peut exceptionnellement intervenir pour résoudre un conflit.

Ces règles créent une mémoire publique, pas une machine à réécrire le passé. Le registre initial mêlait d’ailleurs des valeurs tirées de RFC publiés et des valeurs déjà utilisées dans l’industrie sans spécification publiée. Des codes de sécurité ont été placés sous contrôle de l’IESG. La condition « Trust Relationship Required » a reçu X.7.14 en remplacement d’un ancien usage de X.7.8. Le registre peut réparer l’adresse sémantique ; il ne sait pas quand chaque déploiement a déménagé.

Temporaire et permanent sont des instructions conditionnelles

Dans le RFC 3463, la classe 2 représente une réussite dans une notification d’état de livraison. La classe 4 signale un échec transitoire persistant pour lequel une tentative ultérieure peut réussir. La classe 5 désigne un échec permanent qui exige généralement une modification du message ou de la destination.

Le mot « permanent » est facile à surcharger. Le RFC 5321 demande au client SMTP de se guider sur le code de réponse, non sur le texte explicatif. Une réponse 4yz ouvre la possibilité d’une nouvelle tentative sous certaines conditions. Une réponse 5yz déconseille de répéter exactement la même requête sans changement. Le texte reconnaît néanmoins qu’une situation présentée comme permanente peut ensuite être corrigée.

Il faut donc conserver le temps autour du code. À quelle tentative répond-il ? Pour quel destinataire ? Quel serveur l’a émis ? La configuration a-t-elle changé ? Une nouvelle route a-t-elle été utilisée ? 4.x.x ne promet pas un succès futur, pas plus que 5.x.x ne prouve une impossibilité éternelle. Les deux fournissent une indication structurée à une politique qui reste responsable de sa décision.

Le RFC 2034 organise le transport des codes enrichis dans les réponses SMTP. Le RFC 5248 organise leur vocabulaire. Entre les deux se trouvent l’émission correcte, la conservation exacte du contexte et la logique de relance. Après eux viennent le transfert suivant, l’acceptation finale et l’usage du message. Une seule colonne « statut » ne peut représenter honnêtement cette chaîne.

Le détail peut devenir une fuite

Un diagnostic plus précis n’est pas toujours un meilleur message public. Le RFC 5248 avertit que les codes enrichis peuvent révéler l’architecture interne d’un système. Dans un échange d’authentification, distinguer « utilisateur inconnu » et « mauvais mot de passe » peut transformer le serveur en oracle pour un attaquant. Les spécifications doivent donc indiquer quand le logiciel devrait limiter le détail exposé.

Une réponse publique volontairement générale peut ainsi coexister avec un constat interne plus précis. Cette divergence n’est pas nécessairement une erreur ; elle peut être le résultat d’une politique de sécurité. L’audit doit relier les deux niveaux sans exiger qu’ils soient identiques, et sans conclure que la précision publique prouve la précision interne.

Construire une chaîne de corroboration

La première preuve est syntaxique : le code peut être analysé. La deuxième est documentaire : la version observée du registre contient l’attribution. La troisième reste une déclaration : une implémentation affirme que la condition enregistrée s’applique. Il faut ensuite vérifier la compatibilité de la réponse élémentaire, conserver la commande et le contexte, puis chercher une corroboration dans les journaux du serveur et les transitions de file.

Plus haut dans la chaîne se trouvent la décision de relance, le transfert suivant, l’acceptation par la destination, le dépôt dans une boîte et l’effet humain ou commercial. Aucune étape inférieure ne doit hériter de l’autorité d’une étape supérieure. Un code bien enregistré peut participer à la preuve ; il ne remplace pas les reçus qui lui manquent.

La distinction de Lu Heng entre code en fonctionnement et couches de réalité est ici opérationnelle. Le registre coordonne un symbole ; les machines produisent des observations ; l’organisation décide. Lorsque ces couches sont fusionnées, un nom normalisé acquiert un pouvoir causal qu’il n’a jamais gagné. Lorsqu’elles restent reliées mais séparées, le vocabulaire demeure utile sans devenir une fiction de certitude.

Sources