Delivery Status Notifications : le format des DSN (RFC 3464)

La RFC 3464 définit le format normalisé du message de rebond lisible par une machine : la Delivery Status Notification (DSN), ou notification d’état de livraison. Lorsqu’un message ne peut pas être livré (ou que sa livraison est retardée, ou qu’une notification positive demandée se déclenche), le MTA qui fait le rapport renvoie une DSN à l’expéditeur d’enveloppe. Tout processeur automatique de rebonds est, au fond, un analyseur de ce format, complété d’heuristiques pour le reste, qui n’est pas conforme.

Règles d’enveloppe

• Une DSN envoyée par SMTP DOIT utiliser une adresse de retour nulle : MAIL FROM:<>. Cela empêche les boucles de messagerie : aucune DSN n’est jamais générée pour une DSN.
• Corollaire pour les expéditeurs : les rebonds arrivent à l’adresse que vous avez indiquée dans le MAIL FROM du message d’origine. Utiliser une adresse de retour encodée par destinataire (VERP, par exemple bounces+user=example.com@sender.com) permet d’identifier le destinataire en échec même lorsque le corps de la DSN est mal formé, et permet à un processeur de feedback loop de réutiliser la même chaîne de suppression.
• Chaque destinataire indiqué par l’expéditeur DEVRAIT donner lieu à au plus une DSN « delivered » ou « failed ». Lorsqu’un message atteint un alias de liste de diffusion, le MTA de transfert DEVRAIT émettre une DSN « expanded » pour le destinataire d’origine et ne pas propager la demande de DSN aux adresses issues de l’expansion.

Structure générale : multipart/report

Une DSN est un message MIME Content-Type: multipart/report; report-type=delivery-status, qui contient :

La partie message/delivery-status est un ensemble de groupes de champs de type en-tête : un groupe par message, puis un groupe par destinataire pour chaque destinataire rapporté, chaque groupe étant séparé par une ligne vide.

Champs par message

Les noms de MTA sont sensibles à la casse ; leur orthographe doit être conservée exactement.

Champs par destinataire

Valeurs d’Action (exactement cinq, insensibles à la casse)

Status et Diagnostic-Code

• Status porte le code d’état étendu, indépendant du transport : c’est la clé de classement principale (4.x.x temporaire, 5.x.x définitif).
• Diagnostic-Code conserve l’erreur de transport brute ; le type smtp signifie que le texte est la réponse SMTP du serveur distant. La RFC note qu’il est « quelque peu redondant » avec Status, mais qu’il est fourni pour conserver l’information d’origine. Lorsque Remote-MTA est présent, le diagnostic vient de ce MTA ; sinon, du MTA qui fait le rapport. En pratique, le texte du diagnostic contient souvent des détails propres au fournisseur (noms de listes de blocage, URL de politique, « user unknown ») que le Status numérique ne donne pas : analysez les deux.

Conventions de type

• Les valeurs address-type, mta-name-type et diagnostic-type sont des atomes insensibles à la casse : les valeurs standard sont rfc822 (adresses), dns (noms de MTA), smtp (diagnostics) ; unknown quand le type ne peut pas être déterminé ; préfixe X- pour les types expérimentaux ; les nouveaux types sont enregistrés auprès de l’IANA.
• Le contenu qui suit le type peut être sensible à la casse (parties locales des boîtes aux lettres) et doit être conservé exactement.

Exemple (tiré de la RFC)

Reporting-MTA: dns; cs.utk.edu

Original-Recipient: rfc822;louisl@larry.slip.umd.edu
Final-Recipient: rfc822;louisl@larry.slip.umd.edu
Action: failed
Status: 4.0.0
Diagnostic-Code: smtp; 426 connection timed out
Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400

Conseils d’analyse pour les expéditeurs

1. Identifier le destinataire : privilégier Original-Recipient, à défaut Final-Recipient ; retirer le préfixe de type rfc822;. Si le corps est inexploitable, se rabattre sur l’adresse de retour encodée par VERP.
2. Filtrer sur Action : seul failed déclenche la suppression. Ignorer delayed pour l’hygiène de base de données (le journaliser pour la surveillance de la livraison) ; traiter delivered/relayed/expanded comme des non-rebonds.
3. Classer sur Status : 5.x.x → logique de rebond définitif, 4.x.x → compteurs de rebonds temporaires. Utiliser la table des codes de détail pour séparer les codes d’adresse invalide (à supprimer) des codes de politique ou de réputation (à investiguer : une vague de 5.7.1 est un problème d’expéditeur, pas un problème de liste).
4. Affiner sur Diagnostic-Code : des règles par expression régulière ou mot-clé sur le texte SMTP brut détectent les situations propres à un fournisseur que le code numérique masque (listes de blocage nommées, « spam content », avis de limitation de débit).
5. S’attendre à plusieurs groupes de destinataires par DSN : un seul message de rebond peut rapporter plusieurs destinataires ; traiter chaque groupe indépendamment.
6. S’attendre à la non-conformité : beaucoup de rebonds réels sont du texte libre sans aucune partie message/delivery-status. L’analyse RFC 3464 est la voie rapide ; gardez une solution de repli heuristique et VERP comme filet de sécurité.
7. Ne jamais répondre automatiquement à une DSN, et ne jamais envoyer vos propres rebonds avec une adresse de retour non nulle : c’est la règle MAIL FROM:<> qui préserve l’écosystème des boucles.