Internet Engineering Task Force (IETF) T. Hansen, Ed.
Request for Comments: 8098 AT&T Laboratories
STD: 85 A. Melnikov, Ed.
Obsoletes: 3798 Isode Ltd
Updates: 2046, 3461 February 2017
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) T. Hansen, Ed.
Request for Comments: 8098 AT&T Laboratories
STD: 85 A. Melnikov, Ed.
Obsoletes: 3798 Isode Ltd
Updates: 2046, 3461 February 2017
Category: Standards Track
ISSN: 2070-1721
Message Disposition Notification
消息处置通知
Abstract
摘要
This memo defines a MIME content type that may be used by a Mail User Agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content type is intended to be machine processable. Additional message header fields are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and are often referred to as "read receipts," "acknowledgements," or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past.
此备忘录定义了一种MIME内容类型，邮件用户代理（MUA）或电子邮件网关可使用该类型在邮件成功传递给收件人后报告邮件的处置情况。此内容类型旨在可由机器处理。还定义了其他消息头字段，以允许消息的发件人请求消息处置通知（MDN）。其目的是扩展Internet邮件以支持其他消息传递系统（如X.400和专有的“基于LAN的”系统）中常见的功能，通常称为“读取收据”、“确认”或“收据通知”。其目的是在尊重隐私的同时做到这一点，在过去讨论此类函数时，通常会表达这些函数。
Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multiprotocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail.
由于许多消息在Internet和其他消息传递系统（如X.400或专有的“基于LAN的”系统）之间发送，因此MDN协议在多协议消息传递环境中非常有用。为此，本备忘录中所述的协议规定，除互联网邮件中通常使用的地址外，还可携带“外国”地址。还可以定义其他属性以支持通过Internet邮件“隧道”发送外来通知。
This document is an Internet Standard. It obsoletes RFC 3798 and updates RFC 2046 (message/partial media type handling) and RFC 3461 (Original-Recipient header field generation requirement).
本文件为互联网标准。它淘汰RFC 3798并更新RFC 2046（消息/部分媒体类型处理）和RFC 3461（原始收件人标头字段生成要求）。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc8098.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8098.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Purposes . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Requesting Message Disposition Notifications . . . . . . . . 5
2.1. The Disposition-Notification-To Header . . . . . . . . . 5
2.2. The Disposition-Notification-Options Header . . . . . . . 8
2.3. The Original-Recipient Header Field . . . . . . . . . . . 9
2.4. Use with the Message/Partial Media Type . . . . . . . . . 10
3. Format of a Message Disposition Notification . . . . . . . . 10
3.1. The Message/Disposition-Notification Media Type . . . . . 12
3.2. Message/Disposition-Notification Content Fields . . . . . 15
3.3. Extension-Fields . . . . . . . . . . . . . . . . . . . . 21
4. Timeline of Events . . . . . . . . . . . . . . . . . . . . . 22
5. Conformance and Usage Requirements . . . . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
6.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2.1. Disclosure of Product Information . . . . . . . . . . 25
6.2.2. MUA Fingerprinting . . . . . . . . . . . . . . . . . 25
6.3. Non-repudiation . . . . . . . . . . . . . . . . . . . . . 25
6.4. Mail Bombing . . . . . . . . . . . . . . . . . . . . . . 26
7. Collected ABNF Grammar . . . . . . . . . . . . . . . . . . . 26
8. Guidelines for Gatewaying MDNs . . . . . . . . . . . . . . . 29
8.1. Gatewaying from Other Mail Systems to MDNs . . . . . . . 29
8.2. Gatewaying from MDNs to Other Mail Systems . . . . . . . 29
8.3. Gatewaying of MDN-Requests to Other Mail Systems . . . . 30
9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10.1. Disposition-Notification-Options Header Field
disposition-notification-parameter Names . . . . . . . . 32
10.2. Disposition Modifier Names . . . . . . . . . . . . . . . 33
10.3. MDN Extension Field Names . . . . . . . . . . . . . . . 33
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.1. Normative References . . . . . . . . . . . . . . . . . . 33
11.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Changes from RFC 3798 . . . . . . . . . . . . . . . 36
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Purposes . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Requesting Message Disposition Notifications . . . . . . . . 5
2.1. The Disposition-Notification-To Header . . . . . . . . . 5
2.2. The Disposition-Notification-Options Header . . . . . . . 8
2.3. The Original-Recipient Header Field . . . . . . . . . . . 9
2.4. Use with the Message/Partial Media Type . . . . . . . . . 10
3. Format of a Message Disposition Notification . . . . . . . . 10
3.1. The Message/Disposition-Notification Media Type . . . . . 12
3.2. Message/Disposition-Notification Content Fields . . . . . 15
3.3. Extension-Fields . . . . . . . . . . . . . . . . . . . . 21
4. Timeline of Events . . . . . . . . . . . . . . . . . . . . . 22
5. Conformance and Usage Requirements . . . . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
6.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2.1. Disclosure of Product Information . . . . . . . . . . 25
6.2.2. MUA Fingerprinting . . . . . . . . . . . . . . . . . 25
6.3. Non-repudiation . . . . . . . . . . . . . . . . . . . . . 25
6.4. Mail Bombing . . . . . . . . . . . . . . . . . . . . . . 26
7. Collected ABNF Grammar . . . . . . . . . . . . . . . . . . . 26
8. Guidelines for Gatewaying MDNs . . . . . . . . . . . . . . . 29
8.1. Gatewaying from Other Mail Systems to MDNs . . . . . . . 29
8.2. Gatewaying from MDNs to Other Mail Systems . . . . . . . 29
8.3. Gatewaying of MDN-Requests to Other Mail Systems . . . . 30
9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10.1. Disposition-Notification-Options Header Field
disposition-notification-parameter Names . . . . . . . . 32
10.2. Disposition Modifier Names . . . . . . . . . . . . . . . 33
10.3. MDN Extension Field Names . . . . . . . . . . . . . . . 33
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.1. Normative References . . . . . . . . . . . . . . . . . . 33
11.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Changes from RFC 3798 . . . . . . . . . . . . . . . 36
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
This memo defines a media type [RFC2046] for Message Disposition Notifications (MDNs). An MDN can be used to notify the sender of a message of any of several conditions that may occur after successful delivery, such as display of the message contents, printing of the message, deletion (without display) of the message, or the recipient's refusal to provide MDNs. The "message/disposition-notification" content type defined herein is intended for use within the framework of the "multipart/report" content type defined in RFC-REPORT [RFC6522].
此备忘录定义了消息处置通知（MDN）的媒体类型[RFC2046]。MDN可用于将成功传递后可能出现的几种情况中的任何一种情况通知邮件的发件人，例如显示邮件内容、打印邮件、删除（不显示）邮件或收件人拒绝提供MDN。本文定义的“消息/处置通知”内容类型旨在在RFC-report[RFC6522]中定义的“多部分/报告”内容类型的框架内使用。
This memo defines the format of the notifications and the RFC-MSGFMT [RFC5322] header fields used to request them.
此备忘录定义了通知的格式以及用于请求通知的RFC-MSGFMT[RFC5322]头字段。
The MDNs defined in this memo are expected to serve several purposes:
本备忘录中定义的MDN预计可用于多种用途：
a. Inform human beings of the disposition of messages after successful delivery in a manner that is largely independent of human language;
a. 以一种基本上独立于人类语言的方式告知人类在成功传递信息后的处理方式；
b. Allow mail user agents to keep track of the disposition of messages sent by associating returned MDNs with earlier message transmissions;
b. 允许邮件用户代理通过将返回的MDN与较早的消息传输关联，跟踪发送的消息的处置情况；
c. Convey disposition notification requests and disposition notifications between Internet Mail and "foreign" mail systems via a gateway;
c. 通过网关在Internet邮件和“外国”邮件系统之间传递处置通知请求和处置通知；
d. Allow "foreign" notifications to be tunneled through a MIME-capable messaging system and back into the original messaging system that issued the original notification, or even to a third messaging system;
d. 允许“外来”通知通过支持MIME的消息传递系统进行隧道传输，并返回到发出原始通知的原始消息传递系统，甚至第三个消息传递系统；
e. Allow language-independent, yet reasonably precise, indications of the disposition of a message to be delivered.
e. 允许独立于语言但相当精确的消息处理指示。
These purposes place the following constraints on the notification protocol:
出于这些目的，通知协议受到以下限制：
a. It must be readable by humans and must be machine parsable.
a. 它必须是人类可读的，并且必须是机器可分析的。
b. It must provide enough information to allow message senders (or their user agents) to unambiguously associate an MDN with the message that was sent and the original recipient address for which the MDN was issued (if such information is available), even if the message was forwarded to another recipient address.
b. 它必须提供足够的信息，使邮件发件人（或其用户代理）能够明确地将MDN与发送的邮件以及为其发出MDN的原始收件人地址相关联（如果此类信息可用），即使邮件已转发到另一个收件人地址。
c. It must also be able to describe the disposition of a message independent of any particular human language or of the terminology of any particular mail system.
c. 它还必须能够描述独立于任何特定人类语言或任何特定邮件系统的术语的消息的处理。
d. The specification must be extensible in order to accommodate future requirements.
d. 规范必须是可扩展的，以适应未来的需求。
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 RFC-KEYWORDS [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC-KEYWORDS[RFC2119]中的描述进行解释。
All syntax descriptions use the ABNF specified by RFC-MSGFMT [RFC5322] in which the lexical tokens (used below) are defined: "CRLF", "FWS", "CFWS", "field-name", "mailbox-list", "msg-id", and "text". The following lexical token is defined in RFC-SMTP [RFC5321]: "Atom".
所有语法描述都使用RFC-MSGFMT[RFC5322]指定的ABNF，其中定义了词法标记（如下所示）：“CRLF”、“FWS”、“CFWS”、“字段名”、“邮箱列表”、“消息id”和“文本”。以下词法标记在RFC-SMTP[RFC5321]中定义：“Atom”。
Message disposition notifications are requested by including a Disposition-Notification-To header field in the message containing one or more addresses specifying where dispositions should be sent. Further information to be used by the recipient's Mail User Agent (MUA) [RFC5598] in generating the MDN may be provided by also including Original-Recipient and/or Disposition-Notification-Options header fields in the message.
通过在包含一个或多个地址的消息中包含“发送到头的处置通知”字段来请求消息处置通知，该地址指定应将处置发送到的位置。接收者的邮件用户代理（MUA）[RFC5598]在生成MDN时使用的进一步信息可以通过在消息中还包括原始接收者和/或处置通知选项报头字段来提供。
A request for the receiving user agent to issue message disposition notifications is made by placing a Disposition-Notification-To header field into the message. The syntax of the header field is
接收用户代理发出消息处置通知的请求是通过将处置通知放置到消息头字段中发出的。标题字段的语法为
mdn-request-header = "Disposition-Notification-To" ":" mailbox-list CRLF
mdn request header=“处置通知到”“：”邮箱列表CRLF
A Disposition-Notification-To header field can appear in a message at most once.
消息中最多只能出现一次标题处置通知字段。
The presence of a Disposition-Notification-To header field in a message is merely a request for an MDN. The recipients' user agents are always free to silently ignore such a request.
消息中出现的处置通知头字段仅仅是对MDN的请求。接收者的用户代理总是可以无提示地忽略这样的请求。
An MDN MUST NOT itself have a Disposition-Notification-To header field. An MDN MUST NOT be generated in response to an MDN.
MDN本身不得具有到标头的处置通知字段。不得生成MDN以响应MDN。
A user agent MUST NOT issue more than one MDN on behalf of each particular recipient. That is, once an MDN has been issued on behalf of a recipient, no further MDNs may be issued on behalf of that recipient by the same user agent, even if another disposition is performed on the message. However, if a message is forwarded, an MDN may have been issued for the recipient doing the forwarding, and the recipient of the forwarded message may also cause an MDN to be generated.
用户代理不得代表每个特定收件人发布多个MDN。也就是说，一旦代表接收者发布了MDN，即使对消息执行了另一个处置，也不能由同一用户代理代表该接收者发布更多的MDN。但是，如果邮件被转发，则可能已经为进行转发的收件人发出了MDN，并且转发邮件的收件人也可能导致生成MDN。
It is also possible that if the same message is being accessed by multiple user agents (for example, using POP3), then multiple dispositions might be generated for the same recipient. User agents SHOULD leverage support in the underlying message access protocol to prevent multiple MDNs from being generated. In particular, when the user agent is accessing the message using RFC-IMAP [RFC3501], it SHOULD implement the procedures specified in RFC-IMAP-MDN [RFC3503].
如果多个用户代理（例如，使用POP3）正在访问同一邮件，则可能会为同一收件人生成多个处置。用户代理应该利用底层消息访问协议中的支持来防止生成多个MDN。特别是，当用户代理使用RFC-IMAP[RFC3501]访问消息时，它应该实现RFC-IMAP-MDN[RFC3503]中指定的过程。
While Internet standards normally do not specify the behavior of user interfaces, it is strongly recommended that the user agent obtain the user's consent before sending an MDN. This consent could be obtained for each message through some sort of prompt or dialog box, or globally through the user's setting of a preference. The user might also indicate globally that MDNs are to never be sent. The purpose of obtaining user's consent is to protect user's privacy. The default value should be not to send MDNs.
虽然Internet标准通常不指定用户界面的行为，但强烈建议用户代理在发送MDN之前获得用户的同意。可以通过某种提示或对话框，或通过用户的首选项设置全局获得每条消息的同意。用户还可能全局指示永不发送MDN。获得用户同意的目的是保护用户的隐私。默认值应为不发送MDN。
MDNs MUST NOT be sent automatically if the address in the Disposition-Notification-To header field differs from the address in the Return-Path header field (see RFC-MSGFMT [RFC5322]). In this case, confirmation from the user MUST be obtained, if possible. If obtaining consent is not possible (e.g., because the user is not online at the time or the client is not an interactive email client), then an MDN MUST NOT be sent.
如果处置通知标题字段中的地址与返回路径标题字段中的地址不同，则不得自动发送MDN（请参阅RFC-MSGFMT[RFC5322]）。在这种情况下，如果可能，必须获得用户的确认。如果无法获得同意（例如，由于用户当时不在线或客户端不是交互式电子邮件客户端），则不得发送MDN。
Confirmation from the user MUST be obtained (or no MDN sent) if there is no Return-Path header field in the message or if there is more than one distinct address in the Disposition-Notification-To header field.
如果消息中没有返回路径标头字段，或者如果处置通知标头字段中有多个不同的地址，则必须获得用户的确认（或未发送MDN）。
The comparison of the addresses is done using only the addr-spec (local-part "@" domain) portion, excluding any angle brackets, phrase, and route. As prescribed by RFC 5322, the comparison is case sensitive for the local-part and case insensitive for the domain part. The local-part comparison SHOULD be done after performing local-part canonicalization, i.e., after removing the surrounding double-quote characters, if any, as well as any escaping "\" characters. (See RFC-MSGFMT [RFC5322] for more details.) Implementations MAY treat known domain aliases as equivalent for the purpose of comparison.
地址的比较仅使用addr spec（本地部分“@”域）部分完成，不包括任何尖括号、短语和路由。按照RFC 5322的规定，本地部分的比较区分大小写，域部分的比较不区分大小写。本地部件比较应在执行本地部件规范化之后进行，即在删除周围的双引号字符（如果有）以及任何转义“\”字符之后。（有关更多详细信息，请参阅RFC-MSGFMT[RFC5322]）为了进行比较，实现可以将已知的域别名视为等效的。
Note that use of subaddressing (see [RFC5233]) can result in a failure to match two local-parts and thus result in possible suppression of the MDN. This document doesn't recommend special handling for this case, as the receiving MUA can't reliably know whether or not the sender is using subaddressing.
请注意，使用子地址（请参见[RFC5233]）可能会导致两个本地部分无法匹配，从而导致MDN可能被抑制。本文档不建议对此情况进行特殊处理，因为接收MUA无法可靠地知道发送方是否正在使用子地址。
If the message contains more than one Return-Path header field, the implementation may pick one to use for the comparison or treat the situation as a failure of the comparison.
如果消息包含多个返回路径头字段，则实现可以选择一个用于比较，或者将该情况视为比较失败。
The reason for not automatically sending an MDN if the comparison fails or more than one address is specified is to reduce the possibility of mail loops and of MDNs being used for mail bombing.
如果比较失败或指定了多个地址，则不自动发送MDN的原因是为了减少邮件循环和MDN用于邮件轰炸的可能性。
It's especially important that a message that contains a Disposition-Notification-To header field also contain a Message-ID header field to permit user agents to automatically correlate MDNs with their original messages.
尤其重要的是，包含处置通知到标头字段的消息还包含消息ID标头字段，以允许用户代理自动将MDN与其原始消息关联起来。
If the request for message disposition notifications for some recipients and not others is desired, two copies of the message should be sent, one with a Disposition-Notification-To header field and one without. Many of the other header fields of the message (e.g., To, Cc) will be the same in both copies. The recipients in the respective message envelopes determine from whom message disposition notifications are requested and from whom they are not. If desired, the Message-ID header field may be the same in both copies of the message. Note that there are other situations (e.g., Bcc) in which it is necessary to send multiple copies of a message with slightly different header fields. The combination of such situations and the need to request MDNs for a subset of all recipients may result in more than two copies of a message being sent, some with a Disposition-Notification-To header field and some without.
如果需要为某些收件人而不是其他收件人请求邮件处置通知，则应发送邮件的两个副本，一个带有处置通知到标头字段，另一个没有。消息的许多其他头字段（例如，To、Cc）在两个副本中都相同。各个邮件信封中的收件人确定从谁处请求邮件处置通知以及不从谁处请求通知。如果需要，消息的两个副本中的消息ID标头字段可以相同。请注意，在其他情况下（例如，密件抄送），有必要发送具有稍微不同的标题字段的消息的多个副本。这种情况加上需要为所有收件人的子集请求MDN，可能会导致发送两个以上的邮件副本，其中一些带有到标头的处置通知字段，而另一些则没有。
If it is possible to determine that a recipient is a newsgroup, do not include a Disposition-Notification-To header field for that recipient. Similarly, if an existing message is resent or gatewayed to a newsgroup, the agent that is resending/gatewaying SHOULD strip the Disposition-Notification-To header field. See Section 5 for more discussion. Clients that see an otherwise valid Disposition-Notification-To header field in a newsgroup message SHOULD NOT generate an MDN.
如果可以确定收件人是新闻组，则不要包含该收件人的处置通知标题字段。类似地，如果现有消息被重新发送或网关传送到新闻组，则正在重新发送/网关传送的代理应删除“处置通知到标头”字段。更多讨论见第5节。在新闻组消息中看到以其他方式有效的头处理通知字段的客户端不应生成MDN。
Extensions to this specification may require that information be supplied to the recipient's MUA for additional control over how and what MDNs are generated. The Disposition-Notification-Options header field provides an extensible mechanism for such information. The syntax of this header field is as follows:
对本规范的扩展可能需要向接收方的MUA提供信息，以便对MDN的生成方式和内容进行额外控制。处置通知选项标题字段为此类信息提供了可扩展的机制。此标题字段的语法如下所示：
Disposition-Notification-Options = "Disposition-Notification-Options" ":" [FWS] disposition-notification-parameter-list CRLF
处置通知选项=“处置通知选项”：“[FWS]处置通知参数列表CRLF
disposition-notification-parameter-list = disposition-notification-parameter *([FWS] ";" [FWS] disposition-notification-parameter)
处置通知参数列表=处置通知参数*（[FWS]；“[FWS]处置通知参数）
disposition-notification-parameter = attribute [FWS] "=" [FWS] importance [FWS] "," [FWS] value *([FWS] "," [FWS] value)
处置通知参数=属性[FWS]“=”[FWS]重要性[FWS]，“[FWS]值*（[FWS]，“[FWS]值）
importance = "required" / "optional"
importance = "required" / "optional"
attribute = Atom
attribute = Atom
value = word
value = word
A Disposition-Notification-Options header field can appear in a message at most once.
处置通知选项标题字段最多只能在消息中出现一次。
An importance of "required" indicates that interpretation of the disposition-notification-parameter is necessary for proper generation of an MDN in response to this request. An importance of "optional" indicates that an MUA that does not understand the meaning of this disposition-notification-parameter MAY generate an MDN in response anyway, ignoring the value of the disposition-notification-parameter.
“required”的重要性表示，为了响应此请求，正确生成MDN，必须解释处置通知参数。“可选”的重要性表示不理解此处置通知参数含义的MUA可能会在响应中生成MDN，忽略处置通知参数的值。
No disposition-notification-parameter attribute names are defined in this specification. Attribute names may be defined in the future by later revisions or extensions to this specification. Disposition-
本规范中未定义处置通知参数属性名称。属性名称可能在将来由本规范的后续修订或扩展定义。性情-
notification-parameter attribute names MUST be registered with the Internet Assigned Numbers Authority (IANA) using the "Specification Required" registration policy [RFC5226]. The "X-" prefix has historically been used to denote unregistered "experimental" protocol elements that are assumed not to become common use. Deployment experience of this and other protocols has shown that this assumption is often false. This document allows the use of the "X-" prefix primarily to allow the registration of attributes that are already in common use. The prefix has no meaning for new attributes. Its use in substantially new attributes may cause confusion and is therefore discouraged. (See Section 10 for a registration form.)
通知参数属性名称必须使用“所需规范”注册策略[RFC5226]向互联网分配号码管理局（IANA）注册。“X-”前缀在历史上一直被用来表示未注册的“实验性”协议元素，这些元素被认为不是常用的。该协议和其他协议的部署经验表明，这种假设通常是错误的。本文档允许使用“X-”前缀，主要用于注册已经常用的属性。前缀对于新属性没有意义。在实质上新的属性中使用它可能会引起混淆，因此不鼓励使用。（登记表见第10节。）
Since electronic mail addresses may be rewritten while the message is in transit, it is useful for the original recipient address to be made available by the delivering Message Transfer Agent (MTA) [RFC5598]. The delivering MTA may be able to obtain this information from the ORCPT parameter of the SMTP RCPT TO command, as defined in RFC-SMTP [RFC5321] and RFC-DSN-SMTP [RFC3461].
由于电子邮件地址可能在邮件传输过程中被重写，因此传递邮件传输代理（MTA）提供原始收件人地址非常有用[RFC5598]。按照RFC-SMTP[RFC5321]和RFC-DSN-SMTP[RFC3461]中的定义，传送MTA可能能够从SMTP RCPT to命令的ORCPT参数获取此信息。
RFC-DSN-SMTP [RFC3461] is amended as follows: if the ORCPT information is available, the delivering MTA SHOULD insert an Original-Recipient header field at the beginning of the message (along with the Return-Path header field). The delivering MTA MAY delete any other Original-Recipient header fields that occur in the message. The syntax of this header field is as follows:
RFC-DSN-SMTP[RFC3461]修改如下：如果ORCPT信息可用，则递送MTA应在邮件开头插入原始收件人标头字段（以及返回路径标头字段）。传递MTA可以删除邮件中出现的任何其他原始收件人标题字段。此标题字段的语法如下所示：
original-recipient-header = "Original-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS
原始收件人标头=“原始收件人”“：“OWS地址类型OWS”；“OWS通用地址OWS”
OWS = [CFWS]
; Optional whitespace.
; MDN generators SHOULD use "*WSP"
; (Typically a single space or nothing.
; It SHOULD be nothing at the end of a field.),
; unless an RFC 5322 "comment" is required.
;
; MDN parsers MUST parse it as "[CFWS]".
OWS = [CFWS]
; Optional whitespace.
; MDN generators SHOULD use "*WSP"
; (Typically a single space or nothing.
; It SHOULD be nothing at the end of a field.),
; unless an RFC 5322 "comment" is required.
;
; MDN parsers MUST parse it as "[CFWS]".
The address-type and generic-address tokens are as specified in the description of the Original-Recipient field in Section 3.2.3.
地址类型和通用地址标记如第3.2.3节中原始收件人字段的说明所述。
The purpose of carrying the original recipient information and returning it in the MDN is to permit automatic correlation of MDNs with the original message on a per-recipient basis.
携带原始收件人信息并将其返回MDN的目的是允许每个收件人的MDN与原始邮件自动关联。
The use of the header fields Disposition-Notification-To, Disposition-Notification-Options, and Original-Recipient with the MIME message/partial content type (RFC-MIME-MEDIA [RFC2046]) requires further definition.
使用具有MIME邮件/部分内容类型（RFC-MIME-MEDIA[RFC2046]）的头字段“处置通知到”、“处置通知选项”和“原始收件人”需要进一步定义。
When a message is segmented into two or more message/partial fragments, the three header fields mentioned in the above paragraph SHOULD be placed in the "inner" or "enclosed" message (using the terms of RFC-MIME-MEDIA [RFC2046]). If these header fields are found in the header fields of any of the fragments, they are ignored.
当一条消息被分割成两个或多个消息/部分片段时，上述段落中提到的三个标题字段应放在“内部”或“封闭”消息中（使用RFC-MIME-MEDIA[RFC2046]的术语）。如果在任何片段的头字段中找到这些头字段，则忽略它们。
When the multiple message/partial fragments are reassembled, the following applies. If these header fields occur along with the other header fields of a message/partial fragment message, they pertain to an MDN that will be generated for the fragment. If these header fields occur in the header fields of the "inner" or "enclosed" message (using the terms of RFC-MIME-MEDIA [RFC2046]), they pertain to an MDN that will be generated for the reassembled message. Section 5.2.2.1 of RFC-MIME-MEDIA [RFC2046]) is amended to specify that, in addition to the header fields specified there, the three header fields described in this specification are to be appended, in order, to the header fields of the reassembled message. Any occurrences of the three header fields defined here in the header fields of the initial enclosing message MUST NOT be copied to the reassembled message.
当重新组装多个消息/部分片段时，以下内容适用。如果这些头字段与消息/部分片段消息的其他头字段一起出现，则它们属于将为片段生成的MDN。如果这些头字段出现在“内部”或“封闭”消息的头字段中（使用RFC-MIME-MEDIA[RFC2046]的术语），则它们属于将为重新组装的消息生成的MDN。RFC-MIME-MEDIA[RFC2046]第5.2.2.1节进行了修订，规定除此处规定的头字段外，本规范中描述的三个头字段将依次附加到重新组装消息的头字段中。不得将此处在初始封闭消息的标题字段中定义的三个标题字段的任何出现复制到重新组装的消息中。
A message disposition notification is a MIME message with a top-level content type of multipart/report (defined in RFC-REPORT [RFC6522]). When multipart/report content is used to transmit an MDN:
消息处置通知是一个MIME消息，其顶级内容类型为multipart/report（在RFC-report[RFC6522]中定义）。使用多部分/报告内容传输MDN时：
a. The report-type parameter of the multipart/report content is "disposition-notification".
a. 多部分/报告内容的报告类型参数为“处置通知”。
b. The first component of the multipart/report contains a human-readable explanation of the MDN, as described in RFC-REPORT [RFC6522].
b. 如RFC-report[RFC6522]中所述，多部分/报告的第一个组件包含MDN的可读解释。
c. The second component of the multipart/report is of content type message/disposition-notification, described in Section 3.1 of this document.
c. 多部分/报告的第二个组件为内容类型消息/处置通知，如本文件第3.1节所述。
d. If the original message or a portion of the message is to be returned to the sender, it appears as the third component of the multipart/report. The decision of whether or not to return the message or part of the message is up to the MUA generating the MDN. However, in the case of encrypted messages requesting MDNs, if the original message or a portion thereof is returned, it MUST be in its original encrypted form.
d. 如果要将原始邮件或邮件的一部分返回给发件人，则它将显示为多部分/报告的第三个组件。是否返回消息或部分消息的决定取决于生成MDN的MUA。但是，对于请求MDN的加密消息，如果返回原始消息或其中的一部分，则必须是原始加密形式。
NOTE: For message disposition notifications gatewayed from foreign systems, the header fields of the original message may not be available. In this case, the third component of the MDN may be omitted, or it may contain "simulated" RFC-MSGFMT [RFC5322] header fields that contain equivalent information. In particular, it is very desirable to preserve the subject and date fields from the original message.
注意：对于从外部系统网关发送的消息处置通知，原始消息的标题字段可能不可用。在这种情况下，可以省略MDN的第三个组件，或者它可以包含包含等效信息的“模拟”RFC-MSGFMT[RFC5322]头字段。特别是，非常希望保留原始消息中的主题和日期字段。
The MDN MUST be addressed (in both the message header field and the transport envelope) to the address(es) from the Disposition-Notification-To header field from the original message for which the MDN is being generated.
MDN的地址（在消息头字段和传输信封中）必须与生成MDN的原始消息的处置通知至消息头字段中的地址一致。
The From header field of the MDN MUST contain the address of the person for whom the message disposition notification is being issued.
MDN的From标头字段必须包含为其发出消息处置通知的人员的地址。
The envelope sender address (i.e., SMTP "MAIL FROM") of the MDN MUST be null (<>), specifying that no Delivery Status Notification messages nor other messages indicating successful or unsuccessful delivery are to be sent in response to an MDN.
MDN的信封发件人地址（即SMTP“邮件发件人”）必须为空（<>），指定不发送任何传递状态通知消息或其他指示传递成功或不成功的消息来响应MDN。
A message disposition notification MUST NOT itself request an MDN. That is, it MUST NOT contain a Disposition-Notification-To header field.
消息处置通知本身不得请求MDN。也就是说，它不能包含到标头的处置通知字段。
The Message-ID header field (if present) for an MDN MUST be different from the Message-ID of the message for which the MDN is being issued.
MDN的消息ID标头字段（如果存在）必须不同于为其发出MDN的消息的消息ID。
A particular MDN describes the disposition of exactly one message for exactly one recipient. Multiple MDNs may be generated as a result of one message submission, one per recipient. However, due to the circumstances described in Section 2.1, it's possible that some of the recipients for whom MDNs were requested will not generate MDNs.
一个特定的MDN描述了一个收件人对一条消息的处理。一次邮件提交可能会生成多个MDN，每个收件人一个。但是，由于第2.1节中所述的情况，有可能请求MDN的某些收件人不会生成MDN。
The message/disposition-notification media type is defined as follows:
消息/处置通知媒体类型定义如下：
Type name: message
类型名称：消息
Subtype name: disposition-notification
子类型名称：处置通知
Required parameters: none
所需参数：无
Optional parameters: none
可选参数：无
Encoding considerations: "7bit" encoding is sufficient and MUST be used to maintain readability when viewed by non-MIME mail readers.
编码注意事项：“7bit”编码已足够，必须用于在非MIME邮件阅读器查看时保持可读性。
Security considerations: discussed in Section 6 of RFC 8098.
安全注意事项：在RFC 8098第6节中讨论。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 8098
已发布规范：RFC 8098
Applications that use this media type: Mail Transfer Agents and email clients that support multipart/report generation and/or parsing.
使用此媒体类型的应用程序：支持多部分/报告生成和/或解析的邮件传输代理和电子邮件客户端。
Fragment identifier considerations: N/A
片段标识符注意事项：不适用
Additional information:
其他信息：
Deprecated alias names for this type: N/A
此类型的已弃用别名：不适用
Magic number(s): none
幻数：无
File extension(s): .disposition-notification
文件扩展名：。处置通知
Macintosh file type code(s): The 'TEXT' type code is suggested as files of this type are typically used for diagnostic purposes and suitable for analysis in a text editor. A Uniform Type Identifier (UTI) of "public.utf8- email-message-header" is suggested. This type conforms to "public.plain-text".
Macintosh文件类型代码：建议使用“文本”类型代码，因为这种类型的文件通常用于诊断目的，适合在文本编辑器中进行分析。建议使用“public.utf8-电子邮件消息头”的统一类型标识符（UTI）。此类型符合“public.plain text”。
Person & email address to contact for further information:
ART Area Mailing List <art@ietf.org>
Person & email address to contact for further information:
ART Area Mailing List <art@ietf.org>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type contains textual data in the US-ASCII charset, which is always 7bit.
使用限制：此媒体类型包含US-ASCII字符集中的文本数据，该字符集始终为7bit。
Author: See the Authors' Addresses section of RFC 8098.
作者：参见RFC 8098的作者地址部分。
Change controller: IETF
更改控制器：IETF
Provisional registration? no
临时登记？不
(While the 7bit restriction applies to the message/disposition-notification portion of the multipart/report content, it does not apply to the optional third portion of the multipart/report content.)
（虽然7bit限制适用于多部分/报告内容的消息/处置通知部分，但不适用于多部分/报告内容的可选第三部分。）
The message/disposition-notification report type for use in the multipart/report is "disposition-notification".
在多部分/报告中使用的消息/处置通知报告类型为“处置通知”。
The body of a message/disposition-notification consists of one or more "fields" formatted according to the ABNF of RFC-MSGFMT [RFC5322] header "fields". The syntax of the message/disposition-notification content is as follows:
消息/处置通知的正文由一个或多个“字段”组成，这些字段根据RFC-MSGFMT[RFC5322]头“字段”的ABNF进行格式化。消息/处置通知内容的语法如下所示：
disposition-notification-content = [ reporting-ua-field CRLF ]
[ mdn-gateway-field CRLF ]
[ original-recipient-field CRLF ]
final-recipient-field CRLF
[ original-message-id-field CRLF ]
disposition-field CRLF
*( error-field CRLF )
*( extension-field CRLF )
disposition-notification-content = [ reporting-ua-field CRLF ]
[ mdn-gateway-field CRLF ]
[ original-recipient-field CRLF ]
final-recipient-field CRLF
[ original-message-id-field CRLF ]
disposition-field CRLF
*( error-field CRLF )
*( extension-field CRLF )
extension-field = extension-field-name ":" *([FWS] text)
extension-field = extension-field-name ":" *([FWS] text)
extension-field-name = field-name
extension-field-name = field-name
Note that the order of the above fields is recommended but not fixed. Extension fields can appear anywhere.
请注意，以上字段的顺序是推荐的，但不是固定的。扩展字段可以出现在任何地方。
Since these fields are defined according to the rules of RFC-MSGFMT [RFC5322], the same conventions for continuation lines and comments apply. Notification fields may be continued onto multiple lines by beginning each additional line with a SPACE or HTAB. Text that appears in parentheses is considered a comment and not part of the contents of that notification field. Field names are case insensitive, so the names of notification fields may be spelled in
由于这些字段是根据RFC-MSGFMT[RFC5322]的规则定义的，因此延续行和注释的约定相同。通过在每一行的开头加上空格或HTAB，通知字段可以延续到多行。括号中出现的文本被视为注释，而不是通知字段内容的一部分。字段名不区分大小写，因此通知字段的名称可以用
any combination of uppercase and lowercase letters. RFC-MSGFMT [RFC5322] comments in notification fields may use the "encoded-word" construct defined in RFC-MIME-HEADER [RFC2047].
大写字母和小写字母的任意组合。通知字段中的RFC-MSGFMT[RFC5322]注释可以使用RFC-MIME-HEADER[RFC2047]中定义的“编码字”结构。
Several fields consist of a "-type" subfield, followed by a semi-colon, followed by "*text". For these fields, the keyword used in the address-type or MTA-type subfield indicates the expected format of the address or MTA-name that follows.
几个字段由“-type”子字段组成，后跟分号，后跟“*text”。对于这些字段，“地址类型”或“MTA类型”子字段中使用的关键字表示后面的地址或MTA名称的预期格式。
The "-type" subfields are defined as follows:
“-type”子字段定义如下：
a. An "address-type" specifies the format of a mailbox address. For example, Internet Mail addresses use the "rfc822" address-type. Other values can appear in this field as specified in the "Address Types" IANA subregistry established by RFC-DSN-FORMAT [RFC3464].
a. “地址类型”指定邮箱地址的格式。例如，Internet邮件地址使用“rfc822”地址类型。根据RFC-DSN-FORMAT[RFC3464]建立的“地址类型”IANA子区域中的规定，其他值可出现在该字段中。
address-type = Atom
address-type = Atom
Atom = <The version from RFC 5321 (not from RFC 5322)
is used in this document.>
Atom = <The version from RFC 5321 (not from RFC 5322)
is used in this document.>
b. An "MTA-name-type" specifies the format of a mail transfer agent name. For example, for an SMTP server on an Internet host, the MTA name is the domain name of that host, and the "dns" MTA-name-type is used. Other values can appear in this field as specified in the "MTA Name Types" IANA subregistry established by RFC-DSN-FORMAT [RFC3464].
b. “MTA名称类型”指定邮件传输代理名称的格式。例如，对于Internet主机上的SMTP服务器，MTA名称是该主机的域名，并使用“dns”MTA名称类型。根据RFC-DSN-FORMAT[RFC3464]建立的“MTA名称类型”IANA子区域中的规定，此字段中可以显示其他值。
mta-name-type = Atom
mta-name-type = Atom
Values for address-type and mta-name-type are case insensitive. Thus, address-type values of "RFC822" and "rfc822" are equivalent.
地址类型和mta名称类型的值不区分大小写。因此，“RFC822”和“RFC822”的地址类型值是等效的。
The Internet Assigned Numbers Authority (IANA) maintains a registry of address-type and mta-name-type values, along with descriptions of the meanings of each or a reference to one or more specifications that provide such descriptions. (The "rfc822" address-type is defined in RFC-DSN-SMTP [RFC3461].) Registration forms for address-type and mta-name-type appear in RFC-DSN-FORMAT [RFC3464].
Internet Assigned Numbers Authority（IANA）维护地址类型和mta名称类型值的注册表，以及每个值的含义说明或对提供此类说明的一个或多个规范的引用。（RFC-DSN-SMTP[RFC3461]中定义了“rfc822”地址类型。）地址类型和mta名称类型的注册表格显示在RFC-DSN-FORMAT[RFC3464]中。
reporting-ua-field = "Reporting-UA" ":" OWS ua-name OWS [ ";" OWS ua-product OWS ]
报告ua字段=“报告ua”“：“OWS ua名称OWS[”；“OWS ua产品OWS]
ua-name = *text-no-semi
ua-name = *text-no-semi
ua-product = *([FWS] text)
ua-product = *([FWS] text)
text-no-semi = %d1-9 / ; "text" characters excluding NUL, CR,
%d11 / %d12 / %d14-58 / %d60-127 ; LF, or semi-colon
text-no-semi = %d1-9 / ; "text" characters excluding NUL, CR,
%d11 / %d12 / %d14-58 / %d60-127 ; LF, or semi-colon
The Reporting-UA field is defined as follows:
报告UA字段定义如下：
An MDN describes the disposition of a message after it has been delivered to a recipient. In all cases, the Reporting-UA is the MUA that performed the disposition described in the MDN.
MDN描述消息交付给收件人后的处置。在所有情况下，报告UA是执行MDN中所述处置的MUA。
The "Reporting-UA" field contains information about the MUA that generated the MDN, which is often used by servers to help identify the scope of reported interoperability problems, to work around or tailor responses to avoid particular MUA limitations, and for analytics regarding MUA or operating system use. An MUA SHOULD send a "Reporting-UA" field unless specifically configured not to do so.
“报告UA”字段包含有关生成MDN的MUA的信息，服务器通常使用MDN来帮助确定报告的互操作性问题的范围，解决或调整响应以避免特定MUA限制，以及进行有关MUA或操作系统使用的分析。MUA应发送“报告UA”字段，除非专门配置为不发送。
If the reporting MUA consists of more than one component (e.g., a base program and plug-ins), this may be indicated by including a list of product names.
如果报告MUA包含多个组件（例如，基本程序和插件），则可通过包含产品名称列表来表示。
A reporting MUA SHOULD limit generated product identifiers to what is necessary to identify the product; a sender MUST NOT generate advertising or other nonessential information within the product identifier.
报告MUA应将生成的产品标识符限制在识别产品所需的范围内；发送者不得在产品标识中生成广告或其他非必要信息。
A reporting MUA SHOULD NOT generate a "Reporting-UA" field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties. Overly long and detailed "Reporting-UA" field values increase the risk of a user being identified against their wishes ("fingerprinting").
报告MUA不应生成包含不必要的细粒度细节的“报告UA”字段，并应限制第三方添加子产品。过长且详细的“报告UA”字段值会增加违背用户意愿识别用户的风险（“指纹识别”）。
Likewise, implementations are encouraged not to use the product tokens of other implementations in order to declare compatibility with them, as this circumvents the purpose of the field. If an MUA masquerades as a different MUA, recipients can assume that the user
类似地，鼓励实现不要使用其他实现的产品令牌来声明与它们的兼容性，因为这会绕过该字段的用途。如果一个MUA伪装成不同的MUA，接收者可以认为用户
intentionally desires to see responses tailored for that identified MUA, even if they might not work as well for the actual MUA being used.
有意希望看到针对所识别的MUA定制的响应，即使它们可能不适合实际使用的MUA。
Example:
例子：
Reporting-UA: Foomail 97.1
报告UA:Foomail 97.1
The MDN-Gateway field indicates the name of the gateway or MTA that translated a foreign (non-Internet) message disposition notification into this MDN. This field MUST appear in any MDN that was translated by a gateway from a foreign system into MDN format and MUST NOT appear otherwise.
MDN Gateway字段表示将外部（非Internet）邮件处置通知转换为此MDN的网关或MTA的名称。此字段必须出现在网关从外部系统转换为MDN格式的任何MDN中，否则不得出现。
mdn-gateway-field = "MDN-Gateway" ":" OWS mta-name-type OWS ";" OWS mta-name OWS
mdn网关字段=“mdn网关”“：“OWS mta名称类型OWS”；“OWS mta名称OWS”
mta-name = *text
mta-name = *text
For gateways into Internet Mail, the MTA-name-type will normally be "dns", and the mta-name will be the Internet domain name of the gateway.
对于进入Internet邮件的网关，MTA名称类型通常为“dns”，MTA名称为网关的Internet域名。
The Original-Recipient field indicates the original recipient address as specified by the sender of the message for which the MDN is being issued. For Internet Mail messages, the value of the Original-Recipient field is obtained from the Original-Recipient header field from the message for which the MDN is being generated. If there is an Original-Recipient header field in the message, or if information about the original recipient is reliably available some other way, then the Original-Recipient field MUST be included. Otherwise, the Original-Recipient field MUST NOT be included. If there is more than one Original-Recipient header field in the message, the MUA may choose the one to use or act as if no Original-Recipient header field is present.
“原始收件人”字段表示为其发出MDN的邮件的发件人指定的原始收件人地址。对于Internet邮件，原始收件人字段的值是从生成MDN的邮件的原始收件人标头字段中获取的。如果邮件中有原始收件人标题字段，或者如果有关原始收件人的信息以其他方式可靠可用，则必须包括原始收件人字段。否则，不得包含原始收件人字段。如果消息中有多个原始收件人标头字段，MUA可以选择使用该字段，或者在没有原始收件人标头字段的情况下使用该字段。
original-recipient-field = "Original-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS
原始收件人字段=“原始收件人”“：“OWS地址类型OWS”；“OWS通用地址OWS”
generic-address = *text
generic-address = *text
The address-type field indicates the type of the original recipient address. If the message originated within the Internet, the address-
地址类型字段指示原始收件人地址的类型。如果消息源于Internet，则地址为-
type field will normally be "rfc822", and the address will be according to the syntax specified in RFC-MSGFMT [RFC5322]. The value "unknown" should be used if the Reporting MUA cannot determine the type of the original recipient address from the message envelope. This address is the same as that provided by the sender and can be used to automatically correlate MDN reports with original messages on a per-recipient basis.
类型字段通常为“rfc822”，地址将符合RFC-MSGFMT[RFC5322]中指定的语法。如果报告MUA无法从邮件信封确定原始收件人地址的类型，则应使用“未知”值。此地址与发件人提供的地址相同，可用于根据每个收件人自动将MDN报告与原始邮件关联起来。
The Final-Recipient field indicates the recipient for which the MDN is being issued. This field MUST be present.
Final Recipient（最终收件人）字段表示为其颁发MDN的收件人。此字段必须存在。
The syntax of the field is as follows:
该字段的语法如下所示：
final-recipient-field = "Final-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS
最终收件人字段=“最终收件人”“：“OWS地址类型OWS”；“OWS通用地址OWS”
The generic-address subfield of the Final-Recipient field SHOULD contain the mailbox address of the recipient (which will be the same as the From header field of the MDN) as it was when the MDN was generated by the MUA.
最终收件人字段的通用地址子字段应包含收件人的邮箱地址（与MDN的发件人标头字段相同），与MUA生成MDN时相同。
One example of when this field might not contain the final recipient address of the message is when an alias (e.g., <customer-support@example.com>) forwards mail to a specific personal address (e.g., <bob@example.com>). Bob might want to be able to send MDNs but not give away his personal email address. In this case, the Final-Recipient field can contain:
此字段可能不包含邮件的最终收件人地址的一个示例是别名（例如，<客户-support@example.com>)将邮件转发到特定的个人地址（例如<bob@example.com>). Bob可能希望能够发送MDN，但不想泄露他的个人电子邮件地址。在这种情况下，最终收件人字段可以包含：
Final-Recipient: rfc822;customer-support@example.com
Final-Recipient: rfc822;customer-support@example.com
in place of:
代替：
Final-Recipient: rfc822;bob@example.com
Final-Recipient: rfc822;bob@example.com
The Final-Recipient address may differ from the address originally provided by the sender, because it may have been transformed during forwarding and gatewaying into a totally unrecognizable mess. However, in the absence of the optional Original-Recipient field, the Final-Recipient field and any returned content may be the only information available with which to correlate the MDN with a particular message recipient.
最终收件人地址可能与发件人最初提供的地址不同，因为它可能在转发和网关过程中被转换为完全无法识别的混乱状态。但是，在缺少可选的原始收件人字段的情况下，最终收件人字段和任何返回的内容可能是将MDN与特定消息收件人关联的唯一可用信息。
The address-type subfield indicates the type of address expected by the reporting MTA in that context. Recipient addresses obtained via SMTP will normally be of address-type "rfc822", but can be other
address type（地址类型）子字段表示报告MTA在该上下文中预期的地址类型。通过SMTP获得的收件人地址通常为地址类型“rfc822”，但也可以是其他地址
values from the "Address Types" subregistry of the "Delivery Status Notification (DSN) Types" IANA registry.
“交付状态通知（DSN）类型”IANA注册表的“地址类型”子区中的值。
Since mailbox addresses (including those used in the Internet) may be case sensitive, the case of alphabetic characters in the address MUST be preserved.
由于邮箱地址（包括Internet中使用的邮箱地址）可能区分大小写，因此必须保留地址中字母字符的大小写。
The Original-Message-ID field indicates the message-ID of the message for which the MDN is being issued. It is obtained from the Message-ID header field of the message for which the MDN is issued. This field MUST be present if and only if the original message contained a Message-ID header field. The syntax of the field is as follows:
原始邮件ID字段表示为其发出MDN的邮件的邮件ID。它从为其发出MDN的消息的消息ID头字段中获取。当且仅当原始邮件包含邮件ID标头字段时，此字段必须存在。该字段的语法如下所示：
original-message-id-field = "Original-Message-ID" ":" msg-id
原始邮件id字段=“原始邮件id”“：”消息id
The msg-id token is as specified in RFC-MSGFMT [RFC5322].
msg id标记如RFC-MSGFMT[RFC5322]中所述。
The Disposition field indicates the action performed by the Reporting MUA on behalf of the user. This field MUST be present.
处置字段表示报告MUA代表用户执行的操作。此字段必须存在。
The syntax for the Disposition field is:
处置字段的语法为：
disposition-field = "Disposition" ":" OWS disposition-mode OWS ";" OWS disposition-type [ OWS "/" OWS disposition-modifier *( OWS "," OWS disposition-modifier ) ] OWS
处置字段=“处置”“：“OWS处置模式OWS”；“OWS处置类型[OWS”/“OWS处置修饰符*（OWS”，“OWS处置修饰符）]OWS
disposition-mode = action-mode OWS "/" OWS sending-mode
处置模式=行动模式OWS/“OWS发送模式”
action-mode = "manual-action" / "automatic-action"
action-mode = "manual-action" / "automatic-action"
sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"
sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"
disposition-type = "displayed" / "deleted" / "dispatched" /
"processed"
disposition-type = "displayed" / "deleted" / "dispatched" /
"processed"
disposition-modifier = "error" / disposition-modifier-extension
处置修饰符=“错误”/“处置修饰符扩展”
disposition-modifier-extension = Atom
disposition-modifier-extension = Atom
The disposition-mode, disposition-type, and disposition-modifier values may be spelled in any combination of uppercase and lowercase US-ASCII characters.
处置模式、处置类型和处置修饰符值可以用大写和小写US-ASCII字符的任意组合拼写。
Disposition mode consists of two parts: action mode and sending mode.
处置模式由两部分组成：行动模式和发送模式。
The following action modes are defined:
定义了以下动作模式：
"manual-action" The disposition described by the disposition type was a result of an explicit instruction by the user rather than some sort of automatically performed action. (This might include the case when the user has manually configured her MUA to automatically respond to valid MDN requests.) Unless prescribed otherwise in a particular mail environment, in order to preserve the user's privacy, this MUST be the default for MUAs.
“手动操作”处置类型描述的处置是用户明确指示的结果，而不是某种自动执行的操作。（这可能包括用户手动配置其MUA以自动响应有效MDN请求的情况。）除非在特定邮件环境中另有规定，否则为了保护用户的隐私，这必须是MUA的默认设置。
"automatic-action" The disposition described by the disposition type was a result of an automatic action rather than an explicit instruction by the user for this message. This is typically generated by a Mail Delivery Agent (e.g., MDN generations by Sieve reject action [RFC5429], Fax-over-Email [RFC3249], voice message system (see Voice Profile for Internet Mail (VPIM) [RFC3801]), or upon delivery to a mailing list).
“自动操作”处置类型描述的处置是自动操作的结果，而不是用户对此消息的明确指示。这通常由邮件传递代理生成（例如，通过筛选拒绝操作[RFC5429]、电子邮件传真[RFC3249]、语音消息系统生成MDN（请参阅Internet邮件语音配置文件（VPIM）[RFC3801]），或在传递到邮件列表时生成）。
"Manual-action" and "automatic-action" are mutually exclusive. One or the other MUST be specified.
“手动操作”和“自动操作”是相互排斥的。必须指定其中一个。
The following sending modes are defined:
定义了以下发送模式：
"MDN-sent-manually" The user explicitly gave permission for this particular MDN to be sent. Unless prescribed otherwise in a particular mail environment, in order to preserve the user's privacy, this MUST be the default for MUAs.
“手动发送MDN”用户明确授予发送此特定MDN的权限。除非在特定邮件环境中另有规定，否则为了保护用户的隐私，这必须是MUAs的默认设置。
"MDN-sent-automatically" The MDN was sent because the MUA had previously been configured to do so automatically.
“自动发送MDN”发送MDN是因为MUA之前已配置为自动发送MDN。
"MDN-sent-manually" and "MDN-sent-automatically" are mutually exclusive. One or the other MUST be specified.
“手动发送的MDN”和“自动发送的MDN”是互斥的。必须指定其中一个。
The following disposition-types are defined:
定义了以下处置类型：
"displayed" The message has been displayed by the MUA to someone reading the recipient's mailbox. There is no guarantee that the content has been read or understood.
“已显示”MUA已将邮件显示给正在阅读收件人邮箱的人。不能保证内容已被阅读或理解。
"dispatched" The message has been sent somewhere in some manner (e.g., printed, faxed, forwarded) without necessarily having been previously displayed to the user. The user may or may not see the message later.
“已发送”消息已以某种方式（例如打印、传真、转发）发送到某处，而不必事先向用户显示。用户稍后可能会看到该消息，也可能不会看到。
"processed" The message has been processed in some manner (i.e., by some sort of rules or server) without being displayed to the user. The user may or may not see the message later, or there may not even be a human user associated with the mailbox.
“已处理”消息已以某种方式（即通过某种规则或服务器）处理，而未显示给用户。用户以后可能会看到邮件，也可能不会看到，或者甚至可能没有与邮箱关联的人工用户。
"deleted" The message has been deleted. The recipient may or may not have seen the message. The recipient might "undelete" the message at a later time and read the message.
“已删除”消息已被删除。收件人可能看到或可能没有看到该邮件。收件人可能会在以后“取消删除”邮件并阅读邮件。
Only the extension disposition modifiers are defined:
仅定义了扩展配置修改器：
disposition-modifier-extension Disposition modifiers may be defined in the future by later revisions or extensions to this specification. MDN disposition value names MUST be registered with the Internet Assigned Numbers Authority (IANA) using the "Specification Required" registration policy. (See Section 10 for a registration form.) MDNs with disposition modifier names not understood by the receiving MUA MAY be silently ignored or placed in the user's mailbox without special interpretation. They MUST NOT cause any error message to be sent to the sender of the MDN.
处置修饰符扩展处置修饰符可在将来通过本规范的后续修订或扩展来定义。MDN处置值名称必须使用“所需规范”注册策略向互联网分配号码管理局（IANA）注册。（注册表格见第10节。）接收MUA不理解处置修饰符名称的MDN可能会被忽略或放置在用户邮箱中，无需特殊解释。它们不得导致向MDN的发件人发送任何错误消息。
It is not required that an MUA be able to generate all of the possible values of the Disposition field.
不要求MUA能够生成处置字段的所有可能值。
A user agent MUST NOT issue more than one MDN on behalf of each particular recipient. That is, once an MDN has been issued on behalf of a recipient, no further MDNs may be issued on behalf of that recipient, even if another disposition is performed on the message. However, if a message is forwarded, a "dispatched" MDN MAY be issued for the recipient doing the forwarding and the recipient of the forwarded message may also cause an MDN to be generated.
用户代理不得代表每个特定收件人发布多个MDN。也就是说，一旦代表收件人发出MDN，就不能代表该收件人再发出MDN，即使对消息执行了另一个处置。然而，如果转发消息，则可能会为进行转发的收件人发出“已调度”MDN，并且转发消息的收件人也可能会导致生成MDN。
The Error field is used to supply additional information in the form of text messages when the "error" disposition modifier appears. The syntax is as follows:
“错误”字段用于在出现“错误”处置修饰符时以文本消息的形式提供附加信息。语法如下：
error-field = "Error" ":" *([FWS] text)
error-field = "Error" ":" *([FWS] text)
Note that syntax of these header fields doesn't include comments, so the "encoded-word" construct defined in RFC-MIME-HEADER [RFC2047] can't be used to convey non-ASCII text. Applications that need to convey non-ASCII text in these fields should consider implementing the message/global-disposition-notification media type specified in [RFC6533] instead of this specification.
请注意，这些标题字段的语法不包含注释，因此RFC-MIME-header[RFC2047]中定义的“编码字”结构不能用于传递非ASCII文本。需要在这些字段中传送非ASCII文本的应用程序应考虑在[RCFC3533 ]中指定的消息/全局部署通知媒体类型，而不是此规范。
Additional MDN fields may be defined in the future by later revisions or extensions to this specification. MDN field names MUST be registered with the Internet Assigned Numbers Authority (IANA) using the "Specification Required" registration policy. (See Section 10 for a registration form.) MDN Extension-fields may be defined for the following reasons:
将来，本规范的后续修订或扩展可能会定义其他MDN字段。MDN字段名必须使用“所需规范”注册策略向互联网分配号码管理局（IANA）注册。（注册表格见第10节。）定义MDN扩展字段的原因如下：
a. To allow additional information from foreign disposition reports to be tunneled through Internet MDNs. The names of such MDN fields should begin with an indication of the foreign environment name (e.g., X400-Physical-Forwarding-Address).
a. 允许通过Internet MDN传输来自外部处置报告的附加信息。此类MDN字段的名称应以外部环境名称的指示开头（例如，X400物理转发地址）。
b. To allow transmission of diagnostic information that is specific to a particular Mail User Agent (MUA). The names of such MDN fields should begin with an indication of the MUA implementation that produced the MDN (e.g., Foomail-information).
b. 允许传输特定于特定邮件用户代理（MUA）的诊断信息。此类MDN字段的名称应以生成MDN的MUA实现的指示开头（例如，Foomail信息）。
The following timeline shows when various events in the processing of a message and generation of MDNs take place:
以下时间线显示了处理消息和生成MDN过程中的各种事件发生的时间：
-- User composes message.
--用户编写消息。
-- User tells MUA to send message.
--用户告诉MUA发送消息。
-- MUA passes message to Mail Submission Agent (MSA) and original recipient information is passed along.
--MUA将消息传递给邮件提交代理（MSA），并传递原始收件人信息。
-- MSA sends message to next MTA.
--MSA向下一个MTA发送消息。
-- Final MTA receives message.
--最终MTA收到消息。
-- Final MTA delivers message to recipient's mailbox (possibly generating a Delivery Status Notification (DSN)).
--最终MTA将邮件传递到收件人的邮箱（可能会生成传递状态通知（DSN））。
-- (Recipient's) MUA discovers a new message in recipient's mailbox and decides whether an MDN should be generated. If the MUA has information that an MDN has already been generated for this message, no further MDN processing described below is performed. If MUA decides that no MDN can be generated, no further MDN processing described below is performed.
--（收件人）MUA在收件人邮箱中发现新邮件，并决定是否应生成MDN。如果MUA具有已为此消息生成MDN的信息，则不执行下面描述的进一步MDN处理。如果MUA决定不能生成MDN，则不会执行下面描述的进一步MDN处理。
-- MUA performs automatic processing and might generate corresponding MDNs ("dispatched", "processed", or "deleted" disposition type with "automatic-action" and "MDN-sent-automatically" disposition modes). The MUA remembers that an MDN was generated.
--MUA执行自动处理，并可能生成相应的MDN（“已调度”、“已处理”或“已删除”处置类型，具有“自动操作”和“MDN自动发送”处置模式）。MUA记得生成了MDN。
-- MUA displays list of messages to user.
--MUA向用户显示消息列表。
-- User selects a message and requests that some action be performed on it.
--用户选择一条消息并请求对其执行某些操作。
-- MUA performs requested action; if an automatic MDN has not already been generated, with user's permission, sends an appropriate MDN ("displayed", "dispatched", "processed", or "deleted" disposition type, with "manual-action" and "MDN-sent-manually" or "MDN-sent-automatically" disposition mode). The MUA remembers that an MDN was generated.
--MUA执行请求的操作；如果尚未生成自动MDN，在用户许可的情况下，发送适当的MDN（“显示”、“发送”、“处理”或“删除”处置类型，以及“手动操作”和“手动发送MDN”或“自动发送MDN”处置模式）。MUA记得生成了MDN。
-- User possibly performs other actions on message, but no further MDNs are generated.
--用户可能对消息执行其他操作，但不会生成更多的MDN。
An MUA or gateway conforms to this specification if it generates MDNs according to the protocol defined in this memo. It is not necessary to be able to generate all of the possible values of the Disposition field.
如果MUA或网关根据本备忘录中定义的协议生成MDN，则符合本规范。不必生成Disposition字段的所有可能值。
MUAs and gateways MUST NOT generate the Original-Recipient field of an MDN unless the mail protocols provide the address originally specified by the sender at the time of submission. Ordinary SMTP does not make that guarantee, but the SMTP extension defined in RFC-- DSN-SMTP [RFC3461] permits such information to be carried in the envelope if it is available. The Original-Recipient header field defined in this document provides a way for the MTA to pass the original recipient address to the MUA.
MUA和网关不得生成MDN的原始收件人字段，除非邮件协议提供发件人在提交时最初指定的地址。普通SMTP不能保证这一点，但RFC--DSN-SMTP[RFC3461]中定义的SMTP扩展允许在信封中携带此类信息（如果有）。本文档中定义的原始收件人标头字段为MTA将原始收件人地址传递给MUA提供了一种方法。
Each sender-specified recipient address may result in more than one MDN. If an MDN is requested for a recipient that is forwarded to multiple recipients of an "alias" (as defined in Section 6.2.7.3 of RFC-DSN-SMTP [RFC3461]), each of the recipients may issue an MDN.
每个发件人指定的收件人地址可能导致多个MDN。如果为转发给“别名”（如RFC-DSN-SMTP[RFC3461]第6.2.7.3节所定义）的多个收件人的收件人请求MDN，则每个收件人都可以发出MDN。
Successful distribution of a message to a mailing list exploder or gateway to Usenet newsgroup SHOULD be considered the final disposition of the message. A mailing list exploder MAY issue an MDN with a disposition type of "processed" and disposition modes of "automatic-action" and "MDN-sent-automatically" indicating that the message has been forwarded to the list. In this case, the request for MDNs is not propagated to the members of the list.
将邮件成功分发到邮件列表分解器或Usenet新闻组网关应视为邮件的最终处置。邮件列表分解器可能会发出一个MDN，其处置类型为“已处理”，处置模式为“自动操作”和“自动发送MDN”，表明邮件已转发到列表。在这种情况下，对MDN的请求不会传播到列表的成员。
Alternatively (if successful distribution of a message to a mailing list exploder / Usenet newsgroup is not considered the final disposition of the message), the mailing list exploder can issue no MDN and propagate the request for MDNs to all members of the list. The latter behavior is not recommended for any but small, closely knit lists, as it might cause large numbers of MDNs to be generated and may cause confidential subscribers to the list to be revealed. The mailing list exploder can also direct MDNs to itself, correlate them, and produce a report to the original sender of the message.
或者（如果将邮件成功分发给邮件列表分解器/Usenet新闻组不视为邮件的最终处置），邮件列表分解器可以不发布MDN，并将MDN请求传播给列表的所有成员。后一种行为不建议用于任何小的、组织严密的列表，因为它可能会导致生成大量MDN，并可能导致列表的机密订阅者被泄露。邮件列表分解器还可以将MDN定向到自身，关联它们，并向消息的原始发件人生成报告。
This specification places no restrictions on the processing of MDNs received by user agents or mailing lists.
本规范对用户代理或邮件列表接收的MDN的处理没有限制。
The following security considerations apply when using MDNs.
使用MDN时，以下安全注意事项适用。
MDNs can be (and are, in practice) forged as easily as ordinary Internet electronic mail. User agents and automatic mail handling facilities (such as mail distribution list exploders) that wish to make automatic use of MDNs should take appropriate precautions to minimize the potential damage from denial-of-service attacks.
MDN可以（实际上也是）像普通互联网电子邮件一样容易伪造。希望自动使用MDN的用户代理和自动邮件处理设施（如邮件分发列表爆炸器）应采取适当的预防措施，以尽量减少拒绝服务攻击造成的潜在损害。
Security threats related to forged MDNs include the sending of:
与伪造MDN相关的安全威胁包括：
a. A falsified disposition notification when the indicated disposition of the message has not actually occurred, and
a. 指示的消息处置未实际发生时的伪造处置通知，以及
b. Unsolicited MDNs.
b. 未经请求的MDN。
Similarly, a forged spam or phishing email message can contain Disposition-Notification-To header field that can trick the recipient to send an MDN. MDN processing should only be invoked once authenticity of an email message is verified.
类似地，伪造的垃圾邮件或网络钓鱼电子邮件可能包含处置通知标题字段，该字段可诱使收件人发送MDN。只有在验证电子邮件的真实性后，才应调用MDN处理。
Another dimension of security is privacy. There may be cases in which a message recipient does not wish the disposition of messages addressed to him to be known, or is concerned that the sending of MDNs may reveal other sensitive information (e.g., when the message was read, using which email client, and which OS was used). In this situation, it is acceptable for the MUA to silently ignore requests for MDNs.
安全的另一个方面是隐私。在某些情况下，邮件收件人可能不希望知道发送给他的邮件的处理情况，或者担心发送MDN可能会泄露其他敏感信息（例如，邮件读取时间、使用哪个电子邮件客户端以及使用哪个操作系统）。在这种情况下，MUA可以静默地忽略MDN请求。
If the Disposition-Notification-To header field is passed on unmodified when a message is distributed to the subscribers of a mailing list, the subscribers to the list may be revealed to the sender of the original message by the generation of MDNs.
如果在将消息分发给邮件列表的订阅者时未经修改地传递到消息头的处置通知字段，则可以通过生成MDN向原始消息的发送者显示该列表的订阅者。
Headers of the original message returned in part 3 of the multipart/ report, as well as content of the message/disposition-notification part, could reveal confidential information about host names and/or network topology inside a firewall.
多部分/报告第3部分中返回的原始消息的标题以及消息/处置通知部分的内容可能会泄露有关防火墙内主机名和/或网络拓扑的机密信息。
Disposition mode (Section 3.2.6.1) can leak information about recipient's MUA configuration, in particular, whether MDNs are
处置模式（第3.2.6.1节）可能泄漏有关接收方MUA配置的信息，特别是MDN是否
acknowledged manually or automatically. If this is a concern, MUAs can return "manual-action/MDN-sent-manually" disposition mode in generated MDNs.
手动或自动确认。如果这是一个问题，MUA可以在生成的MDN中返回“手动操作/MDN手动发送”处置模式。
In general, any optional MDN field may be omitted if the Reporting MUA site or user determines that inclusion of the field would impose too great a compromise of site confidentiality. The need for such confidentiality must be balanced against the utility of the omitted information in MDNs.
通常，如果报告MUA站点或用户确定包含任何可选MDN字段会对站点机密性造成太大的损害，则可以省略该字段。这种保密性的需要必须与MDN中省略信息的效用相平衡。
In some cases, someone with access to the message stream may use the MDN request mechanism to monitor the mail reading habits of a target. If the target is known to generate MDN reports, they could add a Disposition-Notification-To header field containing the envelope from address. This risk can be minimized by not sending MDN's automatically.
在某些情况下，可以访问消息流的人可以使用MDN请求机制来监视目标的邮件阅读习惯。如果已知目标生成MDN报告，他们可以向包含信封发件人地址的标题字段添加处置通知。这种风险可以通过不自动发送MDN来最小化。
The "Reporting-UA" field (Section 3.2.1), User-Agent header field, and other header fields often reveal information about the respective sender's software systems. In theory, this can make it easier for an attacker to exploit known security holes; in practice, attackers tend to try all potential holes regardless of the apparent software versions being used. Also note that the "Reporting-UA" field doesn't provide any new information in comparison to the "User-Agent" and/or (undocumented) "X-Mailer" header fields used by many MUAs.
“报告UA”字段（第3.2.1节）、用户代理标题字段和其他标题字段通常显示有关各自发送方软件系统的信息。理论上，这可以使攻击者更容易利用已知的安全漏洞；实际上，攻击者倾向于尝试所有潜在漏洞，而不管所使用的软件版本如何。还请注意，“报告UA”字段与许多MUA使用的“用户代理”和/或（未记录的）“X-Mailer”标题字段相比，不提供任何新信息。
The "Reporting-UA" field (Section 3.2.1) might contain enough information to uniquely identify a specific device, usually when combined with other characteristics, particularly if the user agent sends excessive details about the user's system or extensions. Even when the guidance in Section 3.2.1 is followed to avoid fingerprinting, other sources of unique information may still be present, such as the Accept-Language header fields.
“报告UA”字段（第3.2.1节）可能包含足够的信息来唯一标识特定设备，通常在与其他特征相结合时，尤其是当用户代理发送有关用户系统或扩展的过多详细信息时。即使遵循第3.2.1节中的指南以避免指纹识别，也可能存在其他唯一信息源，例如接受语言标题字段。
MDNs do not provide non-repudiation with proof of delivery. Within the framework of today's Internet Mail, the MDNs defined in this document provide valuable information to the mail user; however, MDNs cannot be relied upon as a guarantee that a message was or was not seen by the recipient. Even if MDNs are not actively forged, they may be lost in transit. The recipient may bypass the MDN issuing mechanism in some manner.
MDN不提供交付证明的不可抵赖性。在当今互联网邮件的框架内，本文档中定义的MDN为邮件用户提供了有价值的信息；但是，MDN不能作为收件人看到或不看到邮件的保证。即使MDN不是主动伪造的，也可能在运输过程中丢失。接收方可能会以某种方式绕过MDN发布机制。
One possible solution for this purpose can be found in RFC-SEC-SERVICES [RFC2634].
在RFC-SEC-SERVICES[RFC2634]中可以找到一种可能的解决方案。
The MDN request mechanism introduces an additional way of mail bombing a mailbox. The MDN request notification provides an address to which MDN's should be sent. It is possible for an attacking agent to send a potentially large set of messages to otherwise unsuspecting third party recipients with a false Disposition-Notification-To address. Automatic or simplistic processing of such requests would result in a flood of MDN notifications to the target of the attack. Additionally, as generated MDN notifications can include the full content of messages that caused them and thus they can be bigger than such messages, they can be used for bandwidth amplification attacks. Such an attack could overrun the storage capacity of the targeted mailbox and/or of the mail transport system, and deny service.
MDN请求机制引入了另一种邮件轰炸邮箱的方式。MDN请求通知提供MDN应发送到的地址。攻击代理可能会向其他毫无戒心的第三方收件人发送一组潜在的大量消息，并向地址发送错误的处置通知。自动或简单地处理此类请求将导致大量MDN通知发送到攻击目标。此外，由于生成的MDN通知可能包含导致它们的消息的全部内容，因此它们可能比此类消息大，因此可用于带宽放大攻击。此类攻击可能会超出目标邮箱和/或邮件传输系统的存储容量，并拒绝服务。
For that reason, MDN's SHOULD NOT be sent automatically where the Disposition-Notification-To address is different from the SMTP "MAIL FROM" address (which is carried in the Return-Path header field). See Section 2.1 for further discussion.
因此，如果发送到地址的处置通知不同于SMTP“邮件发件人”地址（在返回路径标头字段中携带），则不应自动发送MDN。进一步讨论见第2.1节。
NOTE: The following lexical tokens are defined in RFC-MSGFMT [RFC5322]: CRLF, FWS, CFWS, field-name, mailbox-list, msg-id, text, comment, and word. The following lexical tokens are defined in RFC-SMTP [RFC5321]: Atom. (Note that RFC-MSGFMT [RFC5322] also defines "atom", but the version from RFC-SMTP [RFC5321] is more restrictive and this more restrictive version is used in this document.) The "encoded-word" construct defined in RFC-MIME-HEADER [RFC2047] is allowed everywhere where RFC-MSGFMT [RFC5322] "comment" is used, for example, in CFWS.
注意：以下词汇标记在RFC-MSGFMT[RFC5322]中定义：CRLF、FWS、CFWS、字段名、邮箱列表、消息id、文本、注释和word。以下词法标记在RFC-SMTP[RFC5321]中定义：Atom。（请注意，RFC-MSGFMT[RFC5322]还定义了“atom”，但来自RFC-SMTP[RFC5321]的版本限制更严格，本文档中使用了此更严格的版本。）在使用RFC-MIME-HEADER[RFC2047]的任何地方，例如在CFWS中，都允许使用RFC-MSGFMT[RFC5322]“注释”中定义的“编码字”构造。
OWS = [CFWS]
; Optional whitespace.
; MDN generators SHOULD use "*WSP"
; (Typically a single space or nothing.
; It SHOULD be nothing at the end of a field.),
; unless an RFC 5322 "comment" is required.
;
; MDN parsers MUST parse it as "[CFWS]".
OWS = [CFWS]
; Optional whitespace.
; MDN generators SHOULD use "*WSP"
; (Typically a single space or nothing.
; It SHOULD be nothing at the end of a field.),
; unless an RFC 5322 "comment" is required.
;
; MDN parsers MUST parse it as "[CFWS]".
Message header fields: mdn-request-header = "Disposition-Notification-To" ":" mailbox-list CRLF
消息头字段：mdn请求头=“处置通知到”“：”邮箱列表CRLF
Disposition-Notification-Options = "Disposition-Notification-Options" ":" [FWS] disposition-notification-parameter-list CRLF
处置通知选项=“处置通知选项”：“[FWS]处置通知参数列表CRLF
disposition-notification-parameter-list = disposition-notification-parameter *([FWS] ";" [FWS] disposition-notification-parameter)
处置通知参数列表=处置通知参数*（[FWS]；“[FWS]处置通知参数）
disposition-notification-parameter = attribute [FWS] "=" [FWS] importance [FWS] "," [FWS] value *([FWS] "," [FWS] value)
处置通知参数=属性[FWS]“=”[FWS]重要性[FWS]，“[FWS]值*（[FWS]，“[FWS]值）
importance = "required" / "optional"
importance = "required" / "optional"
attribute = Atom
attribute = Atom
value = word
value = word
original-recipient-header = "Original-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS CRLF
原始收件人标头=“原始收件人”“：“OWS地址类型OWS”；“OWS通用地址OWS CRLF”
Report content:
disposition-notification-content =
[ reporting-ua-field CRLF ]
[ mdn-gateway-field CRLF ]
[ original-recipient-field CRLF ]
final-recipient-field CRLF
[ original-message-id-field CRLF ]
disposition-field CRLF
*( error-field CRLF )
*( extension-field CRLF )
Report content:
disposition-notification-content =
[ reporting-ua-field CRLF ]
[ mdn-gateway-field CRLF ]
[ original-recipient-field CRLF ]
final-recipient-field CRLF
[ original-message-id-field CRLF ]
disposition-field CRLF
*( error-field CRLF )
*( extension-field CRLF )
address-type = Atom
address-type = Atom
mta-name-type = Atom
mta-name-type = Atom
reporting-ua-field = "Reporting-UA" ":" OWS ua-name OWS [ ";" OWS ua-product OWS ]
报告ua字段=“报告ua”“：“OWS ua名称OWS[”；“OWS ua产品OWS]
ua-name = *text-no-semi
ua-name = *text-no-semi
ua-product = *([FWS] text)
ua-product = *([FWS] text)
text-no-semi = %d1-9 / ; "text" characters excluding NUL, CR,
%d11 / %d12 / %d14-58 / %d60-127 ; LF, or semi-colon
text-no-semi = %d1-9 / ; "text" characters excluding NUL, CR,
%d11 / %d12 / %d14-58 / %d60-127 ; LF, or semi-colon
mdn-gateway-field = "MDN-Gateway" ":" OWS mta-name-type OWS ";" OWS mta-name
mdn网关字段=“mdn网关”“：“OWS mta名称类型OWS”；“OWS mta名称”
mta-name = *text
mta-name = *text
original-recipient-field = "Original-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS
原始收件人字段=“原始收件人”“：“OWS地址类型OWS”；“OWS通用地址OWS”
generic-address = *text
generic-address = *text
final-recipient-field = "Final-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS
最终收件人字段=“最终收件人”“：“OWS地址类型OWS”；“OWS通用地址OWS”
original-message-id-field = "Original-Message-ID" ":" msg-id
原始邮件id字段=“原始邮件id”“：”消息id
disposition-field = "Disposition" ":" OWS disposition-mode OWS ";" OWS disposition-type [ OWS "/" OWS disposition-modifier *( OWS "," OWS disposition-modifier ) ] OWS
处置字段=“处置”“：“OWS处置模式OWS”；“OWS处置类型[OWS”/“OWS处置修饰符*（OWS”，“OWS处置修饰符）]OWS
disposition-mode = action-mode OWS "/" OWS sending-mode
处置模式=行动模式OWS/“OWS发送模式”
action-mode = "manual-action" / "automatic-action"
action-mode = "manual-action" / "automatic-action"
sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"
sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"
disposition-type = "displayed" / "deleted" / "dispatched" /
"processed"
disposition-type = "displayed" / "deleted" / "dispatched" /
"processed"
disposition-modifier = "error" / disposition-modifier-extension
处置修饰符=“错误”/“处置修饰符扩展”
disposition-modifier-extension = Atom
disposition-modifier-extension = Atom
error-field = "Error" ":" *([FWS] text)
error-field = "Error" ":" *([FWS] text)
extension-field = extension-field-name ":" *([FWS] text)
extension-field = extension-field-name ":" *([FWS] text)
extension-field-name = field-name
extension-field-name = field-name
NOTE: This section provides non-binding recommendations for the construction of mail gateways that wish to provide semi-transparent disposition notifications between the Internet and another electronic mail system. Specific MDN gateway requirements for a particular pair of mail systems may be defined by other documents.
注：本节提供了无约束力的建议，用于构建希望在Internet和其他电子邮件系统之间提供半透明处置通知的邮件网关。特定邮件系统对的特定MDN网关要求可由其他文档定义。
A mail gateway may issue an MDN to convey the contents of a "foreign" disposition notification over Internet Mail. When there are appropriate mappings from the foreign notification elements to MDN fields, the information may be transmitted in those MDN fields. Additional information (such as what might be needed to tunnel the foreign notification through the Internet) may be defined in extension MDN fields. (Such fields should be given names that identify the foreign mail protocol, e.g., X400-* for X.400 protocol elements [X.400]).
邮件网关可以发出MDN，以通过Internet邮件传递“外来”处置通知的内容。当存在从外部通知元素到MDN字段的适当映射时，可以在这些MDN字段中传输信息。其他信息（例如通过Internet传输外部通知可能需要什么）可以在扩展MDN字段中定义。（此类字段应给出标识外文邮件协议的名称，例如，对于X.400协议元素[X.400]），X400-*。
The gateway must attempt to supply reasonable values for the Reporting-UA, Final-Recipient, and Disposition fields. These will normally be obtained by translating the values from the foreign notification into their Internet-style equivalents. However, some loss of information is to be expected.
网关必须尝试为报告UA、最终收件人和处置字段提供合理的值。通常通过将外来通知中的值转换为其互联网风格的等效值来获得这些值。但是，预计会有一些信息丢失。
The sender-specified recipient address and the original message-id, if present in the foreign notification, should be preserved in the Original-Recipient and Original-Message-ID fields.
发件人指定的收件人地址和原始邮件id（如果存在于外部通知中）应保留在原始收件人和原始邮件id字段中。
The gateway should also attempt to preserve the "final" recipient address from the foreign system. Whenever possible, foreign protocol elements should be encoded as meaningful printable ASCII strings.
网关还应尝试从外部系统保留“最终”收件人地址。只要可能，外部协议元素应编码为有意义的可打印ASCII字符串。
For MDNs produced from foreign disposition notifications, the name of the gateway MUST appear in the MDN-Gateway field of the MDN.
对于由外部处置通知生成的MDN，网关的名称必须出现在MDN的MDN网关字段中。
It may be possible to gateway MDNs from the Internet into a foreign mail system. The primary purpose of such gatewaying is to convey disposition information in a form that is usable by the destination system. A secondary purpose is to allow "tunneling" of MDNs through foreign mail systems in case the MDN may be gatewayed back into the Internet.
可以将MDN从Internet网关连接到外部邮件系统。这种网关的主要目的是以目的地系统可用的形式传递处置信息。第二个目的是允许MDN通过外部邮件系统“隧道”传输，以防MDN通过网关返回互联网。
In general, the recipient of the MDN (i.e., the sender of the original message) will want to know, for each recipient: the closest available approximation to the original recipient address and the disposition (displayed, printed, etc.).
通常，MDN的收件人（即原始邮件的发件人）希望知道每个收件人与原始收件人地址和处置（显示、打印等）最接近的可用近似值。
If possible, the gateway should attempt to preserve the Original-Recipient address and Original-Message-ID (if present) in the resulting foreign disposition report.
如果可能，网关应尝试在生成的外部处置报告中保留原始收件人地址和原始邮件ID（如果存在）。
If it is possible to tunnel an MDN through the destination environment, the gateway specification may define a means of preserving the MDN information in the disposition reports used by that environment.
如果可以通过目标环境对MDN进行隧道传输，网关规范可以定义在该环境使用的处置报告中保存MDN信息的方法。
By use of the separate Disposition-Notification-To request header field, this specification offers a richer functionality than most, if not all, other email systems. In most other email systems, the notification recipient is identical to the message sender as indicated in the "from" address. There are two interesting cases when gatewaying into such systems:
通过使用单独的Disposition Notification To request header字段，该规范提供了比大多数（如果不是全部的话）其他电子邮件系统更丰富的功能。在大多数其他电子邮件系统中，通知收件人与“发件人”地址中指示的邮件发件人相同。当网关进入此类系统时，有两种有趣的情况：
1. If the address in the Disposition-Notification-To header field is identical to the address in the SMTP "MAIL FROM", the expected behavior will result, even if the Disposition-Notification-To information is lost. Systems should propagate the MDN request.
1. 如果处置通知至标头字段中的地址与SMTP“邮件发件人”中的地址相同，则即使处置通知至信息丢失，也会导致预期行为。系统应该传播MDN请求。
2. If the address in the Disposition-Notification-To header field is different from the address in the SMTP "MAIL FROM", gatewaying into a foreign system without a separate notification address will result in unintended behavior. This is especially important when the message arrives via a mailing list expansion software that may specifically replace the SMTP "MAIL FROM" address with an alternate address. In such cases, the MDN request should not be gatewayed and should be silently dropped. This is consistent with other forms of non-support for MDN.
2. 如果处置通知标题字段中的地址与SMTP“邮件发件人”中的地址不同，则在没有单独通知地址的情况下通过网关进入外部系统将导致意外行为。当邮件通过邮件列表扩展软件到达时，这一点尤为重要，该软件可能会专门将SMTP“邮件发件人”地址替换为备用地址。在这种情况下，MDN请求不应该被网关化，而应该被静默地丢弃。这与其他形式的不支持MDN是一致的。
NOTE: This example is provided as illustration only and is not considered part of the MDN protocol specification. If the example conflicts with the protocol definition above, the example is wrong.
注：此示例仅作为说明提供，不被视为MDN协议规范的一部分。如果该示例与上面的协议定义冲突，则该示例是错误的。
Likewise, the use of *-type subfield names or extension fields in this example is not to be construed as a definition for those type names or extension fields.
同样，本例中使用的*-型子字段名或扩展字段也不应解释为这些类型名或扩展字段的定义。
This is an MDN issued after a message has been displayed to the user of an Internet Mail user agent.
这是在向Internet邮件用户代理的用户显示消息后发出的MDN。
Date: Wed, 20 Sep 1995 00:19:00 (EDT) -0400
From: Joe Recipient <Joe_Recipient@example.com>
Message-Id: <199509200019.12345@example.com>
Subject: Disposition notification
To: Jane Sender <Jane_Sender@example.org>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=disposition-notification;
boundary="RAA14128.773615765/example.com"
Date: Wed, 20 Sep 1995 00:19:00 (EDT) -0400
From: Joe Recipient <Joe_Recipient@example.com>
Message-Id: <199509200019.12345@example.com>
Subject: Disposition notification
To: Jane Sender <Jane_Sender@example.org>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=disposition-notification;
boundary="RAA14128.773615765/example.com"
--RAA14128.773615765/example.com
--RAA14128.773615765/example.com
The message sent on 1995 Sep 19 at 13:30:00 (EDT) -0400 to Joe Recipient <Joe_Recipient@example.com> with subject "First draft of report" has been displayed. This is no guarantee that the message has been read or understood.
该邮件于1995年9月19日13:30:00（美国东部夏令时）-0400发送给Joe收件人<Joe_Recipient@example.com>主题为“报告初稿”的文件已显示。这并不能保证信息已被阅读或理解。
--RAA14128.773615765/example.com Content-Type: message/disposition-notification
--RAA14128.773615765/example.com内容类型：消息/处置通知
Reporting-UA: joes-pc.cs.example.com; Foomail 97.1
Original-Recipient: rfc822;Joe_Recipient@example.com
Final-Recipient: rfc822;Joe_Recipient@example.com
Original-Message-ID: <199509192301.23456@example.org>
Disposition: manual-action/MDN-sent-manually; displayed
Reporting-UA: joes-pc.cs.example.com; Foomail 97.1
Original-Recipient: rfc822;Joe_Recipient@example.com
Final-Recipient: rfc822;Joe_Recipient@example.com
Original-Message-ID: <199509192301.23456@example.org>
Disposition: manual-action/MDN-sent-manually; displayed
--RAA14128.773615765/example.com Content-Type: message/rfc822
--RAA14128.773615765/example.com内容类型：message/rfc822
[original message optionally goes here]
[原始信息可在此显示]
--RAA14128.773615765/example.com--
--RAA14128.773615765/example.com--
IANA has completed the following actions:
IANA已完成以下操作：
1. IANA has updated the registration template for the message/ disposition-notification media type to match what appears in Section 3.1 of this document and updated the reference for the media type to point to this document (instead of to RFC 3798).
1. IANA已更新消息/处置通知介质类型的注册模板，以匹配本文件第3.1节中出现的内容，并更新了介质类型的参考，以指向本文件（而不是RFC 3798）。
2. The registries specified here already exist; this section updates their documentation. IANA has changed the reference document for the three Message Disposition Notification Parameters registries to point to this document (instead of to RFC 3798).
2. 此处指定的注册表已存在；本节更新了他们的文档。IANA已将三个消息处置通知参数注册表的参考文档更改为指向此文档（而不是RFC 3798）。
This document specifies three types of parameters that must be registered with the Internet Assigned Numbers Authority (IANA). All of them use the "Specification Required" IANA registration policy [RFC5226].
本文件规定了三种类型的参数，必须向互联网分配号码管理局（IANA）注册。它们都使用“规范要求”IANA注册策略[RFC5226]。
The forms below are for use when registering a new disposition-notification-parameter name for the Disposition-Notification-Options header field, a new disposition modifier name, or a new MDN extension field. Each piece of information required by a registration form may be satisfied either by providing the information on the form itself or by including a reference to a published and publicly available specification that includes the necessary information. IANA MAY reject registrations because of incomplete registration forms or incomplete specifications.
在为处置通知选项标题字段、新处置修改器名称或新MDN扩展字段注册新处置通知参数名称时，可使用以下表格。注册表格所需的每一条信息都可以通过在表格上提供信息或包括对已发布和公开的规范（包括必要信息）的引用来满足。IANA可能会因为登记表不完整或规范不完整而拒绝登记。
To register, complete the following applicable form and send it via electronic mail to <IANA@IANA.ORG>.
要注册，请填写以下适用表格并通过电子邮件发送至<IANA@IANA.ORG>.
10.1. Disposition-Notification-Options Header Field disposition-notification-parameter Names
10.1. 处置通知选项标题字段处置通知参数名称
A registration for a Disposition-Notification-Options header field disposition-notification-parameter name MUST include the following information:
处置通知选项标题字段处置通知参数名称的注册必须包括以下信息：
a. The proposed disposition-notification-parameter name.
a. 建议的处置通知参数名称。
b. The syntax for disposition-notification-parameter values, specified using BNF, ABNF, regular expressions, or other non-ambiguous language.
b. 处置通知参数值的语法，使用BNF、ABNF、正则表达式或其他非歧义语言指定。
c. If disposition-notification-parameter values are not composed entirely of graphic characters from the US-ASCII repertoire, a specification for how they are to be encoded as graphic US-ASCII characters in a Disposition-Notification-Options header field.
c. 如果处置通知参数值并非完全由US-ASCII指令表中的图形字符组成，则说明如何在处置通知选项标题字段中将其编码为图形US-ASCII字符。
d. A reference to a permanent and readily available public specification that describes the semantics of the disposition-notification-parameter values.
d. 一种对永久性且随时可用的公共规范的引用，该规范描述了处置通知参数值的语义。
A registration for a disposition-modifier name (used in the Disposition field of a message/disposition-notification) MUST include the following information:
处置修改器名称的注册（在消息/处置通知的处置字段中使用）必须包括以下信息：
a. The proposed disposition-modifier name.
a. 建议的处置修改器名称。
b. A reference to a permanent and readily available public specification that describes the semantics of the disposition modifier.
b. 对描述处置修饰符语义的永久且随时可用的公共规范的引用。
A registration for an MDN extension-field name MUST include the following information:
MDN扩展字段名的注册必须包括以下信息：
a. The proposed extension field name.
a. 建议的扩展字段名。
b. The syntax for extension values, specified using BNF, ABNF, regular expressions, or other non-ambiguous language.
b. 使用BNF、ABNF、正则表达式或其他非歧义语言指定的扩展值的语法。
c. If extension-field values are not composed entirely of graphic characters from the US-ASCII repertoire, a specification for how they are to be encoded as graphic US-ASCII characters in a Disposition-Notification-Options header field.
c. 如果扩展字段值不完全由US-ASCII指令表中的图形字符组成，则说明如何在处置通知选项标题字段中将其编码为图形US-ASCII字符。
d. A reference to a permanent and readily available public specification that describes the semantics of the extension field.
d. 对描述扩展字段语义的永久且随时可用的公共规范的引用。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 5321DOI 10.17487/RFC5321，2008年10月<http://www.rfc-editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <http://www.rfc-editor.org/info/rfc5322>.
[RFC5322]Resnick，P.，Ed.，“互联网信息格式”，RFC 5322，DOI 10.17487/RFC5322，2008年10月<http://www.rfc-editor.org/info/rfc5322>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <http://www.rfc-editor.org/info/rfc2045>.
[RFC2045]Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 2045，DOI 10.17487/RFC20451996年11月<http://www.rfc-editor.org/info/rfc2045>.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <http://www.rfc-editor.org/info/rfc2046>.
[RFC2046]Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 2046，DOI 10.17487/RFC2046，1996年11月<http://www.rfc-editor.org/info/rfc2046>.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, DOI 10.17487/RFC2047, November 1996, <http://www.rfc-editor.org/info/rfc2047>.
[RFC2047]Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，DOI 10.17487/RFC2047，1996年11月<http://www.rfc-editor.org/info/rfc2047>.
[RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages", STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012, <http://www.rfc-editor.org/info/rfc6522>.
[RFC6522]Kucherawy，M.，Ed.，“用于报告邮件系统管理消息的多部分/报告媒体类型”，STD 73，RFC 6522，DOI 10.17487/RFC6522，2012年1月<http://www.rfc-editor.org/info/rfc6522>.
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, DOI 10.17487/RFC3461, January 2003, <http://www.rfc-editor.org/info/rfc3461>.
[RFC3461]Moore，K.，“用于传递状态通知（DSN）的简单邮件传输协议（SMTP）服务扩展”，RFC 3461，DOI 10.17487/RFC3461，2003年1月<http://www.rfc-editor.org/info/rfc3461>.
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, DOI 10.17487/RFC3464, January 2003, <http://www.rfc-editor.org/info/rfc3464>.
[RFC3464]Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 3464，DOI 10.17487/RFC3464，2003年1月<http://www.rfc-editor.org/info/rfc3464>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3503] Melnikov, A., "Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP)", RFC 3503, DOI 10.17487/RFC3503, March 2003, <http://www.rfc-editor.org/info/rfc3503>.
[RFC3503]Melnikov，A.，“互联网消息访问协议（IMAP）的消息处置通知（MDN）配置文件”，RFC 3503，DOI 10.17487/RFC3503，2003年3月<http://www.rfc-editor.org/info/rfc3503>.
[RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, DOI 10.17487/RFC2634, June 1999, <http://www.rfc-editor.org/info/rfc2634>.
[RFC2634]Hoffman，P.，Ed.“S/MIME的增强安全服务”，RFC 2634，DOI 10.17487/RFC2634，1999年6月<http://www.rfc-editor.org/info/rfc2634>.
[RFC3249] Cancio, V., Moldovan, M., Tamura, H., and D. Wing, "Implementers Guide for Facsimile Using Internet Mail", RFC 3249, DOI 10.17487/RFC3249, September 2002, <http://www.rfc-editor.org/info/rfc3249>.
[RFC3249]Cancio，V.，Moldovan，M.，Tamura，H.，和D.Wing，“互联网邮件传真实施指南”，RFC 3249，DOI 10.17487/RFC3249，2002年9月<http://www.rfc-editor.org/info/rfc3249>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, <http://www.rfc-editor.org/info/rfc3501>.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 3501，DOI 10.17487/RFC3501，2003年3月<http://www.rfc-editor.org/info/rfc3501>.
[RFC3801] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, DOI 10.17487/RFC3801, June 2004, <http://www.rfc-editor.org/info/rfc3801>.
[RFC3801]Vaudreuil，G.和G.Parsons，“互联网邮件语音配置文件-第2版（VPIMv2）”，RFC 3801，DOI 10.17487/RFC3801，2004年6月<http://www.rfc-editor.org/info/rfc3801>.
[RFC5233] Murchison, K., "Sieve Email Filtering: Subaddress Extension", RFC 5233, DOI 10.17487/RFC5233, January 2008, <http://www.rfc-editor.org/info/rfc5233>.
[RFC5233]Murchison，K.，“筛选电子邮件过滤：子地址扩展”，RFC 5233，DOI 10.17487/RFC5233，2008年1月<http://www.rfc-editor.org/info/rfc5233>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5429] Stone, A., Ed., "Sieve Email Filtering: Reject and Extended Reject Extensions", RFC 5429, DOI 10.17487/RFC5429, March 2009, <http://www.rfc-editor.org/info/rfc5429>.
[RFC5429]Stone，A.，Ed.“筛选电子邮件过滤：拒绝和扩展拒绝扩展”，RFC 5429，DOI 10.17487/RFC5429，2009年3月<http://www.rfc-editor.org/info/rfc5429>.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, <http://www.rfc-editor.org/info/rfc5598>.
[RFC5598]Crocker，D.，“互联网邮件体系结构”，RFC 5598，DOI 10.17487/RFC5598，2009年7月<http://www.rfc-editor.org/info/rfc5598>.
[RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", RFC 6533, DOI 10.17487/RFC6533, February 2012, <http://www.rfc-editor.org/info/rfc6533>.
[RFC6533]Hansen，T.，Ed.，Newman，C.，和A.Melnikov，“国际化交付状态和处置通知”，RFC 6533，DOI 10.17487/RFC6533，2012年2月<http://www.rfc-editor.org/info/rfc6533>.
[X.400] International Telecommunications Union, "Message handling system and service overview", ITU-T Recommendation F.400/X.400, June 1999.
[X.400]国际电信联盟，“信息处理系统和服务概述”，ITU-T建议F.400/X.400，1999年6月。
Changed IANA registration for different subregistries to "Specification Required" to match what is already used by IANA.
将不同分区的IANA注册更改为“所需规范”，以匹配IANA已使用的内容。
Updated IANA registration template for message/disposition-notification.
已更新消息/处置通知的IANA注册模板。
"X-" fields no longer reserved for experimental use and can now be registered in compliance with RFC 6648.
“X-”字段不再保留供实验使用，现在可以按照RFC 6648注册。
Fixed the default MTA-name-type used in "MDN-Gateway" to be "dns".
修复了“MDN网关”中使用的默认MTA名称类型为“dns”。
Strengthen requirements on obtaining user consent in order to protect user privacy.
加强获得用户同意的要求，以保护用户隐私。
Removed discussion of using source routes with MDNs, as source route is a deprecated Email feature.
删除了关于将源路由与MDN一起使用的讨论，因为源路由是一种不推荐使用的电子邮件功能。
The values of "dispatched" and "processed" were lost from the ABNF for "disposition-type". (Erratum #691)
ABNF中“处置类型”的“已调度”和“已处理”的值丢失。（勘误表691）
Because the warning disposition modifier was previously removed, the warning-field has also been removed. (Erratum #692)
由于警告配置修改器先前已删除，因此警告字段也已删除。（勘误表692）
Because the failed disposition type was previously removed, the failure-field has also been removed.
Because the failed disposition type was previously removed, the failure-field has also been removed.translate error, please retry
The ABNF for ua-name and ua-product included a semi-colon, which could not be distinguished from *text in the production. The ua-name was restricted to not include semi-colon. Semi-colon can still appear in the ua-product.
ua名称和ua产品的ABNF包含分号，无法与生产中的*文本区分。ua名称被限制为不包含分号。分号仍然可以出现在ua产品中。
Removed recommendation to include the MUA DNS host name in the "Reporting-UA" MDN field.
删除了在“报告UA”MDN字段中包含MUA DNS主机名的建议。
The ABNF did not indicate all places that whitespace was allowable, in particular folding whitespace, although all implementations allow whitespace and folding in the header fields just like any other header field formatted as described in RFC-MSGFMT [RFC5322]. There were also a number of places in the ABNF that inconsistently permitted comments and whitespace in one leg of the production and not another. The ABNF now specifies FWS and CFWS in several places that should have already been specified by the grammar.
ABNF并没有指出所有允许空白的地方，特别是折叠空白，尽管所有实现都允许在标题字段中使用空白和折叠，就像RFC-MSGFMT[RFC5322]中所述的任何其他格式的标题字段一样。在ABNF中也有一些地方不一致地允许在制作的一段而不是另一段中出现评论和空白。ABNF现在在几个应该已经由语法指定的地方指定FW和CFW。
Extension-field was defined in the collected grammar but not in the main text.
扩展字段在收集的语法中定义，但在主文本中未定义。
The comparison of mailboxes in Disposition-Notification-To to the Return-Path addr-spec was clarified.
澄清了处置通知中邮箱与返回路径addr规范的比较。
The use of the grammar production "parameter" was confusing with the RFC 2045 [RFC2045] production of the same name, as well as other uses of the same term. These have been clarified.
语法产物“参数”的使用与同名的RFC 2045[RFC2045]产物以及相同术语的其他用法混淆。这些问题已得到澄清。
A clarification was added on the extent of the 7bit nature of MDNs.
增加了对MDN 7比特性质范围的澄清。
Uses of the terms "may" and "might" were clarified.
对“可能”和“可能”两个词的用法作了澄清。
A clarification was added on the order of the fields in the message/ disposition-notification content.
对消息/处置通知内容中字段的顺序添加了说明。
Acknowledgements
致谢
The contributions of Bruce Lilly, Alfred Hoenes, Barry Leiba, Ben Campbell, Pete Resnick, Donald Eastlake, and Alissa Cooper are gratefully acknowledged for this revision.
感谢布鲁斯·莉莉、阿尔弗雷德·霍恩斯、巴里·莱巴、本·坎贝尔、皮特·雷斯尼克、唐纳德·伊斯特莱克和艾莉莎·库珀对本次修订的贡献。
The contributions of Roger Fajman and Greg Vaudreuil to earlier draft versions of this document are also gratefully acknowledged.
感谢Roger Fajman和Greg Vaudreuil对本文件早期草稿的贡献。
Authors' Addresses
作者地址
Tony Hansen (editor) AT&T Laboratories 200 Laurel Ave. South Middletown, NJ 07748 United States of America
Tony Hansen（编辑）美国电话电报公司实验室美国新泽西州南米德尔顿劳雷尔大道200号，邮编07748
Email: tony@att.com
Email: tony@att.com
Alexey Melnikov (editor) Isode Ltd 14 Castle Mews Hampton, Middlesex TW12 2NP United Kingdom
Alexey Melnikov（编辑）Isode有限公司14 Castle Mews Hampton，米德尔塞克斯TW12 2NP英国
Email: Alexey.Melnikov@isode.com
Email: Alexey.Melnikov@isode.com