← RFC Reference

RFC 3462: Type de contenu Multipart/Report

Pourquoi cela existe

Quand le cadre DSN (Delivery Status Notification) a été créé au milieu des années 1990, les auteurs avaient besoin d'un conteneur MIME capable de transporter à la fois du contenu lisible par l'homme et du contenu lisible par la machine dans le même message. Un simple multipart/mixed fonctionnerait structurellement, mais il ne fournit aucun signal sémantique indiquant que le message est un rapport automatisé avec un format interne spécifique.

multipart/report résout cela en :

• Signalant aux clients de messagerie que le message est un rapport automatisé, permettant un traitement spécial de l'interface utilisateur (de nombreux clients affichent les rebonds différemment du courrier ordinaire)
• Incluant un paramètre report-type pour que les analyseurs sachent quel format lisible par la machine attendre à l'intérieur
• Définissant un ordre strict des parties : lisible par l'homme d'abord, lisible par la machine deuxième, message original troisième

RFC 3462 était la deuxième révision de cette spécification (après RFC 1892). Elle a été ensuite obsolète par RFC 6522, qui a resserré le langage et mis à jour l'enregistrement IANA. Le format réel sur le fil n'a pas changé — les messages conformes à RFC 3462 sont également conformes à RFC 6522.

Comment cela fonctionne

Le type de contenu multipart/report fonctionne comme tout multipart MIME, avec des contraintes supplémentaires :

Déclaration Content-Type

Content-Type: multipart/report; report-type=delivery-status;
    boundary="REPORT-BOUNDARY"

Le paramètre report-type indique au destinataire quel type de rapport c'est. Le paramètre boundary sépare les parties MIME, comme avec tout message multipart.

Structure à trois parties

--REPORT-BOUNDARY
Content-Type: text/plain

; Partie 1 : résumé lisible par l'homme
La livraison à user@example.org a échoué définitivement.
La boîte aux lettres du destinataire n'existe pas.

--REPORT-BOUNDARY
Content-Type: message/delivery-status

; Partie 2 : rapport lisible par la machine
Reporting-MTA: dns; mx.example.com

Final-Recipient: rfc822;user@example.org
Action: failed
Status: 5.1.1

--REPORT-BOUNDARY
Content-Type: text/rfc822-headers

; Partie 3 : en-têtes du message original (optionnel)
From: sender@example.com
To: user@example.org
Subject: Hello
Message-ID: <msg-001@example.com>

--REPORT-BOUNDARY--

Détails techniques clés

Types de rapports définis au fil du temps

Quand RFC 3462 a été publié, seul delivery-status existait. Les RFC ultérieures ont ajouté d'autres types de rapports qui utilisent tous le même conteneur multipart/report :

Parties minimales requises

RFC 3462 nécessite au minimum deux parties : le résumé lisible par l'homme et le rapport lisible par la machine. La troisième partie (message original) est optionnelle mais fortement recommandée pour les DSN, car elle permet à l'expéditeur d'identifier quel message a échoué.

Relation avec RFC 6522

RFC 6522 rend ce document obsolète. Les changements sont éditoriaux, pas comportementaux :

• Le paramètre report-type est explicitement marqué comme obligatoire (3462 était ambigu)
• Le modèle d'enregistrement IANA a été mis à jour aux normes actuelles
• La prise en charge des types de messages internationalisés (message/global) a été ajoutée

Si votre code gère déjà RFC 3462 correctement, il gère aussi RFC 6522. Le format sur le fil est inchangé.

Erreurs courantes

• Traiter la partie lisible par l'homme comme faisant autorité. La première partie est uniquement pour l'affichage. Les systèmes automatisés doivent analyser la deuxième partie (lisible par la machine). Le texte lisible par l'homme peut ne pas correspondre aux données structurées.
• Supposer seulement trois parties. Bien que la plupart des rapports aient exactement trois parties, la spécification en permet deux (pas de message original). Votre analyseur ne devrait pas échouer quand la troisième partie est absente.
• Ignorer multipart/report entièrement. Certains processeurs de rebond tentent d'analyser tous les messages de rebond sous forme de texte libre. Cela fonctionne mal. Vérifiez toujours d'abord multipart/report et utilisez les données structurées quand elles sont disponibles.
• Ne pas vérifier le report-type. Un multipart/report avec report-type=feedback-report est une plainte spam, pas un rebond. Le traiter comme un rebond (et supprimer l'adresse de votre liste) est incorrect — l'adresse est valide, le destinataire ne veut juste pas votre courrier.
• Générer des rapports sans la troisième partie. Bien que techniquement valide, omettre les en-têtes du message original rend beaucoup plus difficile pour l'expéditeur d'identifier quel message a déclenché le rapport. Incluez toujours au minimum les en-têtes.

Impact sur la livrabilité

• Tous les flux de rétroaction de courrier automatisé passent par ce format. Qu'il s'agisse d'un rebond, d'une plainte spam, d'un accusé de lecture ou d'un rapport TLS, le conteneur externe est multipart/report. Comprendre ce format est un prérequis pour traiter l'un d'eux.
• La classification correcte des rebonds commence ici. En vérifiant d'abord report-type, votre système peut acheminer les messages delivery-status vers votre processeur de rebond et les messages feedback-report vers votre gestionnaire de plaintes — deux flux de travail fondamentalement différents.
• Affichage du client de messagerie. De nombreux clients de messagerie reconnaissent multipart/report et le rendent spécialement (par exemple, en affichant une bannière « échec de la livraison »). Générer des rapports bien formés améliore l'expérience utilisateur quand votre serveur envoie des rebonds.
• Corrélation Message-ID. La troisième partie (message original ou en-têtes) est comment vous faites correspondre un rebond au message qui l'a causé. Sans cela, vous devenez deviner en fonction de l'adresse destinataire seule, ce qui n'est pas fiable avec le réacheminement et les alias.

Related RFCs