Network Working Group T. Hansen, Ed.
Request for Comments: 3798 AT&T Laboratories
Obsoletes: 2298 G. Vaudreuil, Ed.
Updates: 3461, 2046 Lucent Technologies
Category: Standards Track May 2004
Network Working Group T. Hansen, Ed.
Request for Comments: 3798 AT&T Laboratories
Obsoletes: 2298 G. Vaudreuil, Ed.
Updates: 3461, 2046 Lucent Technologies
Category: Standards Track May 2004
Message Disposition Notification
消息处置通知
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 (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
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 headers 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 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 multi-protocol 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邮件“隧道”发送外来通知。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Purposes . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Terminology. . . . . . . . . . . . . . . . . . . . . . . 4
2. Requesting Message Disposition Notifications . . . . . . . . . 4
2.1. The Disposition-Notification-To Header . . . . . . . . . 4
2.2. The Disposition-Notification-Options Header. . . . . . . 6
2.3. The Original-Recipient Header. . . . . . . . . . . . . . 7
2.4. Use with the Message/Partial Content Type. . . . . . . . 8
3. FORMAT OF A MESSAGE DISPOSITION NOTIFICATION . . . . . . . . . 8
3.1. The message/disposition-notification content-type. . . . 9
3.2. Message/disposition-notification Fields. . . . . . . . . 11
3.3. Extension-fields . . . . . . . . . . . . . . . . . . . . 16
4. Timeline of Events . . . . . . . . . . . . . . . . . . . . . . 17
5. Conformance and Usage Requirements . . . . . . . . . . . . . . 18
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 19
6.1. Forgery. . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Privacy. . . . . . . . . . . . . . . . . . . . . . . . . 19
6.3. Non-Repudiation. . . . . . . . . . . . . . . . . . . . . 20
6.4. Mail Bombing . . . . . . . . . . . . . . . . . . . . . . 20
7. Collected Grammar. . . . . . . . . . . . . . . . . . . . . . . 20
8. Guidelines for Gatewaying MDNS . . . . . . . . . . . . . . . . 22
8.1. Gatewaying from other mail systems to MDNs . . . . . . . 23
8.2. Gatewaying from MDNs to other mail systems . . . . . . . 23
8.3. Gatewaying of MDN-requests to other mail systems . . . . 24
9. Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 25
10.1. Disposition-Notification-Options header parameter names. 26
10.2. Disposition modifier names . . . . . . . . . . . . . . . 26
10.3. MDN extension field names. . . . . . . . . . . . . . . . 26
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A - Changes from RFC 2298 . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Purposes . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Terminology. . . . . . . . . . . . . . . . . . . . . . . 4
2. Requesting Message Disposition Notifications . . . . . . . . . 4
2.1. The Disposition-Notification-To Header . . . . . . . . . 4
2.2. The Disposition-Notification-Options Header. . . . . . . 6
2.3. The Original-Recipient Header. . . . . . . . . . . . . . 7
2.4. Use with the Message/Partial Content Type. . . . . . . . 8
3. FORMAT OF A MESSAGE DISPOSITION NOTIFICATION . . . . . . . . . 8
3.1. The message/disposition-notification content-type. . . . 9
3.2. Message/disposition-notification Fields. . . . . . . . . 11
3.3. Extension-fields . . . . . . . . . . . . . . . . . . . . 16
4. Timeline of Events . . . . . . . . . . . . . . . . . . . . . . 17
5. Conformance and Usage Requirements . . . . . . . . . . . . . . 18
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 19
6.1. Forgery. . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Privacy. . . . . . . . . . . . . . . . . . . . . . . . . 19
6.3. Non-Repudiation. . . . . . . . . . . . . . . . . . . . . 20
6.4. Mail Bombing . . . . . . . . . . . . . . . . . . . . . . 20
7. Collected Grammar. . . . . . . . . . . . . . . . . . . . . . . 20
8. Guidelines for Gatewaying MDNS . . . . . . . . . . . . . . . . 22
8.1. Gatewaying from other mail systems to MDNs . . . . . . . 23
8.2. Gatewaying from MDNs to other mail systems . . . . . . . 23
8.3. Gatewaying of MDN-requests to other mail systems . . . . 24
9. Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 25
10.1. Disposition-Notification-Options header parameter names. 26
10.2. Disposition modifier names . . . . . . . . . . . . . . . 26
10.3. MDN extension field names. . . . . . . . . . . . . . . . 26
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A - Changes from RFC 2298 . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 30
This memo defines a [RFC-MIME-MEDIA] content-type 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].
此备忘录为消息处置通知（MDN）定义[RFC-MIME-MEDIA]内容类型。MDN可用于将成功传递后可能出现的几种情况中的任何一种情况通知邮件的发件人，例如显示邮件内容、打印邮件、删除（不显示）邮件或收件人拒绝提供MDN。本文定义的“消息/处置通知”内容类型旨在在[RFC-report]中定义的“多部分/报告”内容类型的框架内使用。
This memo defines the format of the notifications and the [RFC-MSGFMT] headers used to request them.
此备忘录定义了通知的格式以及用于请求通知的[RFC-MSGFMT]标题。
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 message 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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC-关键词]中所述进行解释。
All syntax descriptions use the ABNF specified by [RFC-MSGFMT], in which the lexical tokens (used below) are defined: "atom", "CRLF", "mailbox", "msg-id", and "text". The following lexical tokens are defined in the definition of the Content-Type header in [RFC-MIME-BODY]: "attribute" and "value".
所有语法描述都使用[RFC-MSGFMT]指定的ABNF，其中定义了词法标记（如下所示）：“atom”、“CRLF”、“mailbox”、“msg id”和“text”。[RFC-MIME-BODY]中内容类型头的定义中定义了以下词汇标记：“属性”和“值”。
Message disposition notifications are requested by including a Disposition-Notification-To header in the message. Further information to be used by the recipient's MUA in generating the MDN may be provided by also including Original-Recipient and/or Disposition-Notification-Options headers in the message.
通过在消息中包含对标头的处置通知来请求消息处置通知。接收方的MUA在生成MDN中使用的进一步信息也可以通过在消息中包括原始接收方和/或处置通知选项头部来提供。
A request for the receiving user agent to issue message disposition notifications is made by placing a Disposition-Notification-To header into the message. The syntax of the header is
接收用户代理发出消息处置通知的请求是通过将处置通知放置到消息头中发出的。标题的语法是
mdn-request-header = "Disposition-Notification-To" ":" mailbox *("," mailbox)
mdn request header=“处置通知到”“：”邮箱*（“，”邮箱）
The presence of a Disposition-Notification-To header in a message is merely a request for an MDN. The recipients' user agents are always free to silently ignore such a request. Alternatively, an explicit denial of the request for information about the disposition of the message may be sent using the "denied" disposition in an MDN.
消息中存在对消息头的处置通知只是对MDN的请求。接收者的用户代理总是可以无提示地忽略这样的请求。或者，可以使用MDN中的“拒绝”处置发送对关于消息处置的信息的请求的明确拒绝。
An MDN MUST NOT itself have a Disposition-Notification-To header. 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, 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。
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 or that a "denied" MDN is always sent in response to a request for an MDN.
虽然Internet标准通常不指定用户界面的行为，但强烈建议用户代理在发送MDN之前获得用户的同意。可以通过某种提示或对话框，或通过用户的首选项设置全局获得每条消息的同意。用户还可以全局指示永远不会发送MDN，或者总是发送“拒绝”MDN以响应MDN请求。
MDNs SHOULD NOT be sent automatically if the address in the Disposition-Notification-To header differs from the address in the Return-Path header (see [RFC-MSGFMT]). In this case, confirmation from the user SHOULD be obtained, if possible. If obtaining consent is not possible (e.g., because the user is not online at the time), then an MDN SHOULD NOT be sent.
如果处置通知到标头中的地址与返回路径标头中的地址不同，则不应自动发送MDN（请参见[RFC-MSGFMT]）。在这种情况下，如果可能，应获得用户的确认。如果无法获得同意（例如，因为用户当时不在线），则不应发送MDN。
Confirmation from the user SHOULD be obtained (or no MDN sent) if there is no Return-Path header in the message, or if there is more than one distinct address in the Disposition-Notification-To header.
如果消息中没有返回路径标头，或者如果到标头的处置通知中有多个不同的地址，则应获得用户的确认（或未发送MDN）。
The comparison of the addresses should be done using only the addr-spec (local-part "@" domain) portion, excluding any phrase and route. The comparison MUST be case-sensitive for the local-part and case-insensitive for the domain part.
应仅使用addr spec（本地部分“@”域）部分比较地址，不包括任何短语和路由。本地部分的比较必须区分大小写，域部分的比较必须区分大小写。
If the message contains more than one Return-Path header, 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用于邮件轰炸的可能性。
A message that contains a Disposition-Notification-To header SHOULD also contain a Message-ID header as specified in [RFC-MSGFMT]. This will permit automatic correlation of MDNs with their original messages by user agents.
包含头处置通知的消息还应包含[RFC-MSGFMT]中指定的消息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 and one without. Many of the other headers of the message (e.g., To, Cc) will be the same in both copies. The recipients in the respective message envelopes determine for whom message disposition notifications are requested and for whom they are not. If desired, the Message-ID header 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 headers. 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 and some without.
如果需要为某些收件人而不是其他收件人请求邮件处置通知，则应发送邮件的两个副本，一个带有到标头的处置通知，另一个没有。消息的许多其他头（例如，To、Cc）在两个副本中都是相同的。各个邮件信封中的收件人确定为谁请求邮件处置通知以及不为谁请求邮件处置通知。如果需要，消息的两个副本中的消息ID报头可以相同。请注意，在其他情况下（如密件抄送），有必要发送具有稍微不同标题的多份邮件副本。这种情况加上需要为所有收件人的子集请求MDN，可能会导致发送两个以上的邮件副本，其中一些带有对邮件头的处置通知，而另一些则没有。
Messages posted to newsgroups SHOULD NOT have a Disposition-Notification-To header.
发布到新闻组的邮件不应具有到标题的处置通知。
Future 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 provides an extensible mechanism for such information. The syntax of this header is as follows:
本规范的未来扩展可能需要向接收方的MUA提供信息，以便对MDN的生成方式和内容进行额外控制。处置通知选项标头为此类信息提供了一种可扩展的机制。此标头的语法如下所示：
Disposition-Notification-Options = "Disposition-Notification-Options" ":" disposition-notification-parameters
处置通知选项=“处置通知选项”：“处置通知参数”
disposition-notification-parameters = parameter *(";" parameter)
disposition-notification-parameters = parameter *(";" parameter)
parameter = attribute "=" importance "," value *("," value)
parameter = attribute "=" importance "," value *("," value)
importance = "required" / "optional"
importance = "required" / "optional"
An importance of "required" indicates that interpretation of the parameter is necessary for proper generation of an MDN in response to this request. If an MUA does not understand the meaning of the parameter, it MUST NOT generate an MDN with any disposition type other than "failed" in response to the request. An importance of "optional" indicates that an MUA that does not understand the meaning of this parameter MAY generate an MDN in response anyway, ignoring the value of the parameter.
“required”的重要性表示，为了响应此请求，正确生成MDN，必须对参数进行解释。如果MUA不理解参数的含义，则不得生成具有除响应请求“失败”以外的任何处置类型的MDN。“可选”的重要性表示不理解此参数含义的MUA可能会生成MDN作为响应，忽略参数值。
No parameters are defined in this specification. Parameters may be defined in the future by later revisions or extensions to this specification. Parameter attribute names beginning with "X-" will
本规范中未定义任何参数。以后可通过本规范的后续修订或扩展来定义参数。以“X-”开头的参数属性名称将
never be defined as standard names; such names are reserved for experimental use. MDN parameter names not beginning with "X-" MUST be registered with the Internet Assigned Numbers Authority (IANA) and described in a standards-track RFC or an experimental RFC approved by the IESG. (See Section 10 for a registration form.)
永远不要被定义为标准名称；这些名称保留供实验使用。不以“X-”开头的MDN参数名称必须在互联网分配号码管理局（IANA）注册，并在IESG批准的标准跟踪RFC或实验RFC中描述。（登记表见第10节。）
If a required parameter is not understood or contains some sort of error, the receiving MUA SHOULD issue an MDN with a disposition type of "failed" (see Section 3.2.6), and include a Failure field (see Section 3.2.7) that further describes the problem. MDNs with the disposition type of "failed" and a "Failure" field MAY also be generated when other types of errors are detected in the parameters of the Disposition-Notification-Options header.
如果未理解所需参数或包含某种错误，接收MUA应发出处置类型为“失败”的MDN（见第3.2.6节），并包括进一步描述问题的失败字段（见第3.2.7节）。当在处置通知选项标头的参数中检测到其他类型的错误时，也可能会生成处置类型为“失败”和“失败”字段的MDN。
However, an MDN with a disposition type of "failed" MUST NOT be generated if the user has indicated a preference that MDNs are not to be sent. If user consent would be required for an MDN of some other disposition type to be sent, user consent SHOULD also be obtained before sending an MDN with a disposition type of "failed".
但是，如果用户已指示不发送MDN的首选项，则不得生成处置类型为“失败”的MDN。如果发送其他处置类型的MDN需要用户同意，则在发送处置类型为“失败”的MDN之前，还应获得用户同意。
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 MTA. 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] and [RFC-DSN-SMTP].
由于邮件在传输过程中可能会重写电子邮件地址，因此传递MTA提供原始收件人地址非常有用。按照[RFC-SMTP]和[RFC-DSN-SMTP]中的定义，传递MTA可能能够从SMTP RCPT to命令的ORCPT参数获取此信息。
[RFC-DSN-SMTP] is amended as follows: If the ORCPT information is available, the delivering MTA SHOULD insert an Original-Recipient header at the beginning of the message (along with the Return-Path header). The delivering MTA MAY delete any other Original-Recipient headers that occur in the message. The syntax of this header is as follows:
[RFC-DSN-SMTP]修改如下：如果ORCPT信息可用，则传递MTA应在邮件开头插入原始收件人标头（以及返回路径标头）。传递MTA可以删除邮件中出现的任何其他原始收件人标题。此标头的语法如下所示：
original-recipient-header = "Original-Recipient" ":" address-type ";" generic-address
原始收件人标题=“原始收件人”“：“地址类型”；“通用地址”
The address-type and generic-address token 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 headers Disposition-Notification-To, Disposition-Notification-Options, and Original-Recipient with the MIME message/partial content type ([RFC-MIME-MEDIA]) requires further definition.
使用MIME邮件/部分内容类型（[RFC-MIME-MEDIA]）的头处置通知、处置通知选项和原始收件人需要进一步定义。
When a message is segmented into two or more message/partial fragments, the three headers mentioned in the above paragraph SHOULD be placed in the "inner" or "enclosed" message (using the terms of [RFC-MIME-MEDIA]). These headers SHOULD NOT be used in the headers of any of the fragments themselves.
当一条消息被分割成两个或多个消息/部分片段时，上述段落中提到的三个标题应放在“内部”或“封闭”消息中（使用[RFC-MIME-MEDIA]术语）。这些头不应该在任何片段本身的头中使用。
When the multiple message/partial fragments are reassembled, the following applies. If these headers occur along with the other headers of a message/partial fragment message, they pertain to an MDN that will be generated for the fragment. If these headers occur in the headers of the "inner" or "enclosed" message (using the terms of [RFC-MIME-MEDIA]), they pertain to an MDN that will be generated for the reassembled message. Section 5.2.2.1 of [RFC-MIME-MEDIA]) is amended to specify that, in addition to the headers specified there, the three headers described in this specification are to be appended, in order, to the headers of the reassembled message. Any occurrences of the three headers defined here in the headers of the initial enclosing message must not be copied to the reassembled message.
当重新组装多个消息/部分片段时，以下内容适用。如果这些头与消息/部分片段消息的其他头一起出现，则它们属于将为片段生成的MDN。如果这些头出现在“内部”或“封闭”消息的头中（使用[RFC-MIME-MEDIA]的术语），则它们属于将为重新组装的消息生成的MDN。对[RFC-MIME-MEDIA]第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]). When multipart/report content is used to transmit an MDN:
消息处置通知是一个MIME消息，其顶级内容类型为multipart/report（在[RFC-report]中定义）。使用多部分/报告内容传输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].
(b) 如[RFC-report]中所述，多部分/报告的第一个组件包含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
(d) 如果要将原始邮件或邮件的一部分返回给发件人，则它将显示为多部分/报告的第三个组件。是否返回消息或部分消息由生成消息的MUA决定
MDN. However, in the case of encrypted messages requesting MDNs, encrypted message text MUST be returned, if it is returned at all, only in its original encrypted form.
MDN。但是，对于请求MDN的加密邮件，必须返回加密的邮件文本（如果返回了），并且只能以原始加密形式返回。
NOTE: For message disposition notifications gatewayed from foreign systems, the headers 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] headers that contain equivalent information. In particular, it is very desirable to preserve the subject and date fields from the original message.
注意：对于从外部系统网关发送的消息处置通知，原始消息的标题可能不可用。在这种情况下，可以省略MDN的第三个组件，或者它可以包含包含等效信息的“模拟的”[RFC-MSGFMT]报头。特别是，非常希望保留原始消息中的主题和日期字段。
The MDN MUST be addressed (in both the message header and the transport envelope) to the address(es) from the Disposition-Notification-To header from the original message for which the MDN is being generated.
MDN必须（在消息头和传输信封中）寻址到正在为其生成MDN的原始消息的处置通知到消息头的地址。
The From field of the message header of the MDN MUST contain the address of the person for whom the message disposition notification is being issued.
MDN消息头的“发件人”字段必须包含为其发出消息处置通知的人员的地址。
The envelope sender address (i.e., SMTP MAIL FROM) of the MDN MUST be null (<>), specifying that no Delivery Status Notification messages or 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.
消息处置通知本身不得请求MDN。也就是说，它不能包含对标头的处置通知。
The Message-ID header (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, MDNs may not be generated for some recipients for which MDNs were requested.
一个特定的MDN描述了一个收件人对一条消息的处理。一次邮件提交可能会生成多个MDN，每个收件人一个。但是，由于第2.1节中所述的情况，可能无法为请求MDN的某些收件人生成MDN。
The message/disposition-notification content-type is defined as follows:
消息/处置通知内容类型定义如下：
MIME type name: message
MIME类型名称：消息
MIME subtype name: disposition-notification
MIME子类型名称：处置通知
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 this memo.
安全注意事项：在本备忘录第6节中讨论。
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] header "fields". The syntax of the message/disposition-notification content is as follows:
消息/处置通知的正文由一个或多个“字段”组成，这些“字段”根据[RFC-MSGFMT]标题“字段”的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
*( failure-field CRLF )
*( error-field CRLF )
*( warning-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
*( failure-field CRLF )
*( error-field CRLF )
*( warning-field CRLF )
*( extension-field CRLF )
Since these fields are defined according to the rules of [RFC-MSGFMT], 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 any combination of upper and lower case letters. Comments in notification fields may use the "encoded-word" construct defined in [RFC-MIME-HEADER].
由于这些字段是根据[RFC-MSGFMT]的规则定义的，因此延续行和注释的约定相同。通过在每一行的开头加上空格或HTAB，通知字段可以延续到多行。括号中出现的文本被视为注释，而不是通知字段内容的一部分。字段名不区分大小写，因此通知字段的名称可以用大写和小写字母的任意组合拼写。通知字段中的注释可以使用[RFC-MIME-HEADER]中定义的“编码字”结构。
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.
(a) “地址类型”指定邮箱地址的格式。例如，Internet邮件地址使用“rfc822”地址类型。
address-type = atom
address-type = atom
(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.
(b) “MTA名称类型”指定邮件传输代理名称的格式。例如，对于Internet主机上的SMTP服务器，MTA名称是该主机的域名，并使用“dns”MTA名称类型。
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].) Registration forms for address-type and mta-name-type appear in [RFC-DSN-FORMAT].
Internet Assigned Numbers Authority（IANA）维护地址类型和mta名称类型值的注册表，以及每个值的含义说明，或对提供此类说明的一个或多个规范的引用。（在[RFC-DSN-SMTP]中定义了“rfc822”地址类型。）地址类型和mta名称类型的注册表格显示在[RFC-DSN-FORMAT]中。
reporting-ua-field = "Reporting-UA" ":" ua-name [ ";" ua-product ]
报告ua字段=“报告ua”“：“ua名称[”；“ua产品]
ua-name = *text
ua-name = *text
ua-product = *text
ua-product = *text
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. This field is optional, but recommended. For Internet Mail user agents, it is recommended that this field contain both: the DNS name of the particular instance of the MUA that generated the MDN, and the name of the product. For example,
MDN描述消息交付给收件人后的处置。在所有情况下，报告UA是执行MDN中所述处置的MUA。此字段是可选的，但建议使用。对于Internet邮件用户代理，建议此字段同时包含：生成MDN的MUA特定实例的DNS名称和产品名称。例如
Reporting-UA: pc.example.com; Foomail 97.1
报告UA:pc.example.com；Foomail97.1
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包含多个组件（例如，基本程序和插件），则可通过包含产品名称列表来表示。
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" ":" mta-name-type ";" mta-name
mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name
mta-name = *text
mta-name = *text
For gateways into Internet Mail, the MTA-name-type will normally be "smtp", and the mta-name will be the Internet domain name of the gateway.
对于进入Internet邮件的网关，MTA名称类型通常为“smtp”，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 from the message for which the MDN is being generated. If there is no Original-Recipient header in the message, then the Original-Recipient field MUST be omitted, unless the same information is reliably available some other way. If there is an Original-Recipient header in the original message (or original recipient information is reliably available some other way), then the Original-Recipient field must be supplied. If there is more than one Original-Recipient header in the message, the MUA may choose the one to use, or act as if no Original-Recipient header is present.
“原始收件人”字段表示为其发出MDN的邮件的发件人指定的原始收件人地址。对于Internet邮件，原始收件人字段的值是从生成MDN的邮件的原始收件人标头中获取的。如果消息中没有原始收件人标头，则必须省略原始收件人字段，除非通过其他方式可靠地获得相同的信息。如果原始邮件中有原始收件人标头（或原始收件人信息以其他方式可靠可用），则必须提供原始收件人字段。如果消息中有多个原始收件人标头，MUA可以选择要使用的一个，或者视为不存在原始收件人标头。
original-recipient-field = "Original-Recipient" ":" address-type ";" generic-address
原始收件人字段=“原始收件人”“：“地址类型”；“一般地址”
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-type field will normally be "rfc822", and the address will be according to the syntax specified in [RFC-MSGFMT]. The value "unknown" should be used if the Reporting MUA cannot determine the type of the original recipient address from the message envelope.
地址类型字段指示原始收件人地址的类型。如果消息来源于互联网，地址类型字段通常为“rfc822”，地址将符合[RFC-MSGFMT]中指定的语法。如果报告MUA无法从邮件信封确定原始收件人地址的类型，则应使用“未知”值。
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.
此地址与发件人提供的地址相同，可用于根据每个收件人自动将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" ":" address-type ";" generic-address
最终收件人字段=“最终收件人”“：“地址类型”；“一般地址”
The generic-address subfield of the Final-Recipient field MUST contain the mailbox address of the recipient (from the From header of the MDN) as it was when the MDN was generated by the MUA.
“最终收件人”字段的“通用地址”子字段必须包含收件人的邮箱地址（来自MDN的“发件人”标头），就像MUA生成MDN时一样。
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".
address type（地址类型）子字段表示报告MTA在该上下文中预期的地址类型。通过SMTP获得的收件人地址通常为地址类型“rfc822”。
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 of the message for which the MDN is issued. This field MUST be present if the original message contained a Message-ID header. 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].
msg id令牌在[RFC-MSGFMT]中指定。
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" ":" disposition-mode ";" disposition-type [ "/" disposition-modifier *( "," disposition-modifier ) ]
处置字段=“处置”“：“处置模式”；“处置类型[“/”处置修饰符*（“，”处置修饰符）]
disposition-mode = action-mode "/" sending-mode
处置模式=行动模式“/”发送模式
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"
处置类型=“已显示”/“已删除”
disposition-modifier = "error" / disposition-modifier-extension
处置修饰符=“错误”/“处置修饰符扩展”
disposition-modifier-extension = atom
disposition-modifier-extension = atom
The disposition-mode, disposition-type, and disposition-modifier may be spelled in any combination of upper and lower case characters.
处置模式、处置类型和处置修饰符可以用大写和小写字符的任意组合拼写。
The following disposition 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.
“手动操作”处置类型描述的处置是用户明确指示的结果，而不是某种自动执行的操作。
"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.
“自动操作”处置类型描述的处置是自动操作的结果，而不是用户对此消息的明确指示。
"Manual-action" and "automatic-action" are mutually exclusive. One or the other MUST be specified.
“手动操作”和“自动操作”是相互排斥的。必须指定其中一个。
"MDN-sent-manually" The user explicitly gave permission for this particular MDN to be sent.
“手动发送MDN”用户明确授予发送此特定MDN的权限。
"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已将邮件显示给正在阅读收件人邮箱的人。不能保证内容已被阅读或理解。
"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 is defined:
仅定义了扩展配置修改器：
disposition-modifier-extension Disposition modifiers may be defined in the future by later revisions or extensions to this specification. Disposition value names beginning with "X-" will never be defined as standard values; such names are reserved for experimental use. MDN disposition value names NOT beginning with "X-" MUST be registered with the Internet Assigned Numbers Authority (IANA) and described in a standards-track RFC or an experimental RFC approved by the IESG. (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
处置修饰符扩展处置修饰符可在将来通过本规范的后续修订或扩展来定义。以“X-”开头的处置值名称永远不会定义为标准值；这些名称保留供实验使用。不以“X-”开头的MDN处置值名称必须在互联网分配号码管理局（IANA）注册，并在IESG批准的标准跟踪RFC或实验RFC中进行说明。（注册表格见第10节。）接收MUA不理解处置修改器名称的MDN可以被忽略或放置在
user's mailbox without special interpretation. They MUST not cause any error message to be sent to the sender of the MDN.
没有特殊解释的用户邮箱。它们不得导致向MDN的发件人发送任何错误消息。
If an MUA developer does not wish to register the meanings of such disposition modifier extensions, "X-" modifiers may be used for this purpose. To avoid name collisions, the name of the MUA implementation should follow the "X-", (e.g., "X-Foomail-").
如果MUA开发人员不希望注册此类处置修饰符扩展的含义，则可为此目的使用“X-”修饰符。为了避免名称冲突，MUA实现的名称应该跟在“X-”后面（例如，“X-Foomail-”）。
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 Failure, Error, and Warning fields are used to supply additional information in the form of text messages when the "failure" disposition type, "error" disposition modifier, and/or the "warning" disposition modifier appear. The syntax is as follows:
“失败”、“错误”和“警告”字段用于在出现“失败”处置类型、“错误”处置修饰符和/或“警告”处置修饰符时以文本消息的形式提供附加信息。语法如下：
failure-field = "Failure" ":" *text
failure-field = "Failure" ":" *text
error-field = "Error" ":" *text
error-field = "Error" ":" *text
warning-field = "Warning" ":" *text
warning-field = "Warning" ":" *text
Additional MDN fields may be defined in the future by later revisions or extensions to this specification. Extension-field names beginning with "X-" will never be defined as standard fields; such names are reserved for experimental use. MDN field names NOT beginning with "X-" MUST be registered with the Internet Assigned Numbers Authority (IANA) and described in a standards-track RFC or an experimental RFC approved by the IESG. (See Section 10 for a registration form.)
将来，本规范的后续修订或扩展可能会定义其他MDN字段。以“X-”开头的扩展字段名称永远不会定义为标准字段；这些名称保留供实验使用。不以“X-”开头的MDN字段名称必须在互联网分配号码管理局（IANA）注册，并在IESG批准的标准跟踪RFC或实验RFC中进行描述。（登记表见第10节。）
MDN Extension-fields may be defined for the following reasons:
定义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信息）。
If an application developer does not wish to register the meanings of such extension fields, "X-" fields may be used for this purpose. To avoid name collisions, the name of the application implementation should follow the "X-", (e.g., "X-Foomail-Log-ID" or "X-Foomail-EDI-info").
如果应用程序开发人员不希望注册此类扩展字段的含义，则可使用“X-”字段。为了避免名称冲突，应用程序实现的名称应该跟在“X-”后面（例如，“X-Foomail-Log-ID”或“X-Foomail-EDI-info”）。
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 MTA (original recipient information passed along)
--MUA将邮件传递给MTA（传递原始收件人信息）
-- MTA sends message to next MTA
--MTA将消息发送到下一个MTA
-- Final MTA receives message
--最终MTA收到消息
-- Final MTA delivers message to MUA (possibly generating a DSN)
--最终MTA向MUA发送消息（可能生成DSN）
-- MUA performs automatic processing and generates corresponding MDNs ("dispatched", "processed", "deleted", "denied", or "failed" disposition type with "automatic-action" and "MDN-sent-automatically" disposition modes)
--MUA执行自动处理并生成相应的MDN（“已调度”、“已处理”、“已删除”、“拒绝”或“失败”处置类型，具有“自动操作”和“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 and, with user's permission, sends an appropriate MDN ("displayed", "dispatched", "processed", "deleted", "denied", or "failed" disposition type, with "manual-action" and "MDN-sent-manually" or "MDN-sent-automatically" disposition mode).
--MUA执行请求的操作，并在用户许可的情况下发送适当的MDN（“显示”、“已发送”、“已处理”、“已删除”、“已拒绝”或“失败”处置类型，以及“手动操作”和“手动发送MDN”或“自动发送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] permits such information to be carried in the envelope if it is available. The Original-Recipient header 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]中定义的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 [RFC-DSN-SMTP], section 6.2.7.3), each of the recipients may issue an MDN.
每个发件人指定的收件人地址可能导致多个MDN。如果为转发给“别名”（如[RFC-DSN-SMTP]第6.2.7.3节所定义）的多个收件人的收件人请求MDN，则每个收件人都可以发出MDN。
Successful distribution of a message to a mailing list exploder 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.
将邮件成功分发到邮件列表分解器应视为邮件的最终处置。邮件列表分解器可能会发出一个MDN，其处置类型为“已处理”，处置模式为“自动操作”和“自动发送MDN”，表明邮件已转发到列表。在这种情况下，对MDN的请求不会传播到列表的成员。
Alternatively, the mailing list exploder MAY 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 MAY also direct MDNs to itself, correlate them, and produce a report to the original sender of the message.
或者，邮件列表分解器可能不会发出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 may be 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,
(a) 指示的消息处置未实际发生时的伪造处置通知，
(b) Unsolicited MDNs
(b) 未经请求的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). In this situation, it is acceptable for the MUA to issue "denied" MDNs or to silently ignore requests for MDNs.
安全的另一个方面是隐私。在某些情况下，邮件收件人可能不希望知道发送给他的邮件的处理情况，或者担心发送MDN可能会泄露其他敏感信息（例如，当邮件被读取时）。在这种情况下，MUA可以发出“被拒绝”的MDN，或者静默地忽略MDN请求。
If the Disposition-Notification-To header 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 could reveal confidential information about host names and/or network topology inside a firewall.
multipart/报告第3部分中返回的原始消息的标题可能会泄露有关防火墙内主机名和/或网络拓扑的机密信息。
An unencrypted MDN could reveal confidential information about an encrypted message, especially if all or part of the original message is returned in part 3 of the multipart/report. Encrypted MDNs are not defined in this specification.
未加密的MDN可能会泄露有关加密消息的机密信息，特别是在多部分/报告的第3部分中返回了原始消息的全部或部分时。本规范中未定义加密的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 field containing the envelope from address along with a source route. The source route is ignored in the comparison so the addresses will always match. But if the source route is honored when the notification is sent, it could direct the message to some other destination. This risk can be minimized by not sending MDN's automatically.
在某些情况下，可以访问消息流的人可以使用MDN请求机制来监视目标的邮件阅读习惯。如果已知目标生成MDN报告，则他们可以将处置通知添加到包含信封发件人地址以及源路由的字段中。源路由在比较中被忽略，因此地址将始终匹配。但是，如果在发送通知时遵守源路由，则它可以将消息定向到其他目的地。这种风险可以通过不自动发送MDN来最小化。
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 2634 [SEC-SERVICES].
RFC 2634[SEC-SERVICES]中提供了一种可能的解决方案。
The MDN request mechanism introduces an additional way of mailbombing 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. Such an attack could overrun the capacity of the targeted mailbox and deny service.
MDN请求机制引入了另一种邮件轰炸邮箱的方式。MDN请求通知提供MDN应发送到的地址。攻击代理可能会使用错误的“处置通知收件人：”地址向不知情的第三方收件人发送一组潜在的大量消息。自动或简单地处理此类请求将导致大量MDN通知发送到攻击目标。此类攻击可能会超出目标邮箱的容量并拒绝服务。
For that reason, MDN's SHOULD NOT be sent automatically where the "disposition-notification-to:" address is different from the envelope MAIL FROM address. See section 2.1 for further discussion.
因此，如果“处置通知收件人：”地址与信封邮寄地址不同，则不应自动发送MDN。进一步讨论见第2.1节。
NOTE: The following lexical tokens are defined in [RFC-MSGFMT]: atom, CRLF, mailbox, msg-id, text. The definitions of attribute and value are as in the definition of the Content-Type header in [RFC-MIME-BODY].
注意：以下词汇标记在[RFC-MSGFMT]中定义：atom、CRLF、mailbox、msg id、text。属性和值的定义与[RFC-MIME-BODY]中内容类型头的定义相同。
Message headers:
消息头：
mdn-request-header = "Disposition-Notification-To" ":" mailbox *("," mailbox)
mdn request header=“处置通知到”“：”邮箱*（“，”邮箱）
Disposition-Notification-Options = "Disposition-Notification-Options" ":" disposition-notification-parameters
处置通知选项=“处置通知选项”：“处置通知参数”
disposition-notification-parameters = parameter *(";" parameter)
处置通知参数=参数*（“；”参数）
parameter = attribute "=" importance "," value *("," value)
parameter = attribute "=" importance "," value *("," value)
importance = "required" / "optional"
importance = "required" / "optional"
original-recipient-header = "Original-Recipient" ":" address-type ";" generic-address
原始收件人标题=“原始收件人”“：“地址类型”；“通用地址”
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
*( failure-field CRLF )
*( error-field CRLF )
*( warning-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
*( failure-field CRLF )
*( error-field CRLF )
*( warning-field CRLF )
*( extension-field CRLF )
address-type = atom
address-type = atom
mta-name-type = atom
mta-name-type = atom
reporting-ua-field = "Reporting-UA" ":" ua-name [ ";" ua-product ]
reporting-ua-field = "Reporting-UA" ":" ua-name [ ";" ua-product ]
ua-name = *text
ua-name = *text
ua-product = *text
ua-product = *text
mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name
mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name
mta-name = *text
mta-name = *text
original-recipient-field = "Original-Recipient" ":" address-type ";" generic-address
原始收件人字段=“原始收件人”“：“地址类型”；“一般地址”
generic-address = *text
generic-address = *text
final-recipient-field = "Final-Recipient" ":" address-type ";" generic-address
最终收件人字段=“最终收件人”“：“地址类型”；“一般地址”
disposition-field = "Disposition" ":" disposition-mode ";" disposition-type [ "/" disposition-modifier *( "," disposition-modifier ) ]
处置字段=“处置”“：“处置模式”；“处置类型[“/”处置修饰符*（“，”处置修饰符）]
disposition-mode = action-mode "/" sending-mode
处置模式=行动模式“/”发送模式
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"
处置类型=“已显示”/“已删除”
disposition-modifier = "error" / disposition-modifier-extension
处置修饰符=“错误”/“处置修饰符扩展”
disposition-modifier-extension = atom
disposition-modifier-extension = atom
original-message-id-field = "Original-Message-ID" ":" msg-id
原始邮件id字段=“原始邮件id”“：”消息id
failure-field = "Failure" ":" *text
failure-field = "Failure" ":" *text
error-field = "Error" ":" *text
error-field = "Error" ":" *text
warning-field = "Warning" ":" *text
warning-field = "Warning" ":" *text
extension-field = extension-field-name ":" *text
extension-field = extension-field-name ":" *text
extension-field-name = atom
extension-field-name = atom
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 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).
邮件网关可以发出MDN，以通过Internet邮件传递“外来”处置通知的内容。当存在从外部通知元素到MDN字段的适当映射时，可以在这些MDN字段中传输信息。可以在扩展MDN字段中定义附加信息（例如通过Internet传输外部通知可能需要的信息）。（此类字段应给出标识外文邮件协议的名称，例如，对于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, 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:
通过使用单独的处置通知请求头，该规范提供了比大多数（如果不是全部的话）其他电子邮件系统更丰富的功能。在大多数其他电子邮件系统中，通知收件人与“发件人”地址中指示的邮件发件人相同。当网关进入此类系统时，有两种有趣的情况：
1) If the address in the disposition-notification-to header 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 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
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"
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--
This document specifies three types of parameters that must be registered with the Internet Assigned Numbers Authority (IANA).
本文件规定了三种类型的参数，必须向互联网分配号码管理局（IANA）注册。
The forms below are for use when registering a new parameter name for the Disposition-Notification-Options header, 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, 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>.
A registration for a Disposition-Notification-Options header parameter name MUST include the following information:
处置通知选项标题参数名称的注册必须包括以下信息：
(a) The proposed parameter name.
(a) 建议的参数名称。
(b) The syntax for parameter values, specified using BNF, ABNF, regular expressions, or other non-ambiguous language.
(b) 参数值的语法，使用BNF、ABNF、正则表达式或其他非歧义语言指定。
(c) If 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.
(c) 如果参数值不完全由US-ASCII指令表中的图形字符组成，则说明如何在处置通知选项标题中将其编码为图形US-ASCII字符。
(d) A reference to a standards track RFC or experimental RFC approved by the IESG that describes the semantics of the parameter values.
(d) 对IESG批准的标准跟踪RFC或实验RFC的引用，描述参数值的语义。
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 standards track RFC or experimental RFC approved by the IESG that describes the semantics of the disposition modifier.
(b) 对IESG批准的标准跟踪RFC或实验RFC的引用，描述处置修饰符的语义。
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.
(c) 如果扩展字段值不完全由US-ASCII指令表中的图形字符组成，则说明如何在处置通知选项标题中将其编码为图形US-ASCII字符。
(d) A reference to a standards track RFC or experimental RFC approved by the IESG that describes the semantics of the extension field.
(d) 对IESG批准的标准跟踪RFC或实验RFC的引用，描述扩展字段的语义。
This document is an updated version of the original document written by Roger Fajman. His contributions to the definition of Message Disposition Notifications are greatly appreciated.
本文件是Roger Fajman编写的原始文件的更新版本。他对消息处置通知的定义所作的贡献受到极大的赞赏。
RFC 2298 was based on the Delivery Status Notifications document [RFC-DSN-FORMAT] by Keith Moore and Greg Vaudreuil. Contributions were made by members of the IETF Receipt Working Group, including Harald Alvestrand, Ian Bell, Urs Eppenberger, Claus Andri Faerber, Ned Freed, Jim Galvin, Carl Hage, Mike Lake, Keith Moore, Paul Overell, Pete Resnick, and Chuck Shih.
RFC 2298基于Keith Moore和Greg Vaudreuil的交付状态通知文档[RFC-DSN-FORMAT]。IETF收据工作组的成员做出了贡献，包括哈拉尔·阿尔维斯特朗、伊恩·贝尔、乌斯·艾彭伯格、克劳斯·安德里·费尔伯、内德·弗里德、吉姆·加尔文、卡尔·哈格、迈克·莱克、基思·摩尔、保罗·奥威尔、皮特·雷斯尼克和查克·施。
[RFC-SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC-SMTP]Klensin，J.，Ed.，“简单邮件传输协议”，RFC 28212001年4月。
[RFC-MSGFMT] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[RFC-MSGFMT]Resnick，P.，Ed.“互联网信息格式”，RFC 2822，2001年4月。
[RFC-MIME-BODY] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC-MIME-BODY]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC-MIME-MEDIA] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC-MIME-MEDIA]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[RFC-MIME-HEADER] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC-MIME-HEADER]Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
[RFC-REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.
[RFC-REPORT]Vaudreuil，G.“邮件系统管理消息报告的多部分/报告内容类型”，RFC 3462，2003年1月。
[RFC-DSN-SMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications", RFC 3461, January 2003.
[RFC-DSN-SMTP]Moore，K.，“用于传递状态通知的简单邮件传输协议（SMTP）服务扩展”，RFC 3461，2003年1月。
[RFC-DSN-FORMAT] Moore, K., and G. Vaudreuil, "An Extensible Format for Delivery Status Notifications (DSNs)", RFC 3464, January 2003.
[RFC-DSN-FORMAT]Moore，K.和G.Vaudreuil，“交付状态通知（DSN）的可扩展格式”，RFC 3464，2003年1月。
[RFC-KEYWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[SEC-SERVICES] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[SEC-SERVICES]Hoffman，P.，Ed.“S/MIME的增强安全服务”，RFC 2634，1999年6月。
Appendix A - Changes from RFC 2298
附录A-RFC 2298的变更
The document has new editors.
该文件有新的编辑器。
The dispositions "denied", and "failed" were removed from the document reflecting the lack of implementation or usage at this time.
从文件中删除了“拒绝”和“失败”的处置，反映出此时缺乏实施或使用。
The disposition modifiers "warning", "superseded", "expired", "mailbox-terminated" have not seen actual implementation. They have been deleted from this document. The extension modifier, as of yet unused, has been retained for future extension.
处置修饰符“警告”、“已取代”、“已过期”、“邮箱已终止”尚未实际实现。它们已从此文档中删除。到目前为止，尚未使用的扩展修改器已保留以供将来扩展。
General editorial cleanups include spelling, grammar, and consistency in usage of terms.
一般的编辑清理包括拼写、语法和术语使用的一致性。
The document has modified BNF for disposition notification options to eliminate the need for dummy values where not otherwise needed.
该文档修改了处置通知选项的BNF，以消除不需要虚拟值的情况。
Authors' Addresses
作者地址
Tony Hansen AT&T Laboratories Middletown, NJ 07748 USA Voice: +1-732-420-8934 EMail: tony+rfc3798@maillennium.att.com
Tony Hansen AT&T Laboratories Middletown，NJ 07748美国语音：+1-732-420-8934电子邮件：Tony+rfc3798@maillennium.att.com
Gregory M. Vaudreuil Lucent Technologies 7291 Williamson Rd Dallas, TX 75214 USA Voice: +1 214 823 9325 EMail: GregV@ieee.org
Gregory M.Vaudreuil-Lucent Technologies德克萨斯州达拉斯威廉森路7291号75214美国语音：+1 214 823 9325电子邮件：GregV@ieee.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。