Résumé

  • Pour un USER syntaxiquement correct, la RFC 1204 recommandait 250 même si le serveur ne reconnaissait pas le nom. La réponse devait empêcher l’énumération des comptes, non confirmer leur existence.
  • PASS 250 portait ensuite une affirmation distincte : le mot de passe avait été vérifié comme associé au nom fourni. DATA 354 n’ouvrait que la réception du texte ; le 250 suivant le corps établissait sa mise en file locale.
  • Un NOOP 250 ne décrivait encore qu’un serveur de dépôt sans erreur interne dans la session. Le chiffre n’acquérait un sens qu’avec la commande, l’état et le composant qui répondait.

Le premier succès était volontairement incomplet

Un protocole peut cacher une information en répondant, et non seulement en se taisant. C’est ce que prescrit la RFC 1204 pour la commande USER. Le client remet un nom au serveur de dépôt de messages. Si la chaîne est recevable, le serveur peut répondre 250. Mais le texte ajoute qu’il devrait faire de même lorsque ce nom n’est pas reconnu.

L’objectif est formulé sans détour : ne pas livrer trop d’informations sur la base des utilisateurs et empêcher le client de tester l’existence d’un nom précis. Le serveur ne ment donc pas sur une authentification accomplie. À ce stade, il n’en annonce aucune. Il accepte une forme et maintient deux états internes—compte connu ou inconnu—derrière la même surface observable.

Cette dissociation change la lecture d’un journal. « 250, commande réussie » est trop pauvre. Le résultat porte sur la transition permise par USER, pas sur la vérité de l’objet nommé. Une console qui transforme cette ligne en « compte valide » annule le contrôle de confidentialité que le protocole voulait construire.

La notice du RFC Editor conserve la qualification Experimental et la publication de février 1991. La fiche Datatracker précise aujourd’hui qu’il s’agit d’un RFC du flux Legacy, antérieur à l’enregistrement d’une source formelle, sans approbation ni statut dans le processus actuel de l’IETF. Le document atteste une proposition historique ; il ne démontre ni déploiement généralisé ni recommandation contemporaine.

Un intermédiaire assumait le dépôt sans devenir toute la messagerie

Le problème de départ appartenait à son époque. Selon la RFC, les systèmes d’exploitation des micro-ordinateurs n’offraient pas de mécanisme d’authentification de l’utilisateur, alors que la messagerie devait limiter l’usurpation de l’expéditeur. Un serveur de dépôt, placé sur un hôte de service, devait vérifier l’utilisateur du PC puis remettre son courrier à un système de livraison tel que Sendmail ou MMDF.

Trois responsabilités existaient déjà : le client présentait les données ; le serveur de dépôt jugeait les identifiants et gardait une file locale ; le système de livraison exécutait la suite. Le protocole Netix utilisait TCP sur le port 218 et reprenait la syntaxe de commande/réponse de SMTP et FTP.

La parenté explique DATA, la terminaison par un point et les classes numériques. Elle n’efface pas le contexte. La RFC 821 décrivait un dialogue SMTP séquentiel entre émetteur et récepteur. MPP réemploya ce langage pour un autre bord : celui qui reliait un poste personnel à un agent de dépôt. Une valeur familière pouvait donc porter un constat différent.

Le mot de passe constituait la deuxième épreuve

Après le 250 de USER, le client envoyait PASS. Ici, un nouveau 250 signifiait que le mot de passe avait été accepté et vérifié comme correctement associé au nom précédemment présenté. 530 signalait l’échec de cette association ; d’autres réponses couvraient syntaxe, ordre et erreur interne.

La chronologie donne à chaque réponse son autorité. La première ne révèle pas la reconnaissance du compte. La deuxième relate une comparaison de données d’authentification. Fusionner les deux supprimerait soit la protection contre l’énumération, soit la preuve que le contrôle du secret a réellement eu lieu.

Même cette vérification restait locale. Elle ne certifiait pas l’identité civile de la personne au clavier, la paternité de chaque phrase, le droit d’écrire à toute destination ni la sincérité du contenu. Elle disait ce que le serveur de dépôt avait conclu d’un couple nom/mot de passe dans son propre environnement.

La RFC 4954 apporta bien plus tard une extension SMTP AUTH fondée sur SASL, avec négociation du mécanisme et réponses propres. Elle exige aussi que les mécanismes à mot de passe en clair soient refusables sans TLS ou protection équivalente contre l’écoute. Ce contraste situe les limites de MPP ; il ne faut ni attribuer rétroactivement ces protections à RFC 1204, ni prétendre une filiation directe.

Être prêt à lire n’était pas garder le message

Une fois le mot de passe accepté, DATA pouvait recevoir 354. Ce code annonçait que le serveur était prêt à lire le texte. Il modifiait le parseur et autorisait les octets suivants. Il ne confirmait ni la fin du corps, ni son enregistrement durable.

Le client envoyait alors le message et sa séquence terminale empruntée à SMTP. Après cette fin seulement, 250 prenait un troisième sens : le texte avait été placé avec succès dans la file de livraison. Si une erreur interne empêchait la mise en file, le serveur répondait 451.

La file établissait une garde locale, mais pas le résultat final. La RFC demandait au serveur de dépôt d’essayer de transmettre rapidement les messages acceptés au système de livraison. Elle confiait ensuite les échecs de livraison à ce système et demandait au serveur de dépôt de ne pas intervenir.

Ce partage interdit de convertir la mise en file en réception par une boîte, en affichage par un logiciel ou en lecture humaine. Un composant pouvait tenir exactement sa promesse—conserver l’objet pour l’étape suivante—sans posséder l’observation des étapes ultérieures.

Le quatrième 250 surveillait uniquement le dépôt

NOOP n’exécutait aucune opération sur un message. Sa réponse 250 indiquait que le serveur de dépôt n’avait rencontré aucune erreur interne pendant la session en cours. Cette bonne santé ne s’étendait pas au système de livraison.

Le même code recouvrait ainsi quatre faits incompatibles avec une étiquette unique :

  • poursuite après un nom syntaxiquement acceptable, reconnaissance tenue secrète ;
  • association nom/mot de passe vérifiée ;
  • corps complet placé dans la file locale ;
  • absence d’erreur interne connue dans le serveur de dépôt.

La bonne unité d’observation n’est donc pas le code isolé. Il faut conserver protocole, connexion, commande, état précédent, nouvel état, composant répondant et objet concerné. Sinon, l’automatisation confond une ambiguïté de sécurité avec une authentification, une garde locale avec une livraison et l’état d’un agent avec celui de toute la chaîne.

La séparation moderne du dépôt confirma la valeur des rôles

La RFC 6409 formalisa ensuite le dépôt sur le port 587. Elle distingue le Message Submission Agent, qui accepte un message d’un logiciel utilisateur et le livre ou le relaie, du Message Transfer Agent chargé du transfert. Cette séparation permet d’appliquer des politiques et mécanismes de sécurité différents.

Le rapprochement est structurel, pas généalogique. Il ne prouve ni que MPP fut adopté, ni qu’il causa la norme ultérieure. Il montre pourquoi les noms de rôles restent nécessaires. L’agent qui reçoit une soumission peut connaître l’utilisateur et la file locale sans connaître encore la destination effective. Son succès est réel, mais limité à sa frontière.

La RFC 1204 mérite donc d’être relue comme une petite grammaire de l’ignorance maîtrisée. Le protocole cachait exprès l’existence du compte au premier échange, réservait la vérification au second et empêchait la file locale de parler au nom du système de livraison. Trois chiffres ne formaient jamais, seuls, un verdict universel.

Sources