Résumé

  • Les RFC 772 et 780 proposaient deux chorégraphies MTP : R conservait d’abord les destinataires ; T conservait d’abord le texte. Le récepteur contrôlait le schéma utilisable.
  • MRSQ détectait, choisissait et réinitialisait ; MRCP nommait un destinataire, mais son accusé n’avait pas la même portée dans R et T. L’ordre répartissait mémoire, preuve et risque d’échec.
  • Les RFC 788 et 821 ont remplacé cette négociation par l’ordre unique MAIL, plusieurs RCPT, DATA. Une copie du corps pouvait toujours servir plusieurs destinataires ; seule la diversité de la grammaire externe disparut.

La question qui effaçait ce qui la précédait

Dans RFC 780, MRSQ remplit plusieurs fonctions. Sans argument, il prouve que la famille MRSQ/MRCP existe et revient à l’état sans schéma. Avec ?, il demande la préférence du récepteur. Avec R ou T, il tente de sélectionner une procédure.

Chaque usage réinitialise pourtant l’état courant. La requête de préférence n’est donc pas une lecture neutre. Elle peut vider les destinataires mémorisés ou le texte conservé par le schéma précédent. Un outil qui l’injecterait au milieu d’une transaction pour « observer » modifierait l’objet observé.

Le client peut demander R ; le serveur peut répondre qu’il ne peut pas l’utiliser et conduire le client vers T. Le texte précise que le récepteur choisit ce qui est effectivement pratiqué, même si l’émetteur exprime un souhait.

Cette autorité repose sur une information locale. Le récepteur sait s’il remet un lot complet à un mailer central, s’il livre au fil des destinataires, combien de noms il peut garder et quel objet coûte le plus à stocker.

R gardait une table avant de recevoir le corps

Dans recipients-first, l’émetteur envoie plusieurs MRCP TO:<path>. Le récepteur répond à chaque nom et conserve les chemins acceptés. Le rejet d’une adresse n’annule ni celles déjà gardées ni celles qui peuvent suivre.

Une fois la liste prête, un MAIL FROM:<sender-path> sans argument TO introduit une seule copie du texte. Une réponse positive après ce texte signifie que tous les destinataires mémorisés ont réussi ; une réponse d’échec doit être interprétée comme un échec pour tout ce groupe. L’état des noms est ensuite vidé.

Le schéma correspond bien à un système qui transmet ensemble corps et liste à un composant central. Il rassemble le dossier avant l’opération de remise et économise les répétitions de texte.

Mais sa table est une ressource finie. Un 452 peut indiquer qu’aucun nom supplémentaire ne tient. Le RFC propose alors de transmettre le corps au groupe déjà gardé, de recueillir un autre groupe puis de retransmettre le corps. Cinquante destinataires avec une table de dix peuvent exiger cinq lots. L’économie « une copie » s’arrête à la capacité d’état du récepteur.

T gardait le corps avant de connaître la liste

Dans text-first, le même MAIL sans destinataire dépose d’abord le texte. Les MRCP suivants appliquent ce texte conservé à chaque adresse et renvoient un résultat individuel comparable à celui d’une remise séparée, sans refaire les manipulations ni la transmission du corps.

Le texte reste disponible jusqu’au prochain MAIL ou au prochain MRSQ, qui le remplace ou le purge. T économise donc lui aussi la bande passante ; il choisit simplement de conserver l’objet volumineux plutôt que la table des noms.

Cette forme convient à un récepteur qui livre de manière incrémentale. Un quota de boîte, un conflit d’accès ou une autre condition variable peut produire une réponse propre au destinataire concerné.

La souplesse a un prix. Quand le corps est accepté, le récepteur ignore encore s’il arrivera un destinataire valable. Un MRCP avant qu’un texte soit stocké ressemble à l’envoi d’un message nul et peut être accepté ou refusé selon l’implémentation. La séquence crée le sens.

Le même 2xx ne confirmait pas le même objet

Sous R, un succès MRCP confirme surtout que le chemin a été enregistré pour l’étape collective ultérieure. Sous T, le corps existe déjà et le succès MRCP correspond à son application à cette adresse. Sans le schéma actif, une ligne de journal ne dit pas quelle responsabilité vient d’être acquise.

Les points de remise à zéro renforcent l’ambiguïté. MRSQ efface l’état ; un MAIL normal avec un destinataire non nul le réinitialise également. Une analyse qui saute une commande peut rattacher un MRCP au mauvais corps ou à une liste déjà détruite.

Le coût d’une chorégraphie négociable apparaît ici. Deux ordres exigent deux objets conservés, deux interprétations de la réponse et plusieurs frontières de purge. La flexibilité locale devient un espace d’états partagé par tous les pairs.

Le récepteur connaissait son propre atelier

RFC 780 ne présente pas R et T comme une bonne et une mauvaise solution. R est adapté au récepteur qui ne livre pas directement et passe un lot complet à un mailer central. T convient au système qui traite une adresse après l’autre et veut rendre immédiatement ses contraintes locales.

Le client ne voit ni la taille de la table, ni l’architecture du mailer, ni les conflits de boîtes. Lui donner le dernier mot reviendrait à faire choisir l’acteur le moins informé. La préférence de l’émetteur restait donc subordonnée aux capacités déclarées par le récepteur.

Cette répartition était rationnelle connexion par connexion. À l’échelle du réseau, elle imposait néanmoins à chaque client, relais, analyseur et testeur de comprendre les deux histoires. Le fait qu’un choix soit justifié localement ne prouve pas qu’il doive rester dans le contrat externe.

SMTP a choisi un ordre visible unique

RFC 788 définit en novembre 1981 trois étapes. MAIL FROM ouvre la transaction et nomme l’expéditeur. Un ou plusieurs RCPT TO négocient les destinataires. DATA apporte enfin le texte. Le dialogue est volontairement lock-step et les commandes doivent suivre cet ordre.

MRSQ et le MRCP du courrier ne figurent plus dans cette grammaire. Le récepteur ne peut plus exiger le texte avant les destinataires. Le rejet d’un RCPT demeure propre à ce destinataire et ne détruit pas nécessairement la transaction pour les autres.

RFC 821 maintient le même modèle en 1982. Le changement n’oblige pourtant pas tous les serveurs à avoir le même intérieur. Ils peuvent valider tôt, mettre en file, remettre à un composant central ou traiter plus tard. Ils exposent seulement la même suite causale au client.

SMTP a donc standardisé l’enveloppe de l’opération, pas l’atelier qui la réalise. Le récepteur perd la faculté de modifier l’ordre sur le fil, mais conserve le choix de ses buffers et de son architecture derrière la frontière.

Une seule copie est restée l’objectif

Les deux schémas MTP voulaient éviter que le même corps soit transmis une fois par destinataire sur un même hôte. La disparition de T n’a pas détruit cet objectif.

RFC 788 et RFC 821 encouragent une seule copie des données pour plusieurs destinataires au même endroit. Dans l’ordre fixe, la séquence devient un MAIL, plusieurs RCPT, un DATA.

RFC 1123 renforce la recommandation : utiliser RCPT, RCPT, ... RCPT, DATA plutôt que répéter RCPT, DATA pour chaque personne. Les noms invalides peuvent être refusés avant que le corps traverse la liaison ; les noms acceptés le partagent.

La transition n’est donc pas une histoire de gaspillage succédant à l’efficacité. Elle conserve le résultat économique et supprime la seconde manière publique d’y parvenir.

Le pipelining ne remet pas le texte en tête

Lock-step désigne aussi l’attente d’une réponse avant la commande suivante. Une extension ultérieure comme PIPELINING réduit des allers-retours en autorisant certains envois groupés. Elle ne change pas les dépendances MAIL–RCPT–DATA.

Envoyer plus tôt des octets déjà ordonnés n’équivaut pas à sélectionner T. DATA ne précède pas les destinataires, et le serveur ne retrouve pas le pouvoir de choisir cette inversion.

La distinction compte pour l’histoire et l’exploitation. Le calendrier des réponses peut être optimisé alors que la structure transactionnelle reste identique. Confondre les deux ferait de toute amélioration de latence une nouvelle grammaire.

La norme moderne garde la frontière

RFC 5321 conserve MAIL, un ou plusieurs RCPT, puis DATA. Des extensions ajoutent des capacités et des paramètres, mais aucune ne rétablit le choix MRSQ entre corps et destinataires.

L’uniformité externe rend les différences internes plus faciles à changer. Un opérateur peut remplacer sa file ou son mailer sans demander à tous les clients de choisir un nouveau schéma. Un client n’a pas à connaître la chose que le serveur écrit d’abord sur disque.

La simplification réduit le nombre de transitions communes, ce qui réduit aussi les traductions qu’un relais doit faire et les cas qu’un journal doit expliquer. Ce bénéfice ne prouve pas que T était mauvais ; il montre pourquoi une bonne optimisation locale peut être retirée du langage interopérable.

Deux MRCP sans parenté

MRCP signifie ici Mail Recipient dans MTP. Le Media Resource Control Protocol, beaucoup plus tardif et destiné à des ressources de parole, réutilise les mêmes lettres sans reprendre ce mécanisme.

Une recherche qui ne joint pas MRSQ, mail, RFC 772 ou RFC 780 risque donc de conclure à tort qu’un article parle de synthèse vocale. L’acronyme seul n’est ni un identifiant historique ni une preuve de duplication.

Sources et limites

Le dossier utilise RFC 772, 780, 788, 821, 1123 et 5321. Ils établissent les schémas, l’autorité du récepteur, les purges, les limites de table, l’ordre SMTP et la continuité de l’économie multi-destinataires.

Ils ne donnent pas un recensement des déploiements, une date unique de retrait dans les logiciels ni un gain de performance universel. RFC 788 ne dit pas que MRSQ fut un échec ; il cesse de le définir et impose une autre procédure.

R n’est pas une transaction atomique pour tous les destinataires, et T ne retransmet pas le corps à chacun. Le sujet est la localisation de l’état et de la preuve, non un classement simpliste des deux méthodes.