Résumé

  • La réponse positive au terminateur final de DATA signifie que le serveur SMTP récepteur accepte le message et prend la responsabilité de le remettre ou de le relayer. C’est un transfert de garde, non un reçu de destination.
  • Le code doit rester lié à sa commande. 250 après EHLO, MAIL, RCPT, RSET ou NOOP ne décrit pas l’acceptation du message complet.
  • La preuve exploitable relie enveloppe, réponses par destinataire, fin de DATA, écriture durable en file, relais suivants et résultat local. Placement, filtrage et lecture restent des événements indépendants.

Un même nombre, plusieurs dettes

Deux lignes de journal peuvent afficher exactement 250 OK et engager des choses totalement différentes.

Après EHLO, la réponse confirme un état de dialogue et annonce éventuellement des extensions. Après MAIL FROM, elle accepte un reverse-path. Après RCPT TO, elle retient un destinataire dans la transaction. RSET peut recevoir 250 après avoir effacé l’état courant ; NOOP l’obtient sans accomplir d’autre action. Aucun de ces cas ne dit que le corps entier est sous la garde du serveur.

La réponse décisive arrive plus tard. Le client a reçu 354, transmis les données et envoyé l’indicateur final. Le récepteur traite alors le reverse-path, les forward-paths acceptés et le contenu stocké. S’il accepte l’ensemble pour remise, il répond positivement ; sinon, il doit échouer la transaction. La RFC 5321 ne prévoit pas un demi-succès à cette frontière.

C’est ici que 250 change la dette. Le serveur récepteur assume la pleine responsabilité du message. Il doit le remettre, le relayer ou traiter convenablement l’échec ultérieur. L’expéditeur peut libérer sa propre copie parce qu’un autre acteur a promis de conserver l’objet et de poursuivre.

Un tableau de bord qui ne garde que le nombre détruit donc la preuve. Il faut au minimum la commande, l’identifiant de session, l’enveloppe, les destinataires encore admis et l’instant précis. Le statut n’est pas faux ; il a été séparé de sa juridiction.

La place de John Klensin est bornée par ces documents. Le profil officiel de l’IETF le nomme Dr John C. Klensin et recensait 60 RFC lors de cette recherche. La RFC 5321 le désigne comme auteur. Cette attribution atteste une contribution à un standard collectif ; elle ne lui confère aucune autorité sur la file d’un opérateur ni sur la conformité d’un produit.

La promesse doit être durable avant de partir

Le transfert de responsabilité explique l’ordre attendu du code en fonctionnement. Le message doit être dans un état suffisamment durable avant que la réponse positive quitte le serveur. Répondre puis tenter l’écriture expose une fenêtre où l’expéditeur a supprimé sa copie tandis que le récepteur n’en possède pas encore une sauvegarde fiable.

La RFC 5321 exige que le serveur ne perde pas un message accepté pour une raison frivole, comme une panne ultérieure ou une pénurie prévisible. Elle ne prescrit pas une base, un journal, un quorum ou une réplication universels. Ce sont des décisions locales. La norme porte l’obligation ; le code en service produit — ou non — le reçu d’exécution.

La primauté du running code formulée par Heng Lu ne diminue donc pas la valeur du standard. Elle empêche d’utiliser le texte comme preuve d’une exécution particulière. Une réponse syntaxiquement correcte ne démontre ni fsync, ni réplication, ni possibilité de reprise. Il faut conserver le handle de file, l’époque de configuration et, si le service le promet, la classe de durabilité atteinte avant le 250.

Cette séparation protège également les auteurs. Le nom de Klensin décrit une responsabilité éditoriale sur un texte de référence, pas une garantie commerciale donnée par chaque logiciel qui parle SMTP.

Relayer n’est pas déposer en boîte

La formule de la RFC contient une alternative essentielle : le serveur accepte de remettre ou relayer. Un relais peut n’avoir aucune visibilité sur la boîte finale. Il devient client d’une nouvelle transaction, choisit un prochain système et attend un autre reçu. Une nouvelle garde commence à chaque acceptation.

La trace Received aide à reconstituer les étapes. Elle indique les identités annoncées par l’émetteur et le récepteur ainsi qu’un horaire. Plusieurs relais ajoutent plusieurs lignes. Mais cette chaîne n’est pas un certificat cryptographique de remise. Elle ne prouve pas que la file suivante était durable, que l’alias s’est développé comme prévu ou que le fournisseur de boîte a rendu le message visible.

Même « remise finale » signifie, pour SMTP, que le message quitte l’environnement SMTP. Souvent il atteint l’utilisateur ou un mail drop associé ; parfois un autre système de messagerie continue le traitement. La fin d’un protocole ne coïncide pas nécessairement avec la fin de l’expérience humaine.

Un modèle honnête garde plusieurs états : accepté par ce hop, persisté localement, accepté par le hop suivant, remis à l’agent local, déposé dans la boîte, mis en quarantaine, rejeté par politique, accès utilisateur inconnu. Les systèmes fermés ne livreront pas tous ces faits. L’inconnu explicite vaut mieux qu’une certitude empruntée au dernier relais visible.

L’absence de retour n’est pas une confirmation

Lorsqu’un échec apparaît après acceptation, le récepteur doit normalement composer un message de notification vers le reverse-path de l’enveloppe. Cette notification porte elle-même un reverse-path nul afin d’éviter qu’un échec de notification n’engendre une boucle.

La voie négative peut pourtant manquer. Un message entrant avec un reverse-path nul ne recevra pas de notification SMTP. Un relais ne connaît pas forcément la validité finale d’un destinataire. Une liste ou une panne DNS temporaire reporte la décision. La RFC reconnaît aussi que, face aux abus, certaines politiques peuvent supprimer un message indésirable sans avertir le prétendu expéditeur.

« Aucun bounce » ne veut donc pas dire « remis ». Cela peut signifier succès, notification encore en file, adresse de retour inutilisable, passerelle opaque, suppression locale ou simple absence d’observation.

Les RFC 3461, 3463 et 3464 ajoutent les DSN comme preuve distincte. Elles permettent d’exprimer, par destinataire, des actions telles que failed, delayed, delivered, relayed et expanded. Une demande de DSN n’en garantit pas la production. relayed refuse justement de promettre la boîte finale ; delivered décrit un acte du système de messagerie, pas la lecture par une personne. Le rapport lui-même doit encore être transporté.

Le 250 final et le DSN ne doivent pas être fusionnés. Le premier désigne le détenteur de la responsabilité. Le second peut, plus tard, décrire un résultat en aval. Leur chronologie est une jointure, non un badge unique.

Une réponse perdue crée un doute à deux copies

Le récepteur enregistre correctement le message, envoie 250, puis la connexion casse avant que le client voie la réponse. Le récepteur possède une copie légitime. L’expéditeur, incapable de prouver l’acceptation, garde la sienne et réessaie. Deux livraisons deviennent possibles.

La RFC accorde un long délai à la terminaison de DATA, car le traitement peut être coûteux, et demande au récepteur de répondre aussi vite que raisonnable. Ce soin réduit l’ambiguïté sans pouvoir la supprimer : au point de passage, le dernier événement observé peut être le message ou son accusé.

Un timeout final n’est donc pas un rejet. Il est un état ambigu accompagné d’un risque de doublon. Le journal doit lier tentative originale, identifiant de message, perte de connexion, politique de retry et toute clé aval utile à la déduplication. Annoncer « non livré » serait aussi imprudent qu’annoncer « livré une seule fois ».

Les métriques héritent de cette limite. Le taux de 250 finaux mesure des transferts reconnus. Il ne mesure pas les boîtes atteintes et ne révèle pas, sans compteur séparé, les retries devenus doublons.

SMTP et LMTP ne dessinent pas le même reçu

SMTP accepte ou refuse chaque RCPT avant DATA, mais sa réponse finale porte sur la transaction acceptée comme un tout. Elle ne donne pas, après le corps, un verdict individuel à chaque destinataire.

LMTP change cette forme pour les remises locales. La RFC 2033 demande une réponse après le point final pour chaque commande RCPT précédemment acceptée, dans le même ordre. Une réponse positive transfère la responsabilité du destinataire correspondant.

Un collecteur doit connaître le protocole et la cardinalité. Transformer un seul 250 SMTP en plusieurs succès finaux par destinataire fabrique de la précision. Agréger une séquence LMTP en un seul résultat peut associer l’échec à la mauvaise adresse. Le reçu minimal conserve l’ordre des RCPT et rejoint explicitement les réponses locales.

Écrire un registre de garde

Le registre commence par une identité de connexion et de transaction. Il distingue l’authentification TLS de l’acceptation du message. Il garde MAIL FROM, chaque RCPT et sa réponse, l’ouverture DATA, la réponse finale, les timestamps et l’identifiant de file fourni par le serveur.

Après le transfert, le nouveau responsable ajoute l’état durable, les tentatives, le prochain hop, sa réponse et les déconnexions ambiguës. La remise locale ajoute le résultat de l’agent ou de LMTP. Un DSN ajoute Action et Status par destinataire, puis la preuve que ce rapport a lui-même quitté la file. Le spam, la quarantaine et la lecture restent inconnus sans système indépendant.

Cette discipline constitue une spécification minimale, pas une architecture imposée. Chaque opérateur garde ses choix de stockage, retry, confidentialité et rétention. La règle commune est plus modeste : ne jamais détacher la réponse de sa commande, ne jamais rebaptiser la garde « remise », ne jamais faire hériter au hop suivant la certitude du précédent.

La conclusion défendable devient alors : ce serveur a accepté cette enveloppe et ce contenu à la fin de DATA ; la responsabilité a changé de main ; voici les transitions observées ensuite ; voici les résultats par destinataire qui restent inconnus.

Sources