Résumé

  • Le courrier ordinaire indique un reverse-path pour les échecs ultérieurs. Une notification utilise MAIL FROM:<> afin que son propre échec ne réclame pas une nouvelle notification.
  • Le chemin nul est un état d’enveloppe explicite, non une absence de champ From:, une preuve d’anonymat ou une exemption de contrôle. La soumission doit le prendre en charge et SPF peut évaluer l’hôte par HELO.
  • Les DSN structurés ont ajouté corrélation et résultats par destinataire sans rouvrir la branche. Quand le signal distant s’arrête, le dernier échec reste une obligation locale.

Accepter un message, c’était hériter d’une promesse

Tant que le client SMTP est connecté, un serveur peut refuser un destinataire. Le code négatif rend l’échec dans la transaction même ; le client conserve la charge du message. Aucun nouveau courrier n’est nécessaire.

Après une réponse positive à DATA, le partage change. Le receiver a accepté le message et la responsabilité de le remettre, de le relayer ou de signaler ensuite l’impossibilité. Or une erreur peut n’apparaître qu’après : DNS temporairement défaillant, boîte supprimée, expansion d’une liste ou gateway incapable d’achever la remise.

Le signal doit alors devenir un message. Il est envoyé au reverse-path de l’enveloppe originale. Lui donner à son tour une adresse de retour ordinaire créerait une nouvelle promesse : en cas d’échec, produire encore un message. La fiabilité se transformerait en récursion.

RFC 821 identifia ce piège dès 1982. Il demanda de ne pas envoyer de notification à propos d’une notification et proposa le null reverse-path, écrit MAIL FROM:<>.

Les chevrons ne contiennent pas une mailbox vide. Ils déclarent qu’aucune destination distante ne doit recevoir un rapport de livraison pour cette transaction. Le message possède toujours un producteur, une connexion, des destinataires et des traces. Il n’a simplement pas de branche arrière.

L’absence devint obligatoire

RFC 1123 transforma la pratique en exigence : tout SMTP devait accepter le reverse-path vide. Rejeter sa syntaxe sous prétexte de « sender manquant » cassait les notifications conformes.

Le texte imposa l’autre moitié de la règle. Une notification produite après acceptation utilise <>. Si l’adresse à notifier est déjà nulle, le receiver ne doit pas générer de notification.

Les deux obligations sont indissociables. Reconnaître le chemin nul sans respecter son effet réactive la boucle. Refuser toute transaction nulle élimine la boucle en éliminant aussi les rapports légitimes. Le protocole exige de reconnaître un état spécial, puis de lui appliquer une politique spéciale.

L’enveloppe n’était pas la conversation humaine

MAIL FROM appartient au transport. Le champ visible From: indique l’auteur ou le service présenté au lecteur. Reply-To organise une éventuelle réponse humaine. Ces adresses peuvent être différentes sans contradiction.

Un message automatique peut donc afficher dans From: une adresse permettant de joindre le responsable du service, tout en portant MAIL FROM:<> dans l’enveloppe. Un humain peut signaler un dysfonctionnement ; un MTA ne doit pas fabriquer un DSN si cette réponse automatique ne se livre pas.

Une automatisation générique qui trouve l’enveloppe vide puis copie From: dans une réponse modifie l’allocation de responsabilité. Elle restaure la branche que le générateur avait fermée. La bonne interprétation de null n’est pas « chercher une valeur ailleurs », mais « ne pas créer ce type de réponse ».

Refuser tôt évitait un courrier supplémentaire

Le RFC 5321 consolide le passage de responsabilité après DATA. Quand une erreur est connue pendant la session, un refus immédiat informe le client réellement connecté et évite un nouveau message.

Cette préférence a une conséquence anti-backscatter. Un message hostile peut inscrire l’adresse d’une victime dans son reverse-path ordinaire. Si un serveur accepte puis produit une erreur plus tard, il envoie la notification à cette victime. Le null path de la notification empêchera une récursion supplémentaire, mais pas ce premier envoi mal orienté.

Le refus transactionnel, l’autorisation de l’hôte et le null sender protègent donc des frontières différentes. Le premier renvoie l’erreur au peer présent. La vérification réduit l’usurpation. Le troisième termine la branche de notification.

Certaines pannes restent tardives et rendent le DSN nécessaire. Le protocole ne remplace pas la réalité par une préférence. Il contient seulement le coût de la seconde histoire.

Le dernier échec ne devait pas être oublié

Un DSN avec <> peut lui-même devenir impossible à remettre. RFC 5321 interdit de relancer une notification distante, mais autorise log et transmission locale. Des systèmes peuvent remettre l’information à un postmaster capable de corriger la configuration.

C’est une différence de domaine d’autorité. Le rapport distant informe le détenteur du reverse-path original. L’alerte locale dit à l’opérateur du MTA que sa notification terminale n’a pas atteint son but. Elle doit employer un canal qui ne génère pas un nouveau DSN externe.

Null marque donc le terme d’une obligation distante, non la disparition de l’obligation. Les faits d’enveloppe, queue IDs, tentatives et résultats par destinataire doivent rester accessibles selon une politique proportionnée.

Les demandes de notification furent séparées

RFC 3461 ajouta l’extension SMTP DSN. ENVID sert à corréler l’enveloppe. RET règle la quantité de message original retournée. NOTIFY demande SUCCESS, FAILURE ou DELAY ; NEVER doit rester seul. ORCPT conserve l’adresse originale du destinataire.

Ces paramètres demandent un comportement de rapport ; ils ne doivent pas modifier l’acceptation d’un MAIL ou RCPT autrement valide. L’évidence et l’admission restent des surfaces distinctes.

L’extension interdit de produire un DSN pour une transaction dont le MAIL FROM était nul, même si un champ visible semble fournir un expéditeur. Deviner depuis le contenu contredirait le signal d’enveloppe. Le postmaster local peut recevoir une alerte qui ne rebondit pas.

Le DSN sortant utilise lui-même <>. Il ne porte pas RET et, si NOTIFY est présent, sa valeur doit être NEVER. Plus d’information n’accorde pas le droit de demander une réponse à l’information.

Le bounce devint un objet interprétable

RFC 3464 définit un DSN comme multipart/report de type delivery-status. Il peut associer une explication lisible, une partie message/delivery-status structurée et, dans les limites de retour et de confidentialité, une partie du message original.

Un DSN vise un seul message original mais décrit plusieurs destinataires séparément. Action distingue failed, delayed, delivered, relayed et expanded. Status, Reporting-MTA, Remote-MTA, Diagnostic-Code et les dates donnent aux logiciels un état plus précis que le texte libre.

Cette granularité empêche de traiter un succès partiel comme un échec global. Une liste peut agir sur l’abonné réellement défaillant ; un client peut garder un destinataire en attente et considérer un autre livré.

La forme ne prouve pas l’authenticité. Le RFC examine forge et confidentialité. Un DSN peut révéler des adresses, des redirections et du contenu, ou être imité. Les champs rendent une affirmation traitable ; ils ne lui donnent pas la non-répudiation.

Les robots de réponse héritèrent du même devoir

Un vacation responder, une liste et un service peuvent se répondre mutuellement. Ils peuvent aussi amplifier une requête dont l’adresse de retour a été forgée. RFC 3834 étend la discipline : aucun responder ne doit générer une réponse destinée à une adresse nulle.

Les réponses automatiques visent généralement Return-Path, non une adresse devinée dans From: ou Reply-To. Lorsqu’une réponse ne doit pas elle-même provoquer d’automatisme, elle peut utiliser MAIL FROM:<> et demander NOTIFY=NEVER.

Le bit terminal ne suffit pas contre l’amplification. Un service ne devrait pas envoyer de grosse réponse ni créer d’effet secondaire sans raison de croire que la partie affectée a autorisé la demande. Terminaison et consentement sont deux contrôles.

La soumission ne pouvait pas criminaliser null

RFC 6409 exige qu’un message submission agent ne refuse pas un message uniquement parce que son return path est nul. Des MUA légitimes génèrent notamment des notifications de disposition.

Le MSA conserve ses autres pouvoirs : authentifier le compte soumis, vérifier ses droits, limiter le débit et appliquer la politique de contenu. La règle interdit une équation simpliste entre valeur spéciale et abus.

RFC 7208 résout aussi le cas SPF. Avec un reverse-path nul, l’identité MAIL FROM est construite comme postmaster au domaine HELO. L’absence de mailbox ne supprime donc pas toute surface d’autorisation de l’hôte.

Ce résultat SPF ne prouve ni le contenu du DSN ni la panne racontée. Il exprime une autorisation host/domain. Un serveur autorisé peut se tromper ; un faux rapport peut voyager ailleurs. Le mécanisme montre seulement que null et identité ne sont pas synonymes.

Sources et limites de preuve

L’origine de MAIL FROM:<> et de la prévention de boucle figure dans RFC 821 : https://www.rfc-editor.org/rfc/rfc821.html

Le support obligatoire et l’interdiction de notifier null sont dans RFC 1123 : https://www.rfc-editor.org/rfc/rfc1123.html

Les paramètres DSN, NOTIFY=NEVER et la discipline d’enveloppe sont dans RFC 3461 : https://www.rfc-editor.org/rfc/rfc3461.html

Le format structuré et ses limites de sécurité/confidentialité sont dans RFC 3464 : https://www.rfc-editor.org/rfc/rfc3464.html

Les automatic responders sont traités dans RFC 3834 : https://www.rfc-editor.org/rfc/rfc3834.html

Le passage actuel de responsabilité et l’escalade locale sont dans RFC 5321 : https://www.rfc-editor.org/rfc/rfc5321.html

La légitimité du null sender à la soumission est dans RFC 6409 : https://www.rfc-editor.org/rfc/rfc6409.html

L’identité SPF fondée sur HELO est dans RFC 7208 : https://www.rfc-editor.org/rfc/rfc7208.html

Ces normes prouvent des contrats, non l’authenticité d’un DSN particulier ni l’état de tous les déploiements. Null n’est une preuve ni d’innocence ni d’abus. Aucun volume actuel de bounce, spam ou rejet n’est affirmé.