Résumé

  • La RFC 1425 a créé avec EHLO un point commun de découverte des extensions SMTP. La réponse positive ne valait que pour la session en cours et ne devait jamais être mise en cache pour la suivante.
  • Le repli supposait qu'un serveur ancien rejette EHLO sans perdre son état et laisse le client revenir à HELO. La RFC 1651 a ensuite décrit des serveurs qui fermaient la connexion ou refusaient ce second salut.
  • Une extension enregistrée, une capacité annoncée, un repli exécutable, une commande acceptée, une transaction de courrier et une remise finale sont des preuves distinctes.

Au début de 1993, le courrier Internet devait évoluer sans fixer un jour où toutes les machines du monde changeraient ensemble.

La simplicité de SMTP avait favorisé son déploiement. Une connexion, un message d'accueil, HELO, l'enveloppe, puis le contenu : le dialogue restait lisible. Mais les besoins nouveaux s'accumulaient. Inventer une négociation particulière pour chaque fonction aurait transformé le protocole commun en collection de dialectes.

La RFC 1425 a choisi un socle mince. Elle n'imposait pas le catalogue des extensions futures. Elle définissait la manière dont un client étendu pouvait demander à un serveur ce qu'il annonçait : commencer par EHLO, lire une réponse éventuellement multiligne, reconnaître des mots-clés enregistrés, puis appliquer la RFC propre à l'extension retenue.

Le registre donnait un sens commun au nom. Il ne déployait pas le logiciel.

La capacité expirait avec la session

Le texte interdisait au client de conserver les informations d'un EHLO réussi. S'il voulait connaître les fonctions étendues, il devait reposer la question au début de chaque session SMTP.

Cette règle empêchait une observation ancienne de devenir un droit permanent. Derrière le même nom d'hôte pouvaient changer le processus, la configuration, le chemin ou l'état de maintenance. La déclaration devait donc exister dans le canal qui allait réellement transporter les commandes.

Une réussite portait le code 250 et plaçait les deux interlocuteurs dans l'état initial : aucune transaction n'était en cours, tables d'état et tampons étaient remis à zéro. La liste qui suivait indiquait les mots-clés et leurs paramètres éventuels. Les noms publics ne commençant pas par X renvoyaient à des extensions enregistrées; le préfixe X servait alors aux accords locaux.

Cette liste ne prouvait aucune opération. Le client devait encore sélectionner une extension, envoyer sa commande ou son paramètre, puis recevoir une réponse propre à cette action.

La RFC 1426 illustre l'ordre. Voir 8BITMIME dans la réponse à EHLO précède l'emploi de BODY=8BITMIME dans MAIL FROM; l'acceptation de cette commande précède DATA. Le mécanisme du corps huit bits appartient à une autre histoire. Ici, il montre seulement que l'annonce et l'usage ne sont pas la même pièce de preuve.

Le repli propre exigeait un état propre

Il fallait continuer à parler aux serveurs limités à la RFC 821. La RFC 1425 imaginait une rencontre ordonnée : le vieux serveur ne reconnaît pas EHLO, renvoie une erreur, mais conserve le canal. Le client peut réinitialiser ou envoyer HELO, puis poursuivre selon l'ancien SMTP.

Le refus n'était ni faute morale ni ordre de mise à niveau. Les deux parties revenaient simplement au plus petit ensemble de règles qu'elles partageaient.

Or la flèche du diagramme dépendait de faits invisibles dans sa syntaxe. La connexion devait rester ouverte. La commande inconnue ne devait pas corrompre l'état interne. Le RSET ou le HELO suivant devait être traité au bon endroit de l'automate.

Une norme pouvait exiger ces propriétés. Seule l'exécution pouvait montrer qu'elles existaient.

La RFC suivante a consigné le terrain

En juillet 1994, la RFC 1651 a remplacé la RFC 1425. Elle conservait l'architecture, mais ajoutait une section sur les serveurs « mal implémentés ».

Certains fermaient le canal SMTP à la réception de EHLO, avant ou après une réponse. Ce comportement contredisait la règle de la RFC 821 selon laquelle la fermeture devait normalement suivre QUIT. Répéter cette règle ne rouvrait pourtant aucune socket.

Le client devait désormais observer la survie du canal. Après une fermeture, il devait décider si l'opération restait possible sans extension; dans ce cas, il ouvrait une nouvelle connexion et utilisait HELO. Ce n'était pas la suite de la première session, mais un nouvel essai avec une autre identité temporelle.

D'autres serveurs gardaient la ligne, mais n'acceptaient plus HELO après avoir rejeté EHLO. Un RSET intermédiaire pouvait les débloquer. Même ce remède produisait parfois un 503 Bad sequence of commands, que la RFC autorisait à ignorer dans ce cas étroit.

La RFC 1869, successeur de 1995, a conservé cet avertissement. Le défaut d'interopérabilité était devenu une mémoire normative du déploiement.

La révision ne montre pas que l'écriture des normes est vaine. Elle montre une norme corrigée par les faits : le premier automate restait la définition du comportement valide, tandis que le texte suivant cessait de confondre validité et présence dans le parc installé.

Le mot « repli » cache plusieurs relations

Un journal peut résumer l'épisode par « ESMTP indisponible, SMTP réussi ». Cette ligne efface pourtant la plupart des preuves.

La connexion a pu s'ouvrir. Le 220 a pu arriver. EHLO a pu partir. Le serveur a pu répondre, fermer avant la réponse ou fermer après. Si le canal a survécu, RSET a pu réussir ou échouer; HELO a pu être accepté. Ensuite seulement viennent l'enveloppe, le contenu, la prise de responsabilité par un relais et la remise.

Chaque événement possède son horodatage et son canal. La réussite sur une seconde connexion ne répare pas la continuité de la première. Un mot-clé annoncé ne garantit pas l'acceptation de sa commande. Une réponse positive à la fin de DATA ne prouve pas la lecture par le destinataire.

L'interdiction du cache traduit cette discipline. Une capacité n'était pas une étiquette durable collée à un serveur dans un inventaire. C'était une déclaration prononcée dans une session. Le contexte disparaissait avec le canal.

Le socle mince a déplacé la dette

La RFC 1425 rappelait qu'un protocole avec peu d'options tend à devenir universel, alors qu'un protocole chargé d'options tend à devenir obscur. Son cadre conservait une petite surface commune et renvoyait chaque fonction à sa propre spécification.

Les vieux serveurs échappaient ainsi à une migration simultanée. En échange, le client qui voulait atteindre le plus grand nombre devait analyser les réponses multilignes, jeter les capacités périmées, détecter les fermetures et gérer les états déviants.

Le registre organisait les noms. Les opérateurs choisissaient localement les extensions exécutées. Les clients choisissaient le chemin compatible annoncé dans la session. L'adoption restait volontaire; l'interopérabilité restait conditionnée par le code réellement en marche.

Le dessin propre indique ce qui devrait arriver. La trace de session indique ce qui est arrivé.