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

Pour traiter les rebonds automatiquement, vous devez lire le message de rebond lisible par une machine que renvoient les serveurs de messagerie. Lorsqu’un message ne peut pas être livré (ou que sa livraison est retardée, ou qu’une notification positive que vous avez demandée se déclenche), le MTA qui fait le rapport renvoie une Delivery Status Notification (DSN), ou notification d’état de livraison, à l’expéditeur d’enveloppe.

La RFC 3464 définit le format normalisé de ce message. Tout processeur automatique de rebonds est, au fond, un analyseur de ce format, complété d’heuristiques pour les rebonds qui ne le respectent pas.

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, car aucune DSN n’est jamais générée pour une DSN.
• Il s’ensuit que les rebonds arrivent à l’adresse que vous avez indiquée dans le MAIL FROM du message d’origine. Une adresse de retour qui encode chaque destinataire (VERP, par exemple bounces+user=example.com@sender.com) vous permet d’identifier le destinataire en échec même lorsque le corps de la DSN est mal formé. Elle permet aussi à 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 devrait pas transmettre la demande de DSN aux adresses issues de l’expansion.

Structure générale : multipart/report

Une DSN est un message MIME avec Content-Type: multipart/report; report-type=delivery-status. Elle contient :

La partie message/delivery-status est un ensemble de groupes de champs écrits comme des en-têtes : un groupe par message, puis un groupe par destinataire pour chaque destinataire rapporté. Une ligne vide sépare les groupes.

Champs par message

Les noms de MTA sont sensibles à la casse, et 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, qui ne dépend pas 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. Lorsque son type est smtp, 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, il vient 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, donc 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) et smtp (diagnostics). unknown sert quand le type ne peut pas être déterminé, le préfixe X- marque les types expérimentaux, et les nouveaux types sont enregistrés auprès de l’IANA.
• Le contenu qui suit le type peut être sensible à la casse (les parties locales des boîtes aux lettres, par exemple) 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. Identifiez le destinataire. Privilégiez Original-Recipient, et à défaut Final-Recipient. Retirez le préfixe de type rfc822;. Si le corps ne peut pas être analysé, rabattez-vous sur l’adresse de retour encodée par VERP.
2. Filtrez sur Action. Seul failed doit entraîner une suppression. Ignorez delayed pour l’hygiène de base de données, mais journalisez-le pour la surveillance de la livraison. Traitez delivered, relayed et expanded comme des messages qui ne sont pas des rebonds.
3. Classez sur Status. Envoyez 5.x.x vers votre logique de rebond définitif et 4.x.x vers vos compteurs de rebonds temporaires. Utilisez 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. Affinez sur Diagnostic-Code. Des règles par expression régulière ou par mot-clé, appliquées au 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. Attendez-vous à plusieurs groupes de destinataires dans une même DSN. Un seul message de rebond peut rapporter plusieurs destinataires, donc traitez chaque groupe séparément.
6. Attendez-vous à des rebonds qui ne respectent pas le format. Beaucoup de rebonds réels sont du texte libre sans aucune partie message/delivery-status. L’analyse selon la RFC 3464 est la voie rapide ; gardez une solution de repli heuristique, avec VERP comme filet de sécurité.
7. Ne répondez jamais automatiquement à une DSN, et n’envoyez jamais vos propres rebonds avec une adresse de retour non nulle. C’est la règle MAIL FROM:<> qui préserve l’écosystème de l’email des boucles.