Internet Engineering Task Force (IETF) M. Kucherawy, Ed.
Request for Comments: 6522 Cloudmark
STD: 73 January 2012
Obsoletes: 3462
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. Kucherawy, Ed.
Request for Comments: 6522 Cloudmark
STD: 73 January 2012
Obsoletes: 3462
Category: Standards Track
ISSN: 2070-1721
The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages
用于报告邮件系统管理邮件的多部分/报告媒体类型
Abstract
摘要
The multipart/report Multipurpose Internet Mail Extensions (MIME) media type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the multipart/report media type with respect to delivery status reports, mail processing programs will benefit if a single media type is used for all kinds of reports.
多部分/报告多用途Internet邮件扩展（MIME）媒体类型是任何类型电子邮件报告的通用“系列”或“容器”类型。尽管本备忘录仅定义了多部分/报告介质类型在传递状态报告中的使用，但如果将单一介质类型用于所有类型的报告，邮件处理程序将受益匪浅。
This memo obsoletes "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, and marks RFC 3462 and its predecessor as "Historic".
本备忘录废除了“用于报告邮件系统管理消息的多部分/报告内容类型”RFC 3462，并将RFC 3462及其前身标记为“历史”。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6522.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6522.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Document Conventions ............................................3
3. The Multipart/Report Media Type .................................3
4. The text/rfc822-headers Media Type ..............................5
5. Registering New Report Types ....................................7
6. IANA Considerations .............................................7
7. Security Considerations .........................................7
8. References ......................................................7
8.1. Normative References .......................................7
8.2. Informative References .....................................8
Appendix A. Acknowledgements ......................................9
1. Introduction ....................................................3
2. Document Conventions ............................................3
3. The Multipart/Report Media Type .................................3
4. The text/rfc822-headers Media Type ..............................5
5. Registering New Report Types ....................................7
6. IANA Considerations .............................................7
7. Security Considerations .........................................7
8. References ......................................................7
8.1. Normative References .......................................7
8.2. Informative References .....................................8
Appendix A. Acknowledgements ......................................9
[OLD-REPORT] and its antecedent declared the multipart/report media type for use within the [MIME] construct to create a container for mail system administrative reports of various kinds.
[OLD-REPORT]及其前身声明了在[MIME]构造中使用的multipart/REPORT媒体类型，以创建各种邮件系统管理报告的容器。
Practical experience has shown that the general requirement of having that media type constrained to be used only as the outermost MIME type of a message is overly restrictive and limits such things as the transmission of multiple administrative reports within a single overall message container. In particular, it prevents one from forwarding a report as part of another multipart MIME message.
实践经验表明，将该媒体类型限制为仅用作消息的最外层MIME类型的一般要求过于严格，并限制了在单个整体消息容器中传输多个管理报告。特别是，它可以防止将报告作为另一个多部分MIME消息的一部分转发。
This memo removes that constraint. No other changes apart from some editorial ones are made. Other memos might update other documents to establish or clarify the constraints on use of multipart/report in contexts where such are needed.
这份备忘录消除了这种限制。除了一些编辑上的改动外，没有其他改动。其他备忘录可能会更新其他文件，以确定或澄清在需要的情况下使用多部分/报告的限制。
This memo obsoletes RFC 3462. RFC 3462 and its predecessor, RFC 1892, have been marked as "Historic".
本备忘录废除RFC 3462。RFC 3462及其前身RFC 1892被标记为“历史”。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
The multipart/report MIME media type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the multipart/report media type with respect to delivery status reports, mail processing programs will benefit if a single media type is used for all kinds of reports.
多部分/报告MIME媒体类型是任何类型电子邮件报告的通用“系列”或“容器”类型。尽管本备忘录仅定义了多部分/报告介质类型在传递状态报告中的使用，但如果将单一介质类型用于所有类型的报告，邮件处理程序将受益匪浅。
Per [MIME-REG], the multipart/report media type is defined as follows:
根据[MIME-REG]，多部分/报告介质类型定义如下：
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]
安全注意事项：见[RFC6522]第7节
Interoperability considerations: see Section 1 of [RFC6522]
互操作性注意事项：见[RFC6522]第1节
Published specification: [RFC6522]
已发布规范：[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
Magic number(s): N/A
File extension(s): N/A
File extension(s): N/A
Macintosh file type code(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>
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>
Author: Murray S. Kucherawy <msk@cloudmark.com>
Change controller: IESG
更改控制器：IESG
The syntax of multipart/report is identical to the multipart/mixed content type defined in [MIME]. The report-type parameter identifies the type of report. The parameter is the MIME subtype of the second body part of the multipart/report. (See Section 5.)
multipart/report的语法与[MIME]中定义的multipart/mixed内容类型相同。报告类型参数标识报告的类型。该参数是多部分/报表的第二个主体部分的MIME子类型。（见第5节。）
The multipart/report media type contains either two or three sub-parts, in the following order:
多部分/报告介质类型包含两个或三个子部分，顺序如下：
1. (REQUIRED) The first body part contains a human-readable message. The purpose of this message is to provide an easily understood description of the condition(s) that caused the report to be generated, for a human reader who might not have a user agent capable of interpreting the second section of the multipart/ report. The text in the first section can use any IANA-registered MIME media type, charset, or language. Where a description of the error is desired in several languages or
1. （必需）第一身体部分包含人类可读的消息。此消息的目的是为可能没有能够解释多部分/报告第二部分的用户代理的人类读者提供导致生成报告的条件的易于理解的描述。第一节中的文本可以使用任何IANA注册的MIME媒体类型、字符集或语言。需要用多种语言或语言描述错误的情况
several media, a multipart/alternative construct MAY be used. This body part MAY also be used to send detailed information that cannot be easily formatted into the second body part.
在多个介质中，可使用多部分/替代结构。此正文部分还可用于发送无法轻松格式化为第二正文部分的详细信息。
2. (REQUIRED) A machine-parsable body part containing an account of the reported message handling event. The purpose of this body part is to provide a machine-readable description of the condition(s) that caused the report to be generated, along with details not present in the first body part that might be useful to human experts. An initial body part, message/delivery-status, is defined in [DSN-FORMAT].
2. （必需）包含报告的消息处理事件的帐户的机器可解析主体部分。本身体部位的目的是提供导致生成报告的条件的机器可读描述，以及第一身体部位中不存在的可能对人类专家有用的细节。初始正文部分消息/传递状态在[DSN-FORMAT]中定义。
3. (OPTIONAL) A body part containing the returned message or a portion thereof. This information could be useful to aid human experts in diagnosing problems. (Although it might also be useful to allow the sender to identify the message about which the report was issued, it is hoped that the envelope-id and original-recipient-address returned in the message/report body part will replace the traditional use of the returned content for this purpose.)
3. （可选）包含返回消息或其一部分的主体部分。这些信息有助于人类专家诊断问题。（虽然允许发件人识别报告发布的邮件可能也很有用，但希望邮件/报告正文部分中返回的信封id和原始收件人地址将取代为此目的返回内容的传统用法。）
Return of content can be wasteful of network bandwidth and a variety of implementation strategies can be used. Generally, the sender needs to choose the appropriate strategy and inform the recipient of the required level of returned content required. In the absence of an explicit request for level of return of content such as that provided in [DSN-SMTP], the agent that generated the delivery service report SHOULD return the full message content.
返回内容可能会浪费网络带宽，并且可以使用多种实现策略。通常，发送方需要选择适当的策略，并通知接收方所需的返回内容级别。如果没有明确的内容返回级别请求（如[DSN-SMTP]中提供的内容），则生成传递服务报告的代理应返回完整的邮件内容。
When 8-bit or binary data not encoded in a 7-bit form is to be returned, and the return path is not guaranteed to be 8-bit or binary capable, two options are available. The original message MAY be re-encoded into a legal 7-bit MIME message or the text/rfc822-headers media type MAY be used to return only the original message headers.
如果要返回未以7位形式编码的8位或二进制数据，并且不能保证返回路径支持8位或二进制，则有两个选项可用。原始消息可以重新编码为合法的7位MIME消息，或者可以使用text/rfc822 headers媒体类型仅返回原始消息头。
The text/rfc822-headers media type provides a mechanism to label and return only the [MAIL] header of a failed message. The header is not the complete message and SHOULD NOT be returned using the message/ rfc822 media type defined in [MIME-TYPES]. The returned header is useful for identifying the failed message and for diagnostics based on the Received header fields.
text/rfc822 headers媒体类型提供了一种机制，用于标记并仅返回失败邮件的[MAIL]头。标头不是完整的消息，不应使用[MIME-TYPES]中定义的消息/rfc822媒体类型返回。返回的报头对于识别失败消息和基于接收到的报头字段进行诊断非常有用。
The text/rfc822-headers media type is defined as follows:
text/rfc822 headers媒体类型定义如下：
Type name: text
类型名称：text
Subtype name: rfc822-headers
子类型名称：rfc822标头
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].
编码注意事项：对于普通邮件头，7位就足够了，但是，如果邮件头被破坏或扩展，并且需要编码使其成为合法的7位内容，则可以使用[MIME]中定义的带引号的可打印内容对其进行编码。
Security considerations: See Section 7 of [RFC6522].
安全注意事项：见[RFC6522]第7节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: [RFC6522]
已发布规范：[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
Magic number(s): N/A
File extension(s): N/A
File extension(s): N/A
Macintosh file type code(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>
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>
Author: Murray S. Kucherawy <msk@cloudmark.com>
Change controller: IESG
更改控制器：IESG
The text/rfc822-headers body part SHOULD contain all the mail header fields from the message that caused the report. The header includes all header fields prior to the first blank line in the message. They include the MIME-Version and MIME content description fields.
text/rfc822 headers正文部分应包含导致报告的邮件中的所有邮件头字段。标题包括消息中第一个空行之前的所有标题字段。它们包括MIME版本和MIME内容描述字段。
Registration of new media types for the purpose of creating a new report format SHOULD note in the Intended Usage section of the media type registration that the type being registered is suitable for use as a report-type (i.e., the second body part) in the context of this specification.
为创建新报告格式而注册的新媒体类型应在媒体类型注册的预期用途部分注意，注册的类型适合用作本规范上下文中的报告类型（即第二正文部分）。
IANA has updated the Media Type Registry to indicate that this memo contains the current definition of the multipart/report and text/ rfc822-headers media types, obsoleting [OLD-REPORT].
IANA已更新了媒体类型注册表，以表明此备忘录包含多部分/报告和文本/rfc822标题媒体类型的当前定义，淘汰了[OLD-report]。
Automated use of report types without authentication presents several security issues. Forging negative reports presents the opportunity for denial-of-service attacks when the reports are used for automated maintenance of directories or mailing lists. Forging positive reports can cause the sender to incorrectly believe a message was delivered when it was not.
在不进行身份验证的情况下自动使用报表类型会带来几个安全问题。伪造负面报告在报告用于目录或邮件列表的自动维护时，会带来拒绝服务攻击的机会。伪造正面报告可能会导致发件人错误地认为邮件在未送达时已送达。
A signature covering the entire multipart/report structure could be used to prevent such forgeries; such a signature scheme is, however, beyond the scope of this document.
覆盖整个多部分/报告结构的签名可用于防止此类伪造；然而，这种签名方案超出了本文件的范围。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[邮件]Resnick，P.，Ed.，“互联网信息格式”，RFC5322，2008年10月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[MIME-REG] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[MIME-REG]Freed，N.和J.Klensin，“媒体类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[MIME-TYPES] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[MIME-TYPES]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[DSN-FORMAT] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[DSN-FORMAT]Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 3464，2003年1月。
[DSN-SMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[DSN-SMTP]Moore，K.，“用于传递状态通知（DSN）的简单邮件传输协议（SMTP）服务扩展”，RFC 3461，2003年1月。
[OLD-REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.
[OLD-REPORT]Vaudreuil，G.“用于报告邮件系统管理消息的多部分/报告内容类型”，RFC 3462，2003年1月。
The author would like to thank Dave Crocker, Frank Ellermann, Ned Freed, Randall Gellens, Alexey Melnikov, and Keith Moore for their input to this update.
作者要感谢Dave Crocker、Frank Ellermann、Ned Freed、Randall Gellens、Alexey Melnikov和Keith Moore为本更新提供的信息。
Thanks also go to Gregory M. Vaudreuil, the original creator of this media type.
还要感谢Gregory M.Vaudreuil，这种媒体类型的原始创建者。
Author's Address
作者地址
Murray S. Kucherawy (editor) Cloudmark 128 King St., 2nd Floor San Francisco, CA 94107 US
Murray S. Kucherawy（编辑）CuldMax 128国王圣，第二楼旧金山，CA 94107美国
Phone: +1 415 946 3800
EMail: msk@cloudmark.com
Phone: +1 415 946 3800
EMail: msk@cloudmark.com