Résumé

  • RFC 3461 permit au client SMTP de choisir les événements à notifier et de faire voyager un identifiant de transaction ainsi que l’adresse originale du destinataire. RFC 3464 donna au retour une forme exploitable destinataire par destinataire.
  • Le vocabulaire contient ses propres limites : delivered ne signifie pas « lu », relayed signale une perte de visibilité après un passage de relais, et le format structuré n’authentifie pas la notification.

Le message de non-remise traditionnel ressemblait à une lettre écrite par la machine qui avait renoncé. Son texte variait selon les logiciels ; il joignait parfois les en-têtes, parfois tout le courriel, parfois un diagnostic local incompréhensible ailleurs. Un humain pouvait en tirer une piste. Pour un agent de messagerie ou l’exploitant d’une grande liste, rattacher ce texte à une transaction, à un destinataire et à une étape du trajet restait fragile.

Cette fragilité touchait au partage de responsabilité de SMTP. Après une réponse positive à RCPT, un serveur accepte normalement de livrer ou de signaler l’échec ultérieur. Mais le mot « signaler » ne dit pas si l’expéditeur souhaite connaître la réussite, l’échec, un retard prolongé ou rien du tout. Il ne préserve pas non plus spontanément l’adresse initiale lorsqu’un transfert la réécrit.

Les RFC 3461, 3463 et 3464, publiées en janvier 2003, ont séparé ces problèmes. La première porte la demande dans l’enveloppe SMTP, la deuxième décrit le rapport, la troisième fournit des codes d’état indépendants du transport. Ensemble, elles ne promettent pas la livraison : elles définissent qui peut demander une trace, qui peut déclarer une action et où cette déclaration cesse d’être probante.

Quatre paramètres pour quatre décisions

Le serveur annonce l’extension avec le mot-clé DSN dans sa réponse EHLO. Aucun nouveau verbe n’est créé. MAIL reçoit RET et ENVID, tandis que RCPT reçoit NOTIFY et ORCPT.

NOTIFY s’applique à un destinataire. L’expéditeur peut combiner SUCCESS, FAILURE et DELAY, ou demander NEVER, qui doit rester seul. En l’absence du paramètre, le serveur peut conserver la pratique d’une notification d’échec, éventuellement accompagnée d’un avis de retard. C’est une préférence de preuve, non une commande sur le résultat.

Le cas du retard est révélateur. DELAY n’impose aucun délai chiffré. Le MTA qui retient le message décide quand l’attente devient anormale, alors que l’issue demeure inconnue. Une même condition temporaire en 4.x.x peut donc produire d’abord l’action delayed, puis failed si la file abandonne après de nouvelles tentatives.

RET=FULL demande que le contenu entier accompagne un rapport d’échec ; RET=HDRS limite le retour aux en-têtes. Sans destinataire en échec, seuls les en-têtes devraient revenir. Le choix arbitre entre diagnostic et confidentialité : recopier le corps dans un nouveau message élargit sa circulation.

Deux identifiants empêchaient une fausse fusion

ENVID nomme la transaction d’enveloppe. S’il est présent, il revient comme Original-Envelope-Id. Le système postal n’en interprète pas la valeur ; seul l’expéditeur ou son logiciel lui donne un sens. Il ne faut pas le confondre avec Message-Id, qui identifie le contenu. Un contenu peut être soumis plusieurs fois, et une transaction peut contenir plusieurs destinataires dont les destins divergent.

ORCPT conserve l’adresse de destinataire donnée par l’expéditeur. Lors de la première soumission, elle correspond à RCPT TO. Après un transfert, l’adresse opérationnelle peut changer tandis que l’adresse originale subsiste. L’une décrit la prochaine destination ; l’autre rattache la preuve au destinataire que l’expéditeur croyait viser.

Le couple autorise une réconciliation en deux temps : retrouver la transaction, puis le destinataire concerné. Il ne constitue aucune preuve d’identité. Une valeur ENVID plausible n’authentifie pas la source du rapport, et ORCPT ne démontre pas qu’une personne contrôle l’adresse. Ce sont des poignées de corrélation que chaque relais doit préserver.

L’action n’était pas la cause

Une DSN est un multipart/report. Sa première partie s’adresse à l’humain ; la deuxième, message/delivery-status, contient d’abord des champs communs au message, puis un groupe par destinataire. Une troisième partie peut restituer les en-têtes ou le message original.

Chaque groupe de destinataire porte une Action parmi cinq valeurs. failed indique que les tentatives sont abandonnées. delayed signifie qu’elles continuent. delivered est terminal pour ce destinataire, mais inclut la remise à un distributeur de liste et n’atteste jamais la lecture. expanded décrit l’acceptation par un alias qui a créé plusieurs nouvelles destinations ; des avis ultérieurs restent possibles.

relayed trace la frontière la plus importante. Le message a été remis ou converti vers un environnement qui n’assume pas la production d’une DSN de réussite. Le MTA sait prouver son passage de témoin, pas l’arrivée finale. Le protocole préfère déclarer cette perte de visibilité plutôt que fabriquer un succès.

À côté de l’action, Status emploie les codes de RFC 3463 : 2.x.x pour le succès, 4.x.x pour l’échec transitoire persistant, 5.x.x pour l’échec permanent, avec sujet et détail. Une condition 4.x.x peut accompagner delayed ou failed. Le code décrit l’état rencontré ; l’action décrit la décision opérationnelle prise à son égard.

Une notification ne devait pas engendrer sa descendante

La DSN voyage elle-même par courrier et peut échouer. Si cet échec déclenchait une nouvelle DSN, deux systèmes injoignables pourraient produire une boucle de rapports sur les rapports. RFC 3464 impose donc le chemin de retour nul MAIL FROM:<> à toute DSN envoyée par SMTP. L’échec du rapport reste silencieux sur le réseau.

La stabilité exige ici de renoncer à une visibilité récursive. L’expéditeur peut ignorer que son avis a disparu. Cette ignorance bornée vaut mieux qu’une amplification infinie.

Les passerelles dessinent une autre limite. Entre deux MTA compatibles, paramètres et identifiants doivent être relayés. Dans un environnement étranger, la traduction n’est qu’un meilleur effort. Les formes d’adresse, les diagnostics et la responsabilité de notifier peuvent différer. La confidentialité peut aussi justifier de masquer une adresse de transfert, d’omettre des champs distants ou d’arrêter les notifications positives.

Structurer une preuve ne la rend pas authentique

RFC 3464 avertit qu’une DSN se falsifie aussi facilement qu’un courriel ordinaire. Une fausse réussite peut interrompre une escalade ; un faux échec peut provoquer une nouvelle tentative, la radiation d’une liste ou une décision de support erronée. ENVID facilite le rapprochement, mais n’ajoute aucune signature cryptographique.

Le contenu retourné mérite la même prudence. FULL peut reproduire un message sensible sur un chemin, dans des journaux et dans des boîtes différents de l’original. Même les en-têtes révèlent correspondants, sujet et acheminement. Le protocole offre le choix, pas le contrôle absolu de la copie.

L’apport historique de DSN est donc une discipline de portée. L’expéditeur choisit les rapports et les identifiants. Le MTA décide d’accepter, de réessayer ou d’abandonner, puis décrit son action. La passerelle traduit ce qu’elle peut. Le transfert confidentiel peut fermer le rideau. La lecture par un humain reste entièrement hors de SMTP.

Le registre SMTP de l’IANA rattache toujours DSN à RFC 3461. Le récépissé est devenu plus précis parce qu’il sait nommer ses limites : transaction, destinataire original, système rapporteur, action, condition et frontière d’observation. Il aide à piloter les files et à rapprocher les incidents ; il ne promet ni placement en boîte de réception, ni attention humaine, ni vérité au-delà du dernier témoin.

Sources