非官方中文译本声明：本页为 IETF RFC 6522《The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages》 的非官方中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布、不受版权限制；依据 BCP 78，本译本为署名翻译作品，译文力求忠实但不构成官方版本，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc6522。

RFC 6522《Multipart/Report：邮件系统管理报告媒体类型》中文译本

IETF · RFC 6522 · 互联网标准（STD 73）· 2012 年 1 月

文档头信息

Internet Engineering Task Force (IETF)；Request for Comments: 6522；STD: 73；废止（Obsoletes）：RFC 3462；类别（Category）：标准跟踪（Standards Track）；ISSN: 2070-1721。编者：M. Kucherawy（Cloudmark），2012 年 1 月。

摘要

multipart/report 这一多用途互联网邮件扩展（MIME）媒体类型，是面向各类电子邮件报告的通用「家族」类型或「容器」类型。尽管本备忘录仅定义了 multipart/report 媒体类型在投递状态报告方面的用法，但若所有种类的报告都采用同一个媒体类型，邮件处理程序将从中获益。

本备忘录废止《The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages》（RFC 3462），并将 RFC 3462 及其前身标记为「历史性（Historic）」文档。

本备忘录的状态

本文档是互联网标准跟踪文档（Internet Standards Track document）。

本文档是互联网工程任务组（IETF）的产物，代表 IETF 社区的共识。它已经过公开评审，并获互联网工程指导组（IESG）批准发布。关于互联网标准的更多信息参见 RFC 5741 第 2 节。

有关本文档当前状态、任何勘误以及如何对其提供反馈的信息，可访问 http://www.rfc-editor.org/info/rfc6522 获取。

版权声明

本文档受 BCP 78 及 IETF Trust 关于 IETF 文档的法律条款（http://trustee.ietf.org/license-info）约束，以本文档发布之日生效的版本为准。请仔细阅读这些文件，其中描述了您对本文档所享有的权利与所受的限制。从本文档中提取的代码组件（Code Components）必须包含《Trust 法律条款》第 4.e 节所述的「简化 BSD 许可证」文本，且按该许可证的规定不附带任何担保。

本文档可能包含自 2008 年 11 月 10 日之前发布或公开的 IETF 文档或 IETF 贡献中的材料。控制这些材料版权的人员可能未授予 IETF Trust 在 IETF 标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，本文档不得在 IETF 标准流程之外被修改，其衍生作品也不得在 IETF 标准流程之外被创建，除非是为了将其格式化以作为 RFC 发布，或将其翻译为英语以外的语言。

1. 引言

[OLD-REPORT] 及其前身声明了 multipart/report 媒体类型，用于在 [MIME] 构造中创建一个容器，以承载各类邮件系统管理报告。

实践经验表明，要求该媒体类型只能用作报文最外层 MIME 类型的这一普遍性约束过于严格，它限制了诸如「在单个总体报文容器中传输多份管理报告」之类的做法。特别是，它使人无法将一份报告作为另一封 multipart MIME 报文的组成部分进行转发。

本备忘录取消了该约束。除若干编辑性修改外，未作其他变更。其他备忘录可以更新其他文档，以便在确有需要的场景中确立或澄清 multipart/report 的使用约束。

本备忘录废止 RFC 3462。RFC 3462 及其前身 RFC 1892 已被标记为「历史性（Historic）」。

2. 文档约定

本文档中的关键词「必须（MUST）」「不得（MUST NOT）」「必需（REQUIRED）」「应当（SHALL）」「不应当（SHALL NOT）」「应该（SHOULD）」「不应该（SHOULD NOT）」「推荐（RECOMMENDED）」「可以（MAY）」和「可选（OPTIONAL）」，应按 [KEYWORDS] 中的描述进行解释。

3. multipart/report 媒体类型

multipart/report 这一 MIME 媒体类型，是面向各类电子邮件报告的通用「家族」类型或「容器」类型。尽管本备忘录仅定义了 multipart/report 媒体类型在投递状态报告方面的用法，但若所有种类的报告都采用同一个媒体类型，邮件处理程序将从中获益。

依据 [MIME-REG]，multipart/report 媒体类型定义如下（注册模板保留英文原文）：

Type name:  multipart

Subtype name:  report

Required parameters:  boundary, report-type

Optional parameters:  none

Encoding considerations:  7bit should always be adequate

Security considerations:  see Section 7 of [RFC6522]

Interoperability considerations:  see Section 1 of [RFC6522]

Published specification:  [RFC6522]

Applications that use this media type:  Mail Transfer Agents, Mail
   User Agents, spam detection and reporting modules, virus detection
   modules, and message authentication modules.

Additional information:

   Magic number(s):  N/A

   File extension(s):  N/A

   Macintosh file type code(s):  N/A

Person and email address to contact for further information:  Murray
   S. Kucherawy <msk@cloudmark.com>

Intended usage:  common

Restrictions on usage:  none; however, other applications that
   register report types may establish such restrictions.

Author:  Murray S. Kucherawy <msk@cloudmark.com>

Change controller:  IESG

multipart/report 的语法与 [MIME] 中定义的 multipart/mixed 内容类型完全相同。report-type 参数标识报告的类型。该参数的取值即 multipart/report 第二个体部（body part）的 MIME 子类型。（参见第 5 节。）

multipart/report 媒体类型按以下顺序包含两个或三个子部：

1.（必需 REQUIRED）第一个体部包含一段人类可读的消息。该消息的目的，是为那些可能没有能够解释 multipart/report 第二部分的用户代理的人类读者，提供一段易于理解的说明，描述导致生成该报告的状况。第一部分中的文本可以使用任何在 IANA 注册的 MIME 媒体类型、字符集或语言。当希望以多种语言或多种媒体形式给出错误描述时，可以（MAY）使用 multipart/alternative 构造。该体部也可以（MAY）用于发送那些难以格式化进第二个体部的详细信息。
2.（必需 REQUIRED）一个机器可解析的体部，其中包含对所报告的报文处理事件的记述。该体部的目的，是提供导致生成该报告的状况的机器可读描述，以及第一个体部中不存在、但可能对人类专家有用的细节。[DSN-FORMAT] 中定义了一个初始体部类型 message/delivery-status。
3.（可选 OPTIONAL）一个体部，包含被退回的原始报文或其中的一部分。该信息可能有助于人类专家诊断问题。（尽管它也可能有助于发送方识别该报告所针对的报文，但人们希望 message/report 体部中返回的 envelope-id 与 original-recipient-address 能够取代传统上为此目的而返回内容的做法。）

返回内容可能浪费网络带宽，可以采用多种实现策略。通常，发送方需要选择合适的策略，并将所要求的内容返回级别告知接收方。在没有诸如 [DSN-SMTP] 所提供的那种「显式的内容返回级别请求」的情况下，生成投递服务报告的代理应该（SHOULD）返回完整的报文内容。

当需要返回未以 7 位形式编码的 8 位或二进制数据，而返回路径又不能保证具备 8 位或二进制传输能力时，有两种可选方案：可以（MAY）将原始报文重新编码为合法的 7 位 MIME 报文，或者可以（MAY）使用 text/rfc822-headers 媒体类型，仅返回原始报文的信头。

4. text/rfc822-headers 媒体类型

text/rfc822-headers 媒体类型提供了一种机制，用于标记并仅返回失败报文的 [MAIL] 信头。信头并非完整报文，因此不应该（SHOULD NOT）使用 [MIME-TYPES] 中定义的 message/rfc822 媒体类型来返回。返回的信头有助于识别失败的报文，并可基于 Received 信头字段进行诊断。

text/rfc822-headers 媒体类型定义如下（注册模板保留英文原文）：

Type name:  text

Subtype name:  rfc822-headers

Required parameters:  None

Optional parameters:  None

Encoding considerations:  7-bit is sufficient for normal mail
   headers, however, if the headers are broken or extended and
   require encoding to make them legal 7-bit content, they MAY be
   encoded with quoted-printable as defined in [MIME].

Security considerations:  See Section 7 of [RFC6522].

Interoperability considerations:  none

Published specification:  [RFC6522]

Applications that use this media type:  Mail Transfer Agents, Mail
   User Agents, spam detection and reporting modules, virus detection
   modules, and message authentication modules.

Additional information:

   Magic number(s):  N/A

   File extension(s):  N/A

   Macintosh file type code(s):  N/A

Person and email address to contact for further information:  Murray
   S. Kucherawy <msk@cloudmark.com>

Intended usage:  common

Restrictions on usage:  none

Author:  Murray S. Kucherawy <msk@cloudmark.com>

Change controller:  IESG

text/rfc822-headers 体部应该（SHOULD）包含引发该报告的那封报文的全部邮件信头字段。信头包括报文中第一个空行之前的所有信头字段，其中含 MIME-Version 以及各 MIME 内容描述字段。

5. 注册新的报告类型

为创建一种新的报告格式而注册新的媒体类型时，应该（SHOULD）在该媒体类型注册的 Intended Usage（预期用途）一节中注明：所注册的类型适合在本规范的语境下用作 report-type（即第二个体部）。

6. IANA 考量

IANA 已更新媒体类型注册表（Media Type Registry），以表明本备忘录包含 multipart/report 与 text/rfc822-headers 两个媒体类型的当前定义，并废止 [OLD-REPORT]。

7. 安全性考量

在不进行认证的情况下自动化使用报告类型会带来若干安全问题。当报告被用于目录或邮件列表的自动化维护时，伪造否定性报告将带来拒绝服务攻击的机会；而伪造肯定性报告则可能使发送方错误地认为某封报文已被投递，而事实上并未投递。

可以使用一个覆盖整个 multipart/report 结构的签名来防止此类伪造；但此类签名方案超出了本文档的范围。

8. 参考文献

8.1. 规范性参考文献

[KEYWORDS]    Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

[MAIL]        Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008.

[MIME]        Freed, N. and N. Borenstein, "Multipurpose Internet
              Mail Extensions (MIME) Part One: Format of Internet
              Message Bodies", RFC 2045, November 1996.

[MIME-REG]    Freed, N. and J. Klensin, "Media Type Specifications
              and Registration Procedures", BCP 13, RFC 4288,
              December 2005.

[MIME-TYPES]  Freed, N. and N. Borenstein, "Multipurpose Internet
              Mail Extensions (MIME) Part Two: Media Types",
              RFC 2046, November 1996.

8.2. 资料性参考文献

[DSN-FORMAT]  Moore, K. and G. Vaudreuil, "An Extensible Message
              Format for Delivery Status Notifications", RFC 3464,
              January 2003.

[DSN-SMTP]    Moore, K., "Simple Mail Transfer Protocol (SMTP)
              Service Extension for Delivery Status Notifications
              (DSNs)", RFC 3461, January 2003.

[OLD-REPORT]  Vaudreuil, G., "The Multipart/Report Content Type for
              the Reporting of Mail System Administrative Messages",
              RFC 3462, January 2003.

附录 A. 致谢

作者谨感谢 Dave Crocker、Frank Ellermann、Ned Freed、Randall Gellens、Alexey Melnikov 和 Keith Moore 为本次更新提供的意见。

同时感谢该媒体类型的最初创建者 Gregory M. Vaudreuil。

作者地址

Murray S. Kucherawy (editor)
Cloudmark
128 King St., 2nd Floor
San Francisco, CA  94107
US

Phone: +1 415 946 3800
EMail: msk@cloudmark.com