Résumé

  • RFC 821 proposait trois commandes facultatives qui inscrivaient la présentation au terminal, le dépôt en boîte ou les deux dans la transaction SMTP.
  • Leur notion de réussite variait : SEND exigeait le terminal, SOML acceptait l’un des deux chemins et SAML dépendait du dépôt en boîte même s’il tentait aussi l’écran.
  • Le relais MX pouvait connaître la route sans commander le terminal de l’utilisateur ; les versions ultérieures de SMTP ont donc relégué ces commandes à une compatibilité déconseillée.

Choisir une arrivée avant même de donner le texte

Imaginons un hôte partagé en 1982. Le destinataire y est connecté et accepte les messages qui surgissent sur son terminal. L’émetteur ouvre une session SMTP et, au lieu de commencer par MAIL, peut choisir parmi trois verbes.

SEND demande une remise au terminal. Si l’utilisateur est absent ou refuse ce type d’interruption, le serveur peut répondre par un échec temporaire pour ce destinataire. SOML, Send Or MaiL, essaie le terminal quand l’utilisateur est présent, sinon dépose le texte dans sa boîte. SAML, Send And MaiL, tente l’affichage lorsque c’est possible et conserve dans tous les cas une copie en boîte.

Selon le RFC 821, il ne s’agissait pas de simples préférences attachées au contenu. Chacune de ces commandes ouvrait la transaction, avant RCPT puis DATA. L’expéditeur choisissait donc la nature de l’arrivée avant de livrer les destinataires et le corps.

SMTP se voyait confier une question qui dépassait l’acheminement : cette personne est-elle active maintenant, consent-elle à être interrompue et faut-il compter comme livraison un éclair sur l’écran ou une copie conservée ?

Un même mot cachait trois preuves différentes

Pour SEND, la transaction ne réussissait que si les données atteignaient le terminal. La boîte aux lettres n’était pas un repli implicite. Pour SOML, l’affichage et le dépôt étaient substituables : l’un ou l’autre suffisait. Pour SAML, la boîte était obligatoire et le terminal supplémentaire ; la réussite dépendait du dépôt, non de la certitude que l’écran s’était allumé.

Un SEND réussi pouvait donc être immédiat sans être durable. Un SOML réussi ne disait pas forcément quel chemin avait abouti. Un SAML réussi attestait la branche de conservation, pas l’attention du lecteur.

Cette grammaire avait le mérite de ne pas confondre totalement présence et garde. Mais elle donnait à l’expéditeur le choix d’un mode dont le destinataire supportait l’interruption et dont l’hôte d’arrivée devait fournir la preuve.

La présence appartenait à une session locale

Le RFC 821 exigeait que l’utilisateur soit actif sur l’hôte et accepte les messages de terminal. Ni l’une ni l’autre de ces conditions n’était une propriété stable de l’adresse électronique.

L’adresse pouvait rester identique pendant que la personne se déconnectait, changeait de poste ou fermait la porte aux interruptions. La route pouvait rester correcte alors que le serveur qui recevait le courrier ne contrôlait plus l’interface interactive. L’état pouvait même changer entre l’acceptation du destinataire et la fin des données.

Le client pouvait demander SEND; il ne pouvait pas déclarer la présence. De même, l’annonce d’une commande dans EHLO prouvait une capacité grammaticale, pas la disponibilité ni le consentement d’une personne précise.

Le relais MX connaissait la destination, pas l’écran

Le RFC 1123 a rendu facultative l’implémentation de SEND, SOML et SAML, côté émission comme côté réception. Sa remarque sur les relais expose le problème essentiel.

Un échangeur MX peut recevoir au nom d’un domaine et savoir comment poursuivre la route, sans pouvoir écrire directement sur le terminal de l’utilisateur. Après un SEND, il pouvait répondre 251 User Not Local pour signaler que la remise risquait d’être différée.

Deux formes d’accessibilité se séparaient ainsi. L’accessibilité de routage permet de prendre en charge et de transférer le courrier. L’accessibilité de présentation suppose de commander la session où se trouve l’utilisateur. Un relais peut posséder la première sans la seconde.

Le stockage-transfert distribuait efficacement la responsabilité du message. Il ne distribuait pas automatiquement le pouvoir d’obtenir l’attention humaine.

La découverte d’extension ne découvrait pas l’utilisateur

Avec le RFC 1425, le premier registre des extensions SMTP a inscrit les trois commandes comme services optionnels, leur nom servant également de mot-clé EHLO.

Le client pouvait savoir que le serveur comprenait la commande. Il ne savait toujours pas si le destinataire était connecté, s’il acceptait l’affichage, si ce serveur était l’hôte final ni si la présentation réussirait.

Une interface peut facilement transformer cette capacité en voyant vert, puis le voyant en promesse. Ce glissement serait faux : EHLO décrit le vocabulaire du serveur, non l’état intime du destinataire.

La compatibilité est restée, le centre de gravité a changé

En 2001, le RFC 2821 qualifiait déjà SEND, SAML et SOML d’obsolètes. Les commandes avaient été rarement implémentées ; les nouveaux postes de travail et d’autres protocoles avaient pu les rendre inutiles même là où du code subsistait.

La norme n’a pas supprimé brutalement les anciens interlocuteurs. Les clients ne devaient plus proposer ces services. Un serveur pouvait encore les implémenter, à condition de respecter le modèle du RFC 821 et de les annoncer dans EHLO.

Le RFC 5321 conserve ce compromis. Les verbes restent reconnaissables, tandis que le SMTP ordinaire se concentre sur MAIL et sur le transfert formel de responsabilité après l’acceptation des données.

Cette responsabilité est une promesse durable : le serveur qui accepte doit poursuivre la livraison ou signaler l’échec. Elle est plus solide qu’une affirmation sur l’écran regardé par quelqu’un à un instant donné. La dépréciation a donc réduit la prétention du transport sans interdire toute compatibilité.

Un registre n’est pas un recensement

Les registres SMTP de l’IANA conservent SEND, SOML et SAML, leurs références au RFC 821, leur dépréciation ultérieure et l’interdiction de les employer pour Message Submission.

Ces lignes entretiennent des noms interopérables. Elles ne mesurent ni le déploiement actuel, ni la présence des destinataires, ni le succès d’un affichage précis. Enregistrer un mot ne ressuscite pas les conditions sociales auxquelles ce mot supposait d’accéder.

Capacité, présence, consentement, présentation, stockage et responsabilité forment six faits différents. Le SMTP initial en associait plusieurs dans le choix d’un verbe. Le SMTP ultérieur n’a pas résolu l’attention humaine ; il a cessé de la promettre au cœur du transport.

L’écran le plus rapide n’était pas la remise la plus forte

Ces commandes avaient un sens dans un petit univers d’hôtes étroitement liés. SOML organisait un repli raisonnable ; SAML protégeait une copie. Les auteurs avaient vu une vraie différence entre montrer et conserver.

L’échelle a déplacé cette différence vers d’autres couches. Avec davantage de relais, de postes hétérogènes et d’agents utilisateurs, le transport pouvait posséder une file et assumer la garde. Il ne pouvait pas posséder l’écran actuel ni la volonté d’être dérangé.

Un écran peut s’allumer tout de suite et s’éteindre sans trace. Une boîte silencieuse peut être consultée plus tard tout en conservant une responsabilité. Le message arrivé avant la boîte avait peut-être gagné quelques secondes ; il n’avait pas nécessairement trouvé où rester.

Sources