← RFC Reference

RFC 6522：Multipart/Report 媒体类型（已更新）

这为什么存在

电子邮件生成许多类型的自动化报告：退信通知（RFC 3464）、垃圾邮件投诉（RFC 5965）、身份验证失败报告（RFC 6591）和 TLS 失败报告（RFC 8460）。所有这些都需要一个通用容器格式，既能携带人类可读的摘要，又能携带机器可解析的报告。

multipart/report 就是这样的容器。它最初在 RFC 3462 中定义，该规范本身更新了 RFC 1892。RFC 6522 是当前版本，使规范与现代 MIME 注册程序保持一致，并澄清了早期草案中的歧义。

从 RFC 3462 到 6522 的关键变化：

• 更新了 MIME 类型注册以遵循当前 IANA 模板格式
• 澄清了 report-type 参数是必需的，而非可选的
• 加强了规范语言以消除关于部分排序的歧义
• 与 RFC 6838 中更新的 MIME 框架保持一致

工作原理

multipart/report 消息是一个具有必需 report-type 参数的 MIME 多部分消息，该参数标识内部报告的类型。它按特定顺序包含两个或三个 MIME 部分：

1. 人类可读部分（text/plain 或 text/html）— 在邮件客户端中打开消息的人类摘要。
2. 机器可读报告 — 结构化数据。内容类型取决于 report-type：
   • delivery-status → message/delivery-status（RFC 3464）
   • feedback-report → message/feedback-report（RFC 5965）
   • tlsrpt → application/tlsrpt+json（RFC 8460）
3. 原始消息（可选）— 触发报告的消息的 message/rfc822（完整消息）或 text/rfc822-headers（仅标题）。

结构示例：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--

结构示例：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--

关键技术细节

report-type 参数

Content-Type 标题上的 report-type 参数是必需的，它告诉解析器在第二个 MIME 部分中预期什么类型的机器可读数据：

部分排序规则

• 第一部分必须始终是人类可读的（text/plain 或类似格式）。
• 第二部分必须是机器可读报告，其内容类型与 report-type 匹配。
• 可选的第三部分包含原始消息或其标题。它必须使用 message/rfc822、text/rfc822-headers 或 message/global（用于国际化消息）。

国际化

RFC 6522 添加了对 message/global 和 message/global-headers 的支持作为第三部分的替代方案，以根据 RFC 6531/6532 容纳国际化电子邮件地址和标题。

常见错误

• 遗漏 report-type 参数。没有 report-type，解析器无法确定第二个 MIME 部分包含的内容。RFC 6522 将此参数设为强制性；始终包含它。
• 部分顺序错误。某些实现将机器可读部分放在首位。人类可读部分必须放在首位，以便不理解报告类型的邮件客户端仍能显示有用的内容。
• 仅按 Content-Type 进行解析。不要尝试通过扫描第二部分的 Content-Type 来检测报告类型。使用外部 multipart/report Content-Type 上的 report-type 参数 — 这就是它的用途。
• 将 multipart/report 视为 multipart/mixed。虽然结构相似，但 multipart/report 具有严格的部分排序和语义。通用 MIME 解析器可能会显示它，但报告处理器必须尊重定义的结构。
• 混淆 RFC 3462 和 RFC 6522。它们定义相同的内容类型。RFC 6522 废弃 3462。如果在现有代码中看到对 RFC 3462 的引用，行为是等效的 — 但在新实现中引用 6522。

可传递性影响

• 所有电子邮件报告的基础。每个 DSN、ARF 投诉、DMARC 汇总报告和 TLS 失败报告都使用 multipart/report。如果解析器无法处理此容器，则无法处理任何自动化电子邮件反馈。
• 退信处理取决于正确的解析。退信处理器必须首先识别 multipart/report，然后检查 report-type=delivery-status，然后提取 message/delivery-status 部分。任何步骤出错都意味着退信丢失和列表卫生性下降。
• 投诉循环处理。来自邮箱提供商的反馈循环报告使用 report-type=feedback-report。正确解析容器是提取投诉数据和禁止收件人的第一步。
• TLS 报告。SMTP TLS 报告在 multipart/report 内传递 JSON 有效负载，带有 report-type=tlsrpt。这些报告揭示 TLS 协商失败，这些失败以静默方式阻止邮件安全传递。

Related RFCs