← RFC Reference

RFC 6522 : Type de média Multipart/Report (Mis à jour)

Pourquoi cela existe

Le courrier électronique génère de nombreux types de rapports automatisés : notifications de rebond (RFC 3464), plaintes de spam (RFC 5965), rapports d'échec d'authentification (RFC 6591), et rapports d'échec TLS (RFC 8460). Tous ceux-ci ont besoin d'un format de conteneur commun qui peut contenir à la fois un résumé lisible par l'homme et un rapport analysable par une machine.

multipart/report est ce conteneur. Il a été défini à l'origine dans la RFC 3462, qui a elle-même mis à jour la RFC 1892. La RFC 6522 est la version actuelle, mettant la spécification en conformité avec les procédures d'enregistrement MIME modernes et clarifiant les ambiguïtés des brouillons antérieurs.

Les changements clés de la RFC 3462 à la 6522 :

• Mise à jour de l'enregistrement du type MIME pour suivre le format de modèle IANA actuel
• Clarification que le paramètre report-type est obligatoire, non facultatif
• Resserrement du langage de spécification pour éliminer les ambiguïtés concernant l'ordre des parties
• Alignement avec le cadre MIME mis à jour de la RFC 6838

Comment cela fonctionne

Un message multipart/report est un message multipartite MIME avec un paramètre report-type obligatoire qui identifie le type de rapport à l'intérieur. Il contient deux ou trois parties MIME dans un ordre spécifique :

1. Partie lisible par l'homme (text/plain ou text/html) — un résumé pour les humains qui ouvrent le message dans un client de messagerie.
2. Rapport analysable par une machine — les données structurées. Le type de contenu dépend de report-type :
   • delivery-status → message/delivery-status (RFC 3464)
   • feedback-report → message/feedback-report (RFC 5965)
   • tlsrpt → application/tlsrpt+json (RFC 8460)
3. Message original (facultatif) — message/rfc822 (message complet) ou text/rfc822-headers (en-têtes uniquement) du message qui a déclenché le rapport.

Exemple de structure : rebond DSN

From: mailer-daemon@mail.example.org
To: sender@example.com
Subject: Delivery Status Notification (Failure)
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
    boundary="REPORT-BOUNDARY-001"

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

Your message to user@example.org could not be delivered.
The mailbox does not exist.

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

Reporting-MTA: dns; mail.example.org
Arrival-Date: Tue, 10 Mar 2026 14:22:00 -0500

Final-Recipient: rfc822;user@example.org
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp; 550 5.1.1 Mailbox not found

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

From: sender@example.com
To: user@example.org
Subject: Invoice #1234
Message-ID: <inv-1234@example.com>

--REPORT-BOUNDARY-001--

Exemple de structure : plainte ARF

Content-Type: multipart/report; report-type=feedback-report;
    boundary="ARF-BOUNDARY-001"

--ARF-BOUNDARY-001
Content-Type: text/plain

This is a spam complaint for a message from 203.0.113.10.

--ARF-BOUNDARY-001
Content-Type: message/feedback-report

Feedback-Type: abuse
User-Agent: FBL/1.0
Version: 1
Source-IP: 203.0.113.10

--ARF-BOUNDARY-001
Content-Type: message/rfc822

[original message]

--ARF-BOUNDARY-001--

Détails techniques clés

Le paramètre report-type

Le paramètre report-type sur l'en-tête Content-Type est obligatoire et indique aux analyseurs quel type de données analysables par machine attendre dans la deuxième partie MIME :

Règles d'ordre des parties

• La première partie doit toujours être lisible par l'homme (text/plain ou similaire).
• La deuxième partie doit être le rapport analysable par une machine avec le type de contenu correspondant à report-type.
• La troisième partie facultative contient le message original ou ses en-têtes. Elle doit utiliser message/rfc822, text/rfc822-headers, ou message/global (pour les messages internationalisés).

Internationalisation

La RFC 6522 ajoute le support de message/global et message/global-headers comme alternatives pour la troisième partie, pour accueillir les adresses e-mail et en-têtes internationalisés selon la RFC 6531/6532.

Erreurs courantes

• Omission du paramètre report-type. Sans report-type, les analyseurs ne peuvent pas déterminer ce que contient la deuxième partie MIME. La RFC 6522 rend ce paramètre obligatoire ; incluez-le toujours.
• Mauvais ordre des parties. Certaines implémentations mettent la partie analysable par une machine en premier. La partie lisible par l'homme doit venir en premier pour que les clients de messagerie qui ne comprennent pas le type de rapport affichent toujours quelque chose d'utile.
• Analyse uniquement par Content-Type. N'essayez pas de détecter le type de rapport en analysant le Content-Type de la deuxième partie. Utilisez le paramètre report-type sur le Content-Type multipart/report externe — c'est à cela qu'il sert.
• Traiter multipart/report comme multipart/mixed. Bien que structurellement similaire, multipart/report a un ordre et une sémantique des parties stricts. Un analyseur MIME générique peut l'afficher, mais un processeur de rapport doit respecter la structure définie.
• Confondre RFC 3462 et RFC 6522. Elles définissent le même type de contenu. La RFC 6522 rend obsolète la 3462. Si vous voyez des références à la RFC 3462 dans du code existant, le comportement est équivalent — mais citez la 6522 dans les nouvelles implémentations.

Impact sur la livraison

• Fondation de tous les rapports de courrier électronique. Chaque DSN, plainte ARF, rapport d'agrégat DMARC, et rapport d'échec TLS utilise multipart/report. Si votre analyseur ne peut pas gérer ce conteneur, vous ne pouvez traiter aucun retour de courrier électronique automatisé.
• Le traitement des rebonds dépend d'une analyse correcte. Votre processeur de rebond doit d'abord reconnaître multipart/report, puis vérifier report-type=delivery-status, puis extraire la partie message/delivery-status. Obtenir une étape fausse signifie des rebonds manqués et une hygiène de liste dégradée.
• Traitement de la boucle de plainte. Les rapports de boucle de rétroaction des fournisseurs de boîtes aux lettres utilisent report-type=feedback-report. L'analyse correcte du conteneur est la première étape pour extraire les données de plainte et supprimer les destinataires.
• Rapport TLS. SMTP TLS Reporting livre des charges JSON dans multipart/report avec report-type=tlsrpt. Ces rapports révèlent les échecs de négociation TLS qui empêchent silencieusement votre courrier d'être livré de manière sécurisée.

Related RFCs