Network Working Group G. Vaudreuil
Request for Comments: 3462 Lucent Technologies
Obsoletes: 1892 January 2003
Category: Standards Track
Network Working Group G. Vaudreuil
Request for Comments: 3462 Lucent Technologies
Obsoletes: 1892 January 2003
Category: Standards Track
The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages
用于报告邮件系统管理邮件的多部分/报告内容类型
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
The Multipart/Report Multipurpose Internet Mail Extensions (MIME) content-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 content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports.
多部分/报告多用途Internet邮件扩展（MIME）内容类型是任何类型电子邮件报告的通用“系列”或“容器”类型。尽管本备忘录仅定义了多部分/报告内容类型在传递状态报告中的使用，但如果使用单一内容类型来处理所有类型的报告，邮件处理程序将受益匪浅。
This document is part of a four document set describing the delivery status report service. This collection includes the Simple Mail Transfer Protocol (SMTP) extensions to request delivery status reports, a MIME content for the reporting of delivery reports, an enumeration of extended status codes, and a multipart container for the delivery report, the original message, and a human-friendly summary of the failure.
此文档是描述交付状态报告服务的四文档集的一部分。此集合包括用于请求传递状态报告的简单邮件传输协议（SMTP）扩展、用于报告传递报告的MIME内容、扩展状态代码的枚举、用于传递报告的多部分容器、原始邮件以及对故障的人性化摘要。
Table of Contents
目录
Document Conventions................................................2
1. The Multipart/Report Content Type................................2
2. The Text/RFC822-Headers..........................................4
3. Security Considerations..........................................4
4. Normative References.............................................5
Appendix A - Changes from RFC 1893..................................6
Author's Address....................................................6
Full Copyright Statement............................................7
Document Conventions................................................2
1. The Multipart/Report Content Type................................2
2. The Text/RFC822-Headers..........................................4
3. Security Considerations..........................................4
4. Normative References.............................................5
Appendix A - Changes from RFC 1893..................................6
Author's Address....................................................6
Full Copyright Statement............................................7
Document Conventions
文件惯例
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 BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
The Multipart/Report MIME content-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 content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports.
多部分/报表MIME内容类型是任何类型电子邮件报表的通用“系列”或“容器”类型。尽管本备忘录仅定义了多部分/报告内容类型在传递状态报告中的使用，但如果使用单一内容类型来处理所有类型的报告，邮件处理程序将受益匪浅。
The Multipart/Report content-type is defined as follows:
多部分/报告内容类型定义如下：
MIME type name: multipart MIME subtype name: report Required parameters: boundary, report-type Optional parameters: none Encoding considerations: 7bit should always be adequate Security considerations: see section 3 of this memo
MIME类型名称：多部分MIME子类型名称：报表所需参数：边界，报表类型可选参数：无编码注意事项：7bit应始终足够安全注意事项：请参阅本备忘录第3节
The syntax of Multipart/Report is identical to the Multipart/Mixed content type defined in [MIME]. When used to send a report, the Multipart/Report content-type must be the top-level MIME content type for any report message. The report-type parameter identifies the type of report. The parameter is the MIME content sub-type of the second body part of the Multipart/Report.
Multipart/Report的语法与[MIME]中定义的Multipart/Mixed内容类型相同。用于发送报告时，多部分/报告内容类型必须是任何报告消息的顶级MIME内容类型。报告类型参数标识报告的类型。该参数是多部分/报表的第二个主体部分的MIME内容子类型。
User agents and gateways must be able to automatically determine that a message is a mail system report and should be processed as such. Placing the Multipart/Report as the outermost content provides a mechanism whereby an auto-processor may detect through parsing the RFC 822 headers that the message is a report.
用户代理和网关必须能够自动确定消息是邮件系统报告，并应按此方式进行处理。将多部分/报告作为最外层内容提供了一种机制，自动处理器可以通过解析RFC 822头来检测消息是否为报告。
The Multipart/Report content-type contains either two or three sub-parts, in the following order:
多部分/报告内容类型按以下顺序包含两个或三个子部分：
1) [Required] The first body part contains 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 may not have a user agent capable of interpreting the second section of the Multipart/Report.
1) [必需]第一个正文部分包含人类可读的消息。此消息的目的是为可能没有能够解释多部分/报告第二部分的用户代理的人类读者提供导致生成报告的条件的易于理解的描述。
The text in the first section may be in any MIME standards-track content-type, charset, or language. Where a description of the error is desired in several languages or several media, a Multipart/Alternative construct may be used.
第一部分中的文本可以是任何MIME标准曲目内容类型、字符集或语言。如果需要用多种语言或多种媒体描述错误，可以使用多部分/替代结构。
This body part may also be used to send detailed information that cannot be easily formatted into a Message/Report 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 may be useful to human experts. An initial body part, Message/delivery-status is defined in [DSN].
(2) [必需]包含报告的消息处理事件的帐户的机器可解析正文部分。本身体部位的目的是提供导致生成报告的条件的机器可读描述，以及第一身体部位中不存在的可能对人类专家有用的细节。[DSN]中定义了初始正文部分、消息/传递状态。
(3) [Optional] A body part containing the returned message or a portion thereof. This information may be useful to aid human experts in diagnosing problems. (Although it may also be useful to allow the sender to identify the message 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 may be wasteful of network bandwidth and a variety of implementation strategies can be used. Generally the sender should 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 [DRPT], the agent that generated the delivery service report should return the full message content.
返回内容可能会浪费网络带宽，可以使用多种实现策略。通常，发送方应选择适当的策略，并告知接收方所需的返回内容级别。如果没有明确的内容返回级别请求（如[DRPT]中提供的内容），则生成交付服务报告的代理应返回完整的消息内容。
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 content-type MAY be used to return only the original message headers.
如果要返回未以7位形式编码的8位或二进制数据，并且不能保证返回路径支持8位或二进制，则有两个选项可用。原始消息可以重新编码为合法的7位MIME消息，或者可以使用Text/RFC822 Headers内容类型仅返回原始消息头。
The Text/RFC822-Headers MIME content-type provides a mechanism to label and return only the RFC 822 headers of a failed message. These headers are not the complete message and should not be returned as a Message/RFC822. The returned headers are useful for identifying the failed message and for diagnostics based on the received lines.
Text/RFC822 Headers MIME内容类型提供了一种机制，用于标记并仅返回失败消息的RFC822头。这些头不是完整的消息，不应作为消息/RFC822返回。返回的标头对于识别失败消息和基于接收到的行进行诊断非常有用。
The Text/RFC822-Headers content-type is defined as follows:
Text/RFC822 Headers内容类型定义如下：
MIME type name: Text MIME subtype name: RFC822-Headers Required parameters: None Optional parameters: None Encoding considerations: 7 bit is sufficient for normal RFC822 headers, however, if the headers are broken and require encoding to make them legal 7 bit content, they may be encoded in quoted-printable. Security considerations: See section 3 of this memo.
MIME类型名称：文本MIME子类型名称：RFC822头所需参数：无可选参数：无编码注意事项：7位对于普通RFC822头就足够了，但是，如果头被破坏，并且需要编码以使其成为合法的7位内容，则可以将其编码为可打印的引号。安全注意事项：见本备忘录第3节。
The Text/RFC822-Headers body part should contain all the RFC822 header lines from the message which caused the report. The RFC822 headers include all lines prior to the blank line in the message. They include the MIME-Version and MIME Content-Headers.
Text/RFC822 Headers正文部分应包含导致报告的消息中的所有RFC822头行。RCF822标头包括消息中空白行之前的所有行。它们包括MIME版本和MIME内容头。
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 may 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.
覆盖整个多部分/报告结构的签名可用于防止此类伪造；然而，这种签名方案超出了本文件的范围。
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[SMTP]Postel，J.，“简单邮件传输协议”，STD 10，RFC 8211982年8月。
[DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[DSN]Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 3464，2003年1月。
[RFC822] Crocker, D., "Standard for the format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC822]Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[MIME] Borenstein, N. and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[MIME]Borenstein，N.和N.Freed，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[DRPT] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 3461, January 2003.
[DRPT]Moore，K.，“传递状态通知的SMTP服务扩展”，RFC 34612003年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Appendix A - Changes from RFC 1892
附录A-对RFC 1892的变更
Changed Authors contact information
更改了作者的联系信息
Updated required standards boilerplate
更新所需标准样板
Edited the text to make it spell-checker and grammar checker compliant
编辑文本以使其符合拼写检查器和语法检查器
Author's Address
作者地址
Gregory M. Vaudreuil Lucent Technologies 7291 Williamson Rd Dallas Tx, 75214
Gregory M.Vaudreuil-Lucent Technologies德克萨斯州达拉斯威廉森路7291号，邮编75214
Phone: +1 214 823 9325
EMail: GregV@ieee.org
Phone: +1 214 823 9325
EMail: GregV@ieee.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。