Network Working Group R. Fajman
Request for Comments: 2298 National Institutes of Health
Category: Standards Track March 1998
Network Working Group R. Fajman
Request for Comments: 2298 National Institutes of Health
Category: Standards Track March 1998
An Extensible Message Format for Message Disposition Notifications
用于消息处置通知的可扩展消息格式
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 (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
This memo defines a MIME content-type that may be used by a mail user agent (UA) or electronic mail gateway to report the disposition of a message after it has been sucessfully 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 the privacy concerns that have often been expressed when such functions have been discussed in the past.
此备忘录定义了一种MIME内容类型，邮件用户代理（UA）或电子邮件网关可使用该类型在邮件成功传递给收件人后报告邮件的处理情况。此内容类型旨在可由机器处理。还定义了其他消息头，以允许消息的发送者请求消息处置通知（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 ............................................ 2
2. Requesting Message Disposition Notifications ............ 3
3. Format of a Message Disposition Notification ............ 7
4. Timeline of events ...................................... 17
5. Conformance and Usage Requirements ...................... 18
6. Security Considerations ................................. 19
7. Collected Grammar ....................................... 20
8. Guidelines for Gatewaying MDNs .......................... 22
9. Example ................................................. 24
10. IANA Registration Forms ................................. 25
11. Acknowledgments ......................................... 26
12. References .............................................. 26
13. Author's Address ........................................ 27
14. Copyright ............................................... 28
1. Introduction ............................................ 2
2. Requesting Message Disposition Notifications ............ 3
3. Format of a Message Disposition Notification ............ 7
4. Timeline of events ...................................... 17
5. Conformance and Usage Requirements ...................... 18
6. Security Considerations ................................. 19
7. Collected Grammar ....................................... 20
8. Guidelines for Gatewaying MDNs .......................... 22
9. Example ................................................. 24
10. IANA Registration Forms ................................. 25
11. Acknowledgments ......................................... 26
12. References .............................................. 26
13. Author's Address ........................................ 27
14. Copyright ............................................... 28
This memo defines a MIME content-type [5] 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 1892 [7].
此备忘录为消息处置通知（MDN）定义了MIME内容类型[5]。MDN可用于将成功传递后可能出现的几种情况中的任何一种情况通知邮件的发件人，例如显示邮件内容、打印邮件、删除（不显示）邮件或收件人拒绝提供MDN。本文定义的“消息/处置通知”内容类型旨在在RFC 1892[7]中定义的“多部分/报告”内容类型的框架内使用。
This memo defines the format of the notifications and the RFC 822 headers used to request them.
此备忘录定义了通知的格式以及用于请求通知的RFC 822标题。
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 2119.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。
The MDNs defined in this memo are expected to serve several purposes:
本备忘录中定义的MDN预计可用于多种用途：
(a) Inform human beings of the disposition of messages after succcessful delivery, in a manner which 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, as well as being 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 is 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 accomodate future requirements.
(d) 规范必须是可扩展的，以适应未来的需求。
Message disposition notifications are requested by including a Disposition-Notification-To header in the message. Further information to be used by the recipient's UA in generating the MDN may be provided by including Original-Recipient and/or Disposition-Notification-Options headers in the message.
通过在消息中包含对标头的处置通知来请求消息处置通知。可通过在消息中包括原始接收者和/或处置通知选项报头来提供接收者的UA在生成MDN中使用的进一步信息。
A request that the receiving user agent issue message disposition notifications is made by placing a Disposition-Notification-To header into the message. The syntax of the header, using the ABNF of RFC 822 [2], is
接收用户代理发出消息处置通知的请求是通过将处置通知放置到消息头中发出的。使用RFC 822[2]的ABNF的头的语法是
mdn-request-header = "Disposition-Notification-To" ":" 1#mailbox
mdn-request-header = "Disposition-Notification-To" ":" 1#mailbox
The mailbox token is as specified in RFC 822 [2].
邮箱令牌在RFC 822[2]中指定。
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。
At most one MDN may be issued on behalf of each particular recipient by their user agent. 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 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 never to 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 822 [2]). 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 822[2]）。在这种情况下，如果可能，应获得用户的确认。如果无法获得同意（例如，因为用户当时不在线），则不应发送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 possibilities for mail loops and use of MDNs 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 822 [2]. This will permit automatic correlation of MDNs with original messages by user agents.
如RFC 822[2]中所述，包含对消息头的处置通知的消息还应包含消息ID消息头。这将允许用户代理自动将MDN与原始消息关联起来。
If it is desired to request message disposition notifications for some recipients and not others, two copies of the message should be sent, one with an 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 UA 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, using the ABNF of RFC 822 [2], is
本规范的未来扩展可能需要向接收方的UA提供信息，以便对MDN的生成方式和内容进行额外控制。处置通知选项标头为此类信息提供了一种可扩展的机制。使用RFC 822[2]的ABNF，此标头的语法为
Disposition-Notification-Options = "Disposition-Notification-Options" ":" disposition-notification-parameters
处置通知选项=“处置通知选项”：“处置通知参数”
disposition-notification-parameters = parameter *(";" parameter)
disposition-notification-parameters = parameter *(";" parameter)
parameter = attribute "=" importance "," 1#value
parameter = attribute "=" importance "," 1#value
importance = "required" / "optional"
importance = "required" / "optional"
The definitions of attribute and value are as in the definition of the Content-Type header in RFC 2045 [4].
属性和值的定义与RFC 2045[4]中内容类型标题的定义相同。
An importance of "required" indicates that interpretation of the parameter is necessary for proper generation of an MDN in response to this request. If a UA 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 a UA that does not understand the meaning of this parameter MAY generate an MDN in response anyway, ignoring the value of the parameter.
“required”的重要性表示，为了响应此请求，正确生成MDN，必须对参数进行解释。如果UA不理解该参数的含义，则其不得生成具有除响应请求“失败”以外的任何处置类型的MDN。“可选”的重要性表示不理解此参数含义的UA可能会生成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 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-”开头的参数属性名称永远不会定义为标准名称；这些名称保留供实验使用。不以“X-”开头的MDN参数名称必须在互联网分配号码管理局（IANA）注册，并在IESG批准的标准跟踪RFC或实验RFC中描述。注册表格见第10节。
If a required parameter is not understood or contains some sort of error, the receiving UA 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 a 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.
如果所需参数未被理解或包含某种错误，接收UA应发出处置类型为“失败”的MDN（见第3.2.6节），并包括进一步描述问题的故障字段（见第3.2.7节）。当在disposition Notification Options标头的参数中检测到其他类型的错误时，也可能会生成处置类型为“failed”和“Failure”字段的MDN。
However, an MDN with a disposition type of "failed" MUST NOT be generated if the user has indicated a preferance 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 1891 [8]. If this 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, using the ABNF of RFC 822 [2], is as follows
由于邮件在传输过程中可能会重写电子邮件地址，因此传递MTA提供原始收件人地址非常有用。按照RFC 1891[8]中的定义，传送MTA可能能够从SMTP RCPT to命令的ORCPT参数获取此信息。如果此信息可用，则传递MTA应在邮件开头插入原始收件人标头（以及返回路径标头）。传递MTA可以删除邮件中出现的任何其他原始收件人标题。使用RFC 822[2]的ABNF，该头的语法如下
original-recipient-header = "Original-Recipient" ":" address-type ";" generic-address
原始收件人标题=“原始收件人”“：“地址类型”；“通用地址”
The address-type and generic-address token are as 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 2046 [5]) requires further definition.
使用MIME邮件/部分内容类型（RFC 2046[5]）的头处置通知、处置通知选项和原始收件人需要进一步定义。
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 2046 [5]). These headers SHOULD NOT be used in the headers of any of the fragments themselves.
当一条消息被分割成两个或多个消息/部分片段时，上述段落中提到的三个标题应放在“内部”或“封闭”消息中（使用RFC 2046[5]的术语）。这些头不应该在任何片段本身的头中使用。
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 to be generated for the fragment. If these headers occur in the headers of the "inner" or "enclosed" message (using the terms of RFC 2046 [5]), they pertain to an MDN to be generated for the reassembled message. Section 5.2.2.1 of RFC 2046 [5]) 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 occurances of the three headers defined here in the headers of the initial enclosing message must not be copied to the reassembled message.
当重新组装多个消息/部分片段时，以下内容适用。如果这些头与消息/部分片段消息的其他头一起出现，则它们属于要为片段生成的MDN。如果这些头出现在“内部”或“封闭”消息的头中（使用RFC 2046[5]的术语），则它们属于为重新组装的消息生成的MDN。RFC 2046[5]第5.2.2.1节进行了修订，规定除此处规定的标题外，本规范中描述的三个标题应依次附加到重新组装的消息标题中。在初始封装消息的消息头中定义的三个消息头出现的任何情况都不得复制到重新组装的消息中。
A message disposition notification is a MIME message with a top-level content-type of multipart/report (defined in RFC 1892 [7]). When a multipart/report content is used to transmit an MDN:
消息处置通知是一个MIME消息，其顶级内容类型为multipart/report（在RFC 1892[7]中定义）。使用多部分/报告内容传输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 1892 [7].
(b) 如RFC 1892[7]中所述，多部分/报告的第一个组件包含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 UA generating the 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.
(d) 如果要将原始邮件或邮件的一部分返回给发件人，则它将显示为多部分/报告的第三个组件。是否返回消息或部分消息的决定取决于生成MDN的UA。但是，对于请求MDN的加密邮件，必须返回加密的邮件文本（如果返回了），并且只能以原始加密形式返回。
NOTE: For message dispostion 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 822 headers which contain equivalent information. In particular, it is very desirable to preserve the subject and date fields from the original message.
注意：对于从外部系统网关发送的消息处理通知，原始消息的标题可能不可用。在这种情况下，可以省略MDN的第三个组件，或者它可以包含包含等效信息的“模拟”rfc822报头。特别是，非常希望保留原始消息中的主题和日期字段。
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 Optional parameters: none Encoding considerations: "7bit" encoding is sufficient and MUST be used to maintain readability when viewed by non-MIME mail readers. Security considerations: discussed in section 6 of this memo.
MIME子类型名称：处置通知可选参数：无编码注意事项：“7bit”编码已足够，必须用于在非MIME邮件阅读器查看时保持可读性。安全注意事项：在本备忘录第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 822 header "fields" (see [2]). Using the ABNF of RFC 822, the syntax of the message/disposition-notification content is as follows:
消息/处置通知的正文由一个或多个“字段”组成，这些“字段”根据RFC 822标题“字段”的ABNF进行格式化（参见[2]）。使用RFC 822的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 822 [2], 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 which 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 2047 [6].
由于这些字段是根据RFC 822[2]的规则定义的，因此连续行和注释的约定相同。通过在每一行的开头加上空格或HTAB，通知字段可以延续到多行。出现在括号中的文本被视为注释，而不是通知字段内容的一部分。字段名不区分大小写，因此通知字段的名称可以用大写和小写字母的任意组合拼写。通知字段中的注释可以使用RFC 2047[6]中定义的“编码字”结构。
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) will maintain a registry of address-type and mta-name-type values, along with descriptions of the meanings of each, or a reference to a one or more specifications that provide such descriptions. (The "rfc822" address-type is defined in RFC 1891 [8].) Registration forms for address-type and mta-name-type appear in RFC 1894 [9].
互联网分配号码管理局（IANA）将维护地址类型和mta名称类型值的注册表，以及每个值的含义说明，或对提供此类说明的一个或多个规范的引用。（RFC 1891[8]中定义了“rfc822”地址类型）。RFC 1894[9]中显示了地址类型和mta名称类型的注册表格。
IANA will not accept registrations for any address-type name that begins with "X-". These type names are reserved for experimental use.
IANA不接受以“X-”开头的任何地址类型名称的注册。这些类型名称保留供实验使用。
The following lexical tokens, defined in RFC 822 [2], are used in the ABNF grammar for MDNs: atom, CRLF, mailbox, msg-id, text.
RFC 822[2]中定义的以下词汇标记用于MDN的ABNF语法：atom、CRLF、mailbox、msg id、text。
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字段定义如下：
A MDN describes the disposition of a message after it has been delivered to a recipient. In all cases, the Reporting-UA is the UA that performed the disposition described in the MDN. This field is
MDN描述邮件交付给收件人后的处置。在所有情况下，报告UA都是执行MDN中所述处置的UA。这个领域是
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 UA that generated the MDN and the name of the product. For example,
可选，但推荐。对于Internet邮件用户代理，建议此字段同时包含生成MDN的UA特定实例的DNS名称和产品名称。例如
Reporting-UA: rogers-mac.dcrt.nih.gov; Foomail 97.1
报告UA:rogers-mac.dcrt.nih.gov；Foomail97.1
If the reporting UA 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.
如果报告UA包含多个组件（例如，基本程序和插件），可通过包括产品名称列表来表示。
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 which 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
“原始收件人”字段表示为其发出MDN的邮件的发件人指定的原始收件人地址。对于Internet邮件消息
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 UA may choose the one to use or act as if no Original-Recipient header is present.
原始收件人字段从生成MDN的邮件的原始收件人标头中获取。如果消息中没有原始收件人标头，则必须省略原始收件人字段，除非通过其他方式可靠地获得相同的信息。如果原始邮件中有原始收件人标头（或原始收件人信息以其他方式可靠可用），则必须提供原始收件人字段。如果消息中有多个原始收件人报头，UA可以选择使用该报头，或者在没有原始收件人报头的情况下使用该报头。
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 field will normally be "rfc822", and the address will be according to the syntax specified in RFC 822 [2]. The value "unknown" should be used if the Reporting UA 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 822[2]中指定的语法。如果报告UA无法从邮件信封中确定原始收件人地址的类型，则应使用“未知”值。此地址与发件人提供的地址相同，可用于根据每个收件人自动将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 UA.
最终收件人字段的通用地址子字段必须包含收件人的邮箱地址（来自MDN的from头），就像UA生成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 an 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
原始邮件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 822 [2].
msg id标记如RFC 822[2]中所规定。
The Disposition field indicates the action performed by the Reporting-UA on behalf of the user. This field MUST be present.
处置字段表示报告UA代表用户执行的操作。此字段必须存在。
The syntax for the Disposition field is:
处置字段的语法为：
disposition-field = "Disposition" ":" disposition-mode ";" disposition-type [ '/' disposition-modifier *( "," dispostion-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"
/ "dispatched"
/ "processed"
/ "deleted"
/ "denied"
/ "failed"
disposition-type = "displayed"
/ "dispatched"
/ "processed"
/ "deleted"
/ "denied"
/ "failed"
disposition-modifier = ( "error" / "warning" )
/ ( "superseded" / "expired" /
"mailbox-terminated" )
/ disposition-modifier-extension
disposition-modifier = ( "error" / "warning" )
/ ( "superseded" / "expired" /
"mailbox-terminated" )
/ 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 explicity gave permission for this particular MDN to be sent.
“手动发送MDN”用户明确授予发送此特定MDN的权限。
"MDN-sent-automatically" The MDN was sent because the UA had previously been configured to do so automatically.
“自动发送MDN”之所以发送MDN，是因为UA之前已配置为自动发送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 UA to someone reading the recipient's mailbox. There is no guarantee that the content has been read or understood.
“已显示”UA已向正在阅读收件人邮箱的人显示消息。不能保证内容已被阅读或理解。
"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.
“已删除”消息已被删除。收件人可能看到或可能没有看到该邮件。收件人可能会在以后“取消删除”邮件并阅读邮件。
"denied" The recipient does not wish the sender to be informed of the message's disposition. A UA may also siliently ignore message disposition requests in this situation.
“拒绝”收件人不希望将邮件的处置情况通知发件人。在这种情况下，UA也可能愚蠢地忽略消息处理请求。
"failed" A failure occurred that prevented the proper generation of an MDN. More information about the cause of the failure may be contained in a Failure field. The "failed" disposition type is not to be used for the situation in which there is is some problem in processing the message other than interpreting the request for an MDN. The "processed" or other disposition type with appropriate disposition modifiers is to be used in such situations.
“失败”发生的故障阻止正确生成MDN。故障字段中可能包含有关故障原因的更多信息。“failed”处置类型不适用于除解释MDN请求外处理消息时出现问题的情况。在这种情况下，应使用带有适当处置修饰符的“已处理”或其他处置类型。
The following disposition modifiers are defined:
定义了以下处置修饰符：
"error" An error of some sort occurred that prevented successful processing of the message. Further information is contained in an Error field.
“错误”发生了某种类型的错误，阻止了消息的成功处理。更多信息包含在错误字段中。
"warning" The message was successfully processed but some sort of exceptional condition occurred. Further information is contained in a Warning field.
“警告”消息已成功处理，但出现某种异常情况。更多信息包含在警告字段中。
"superseded" The message has been automatically rendered obsolete by another message received. The recipient may still access and read the message later.
“已取代”收到的另一封邮件已自动使邮件过时。收件人以后仍可以访问和阅读邮件。
"expired" The message has reached its expiration date and has been automatically removed from the recipient's mailbox.
“过期”邮件已达到其过期日期，并已自动从收件人邮箱中删除。
"mailbox-terminated" The recipient's mailbox has been terminated and all message in it automatically removed.
“邮箱已终止”收件人的邮箱已终止，其中的所有邮件将自动删除。
"Obsoleted", "expired", and "terminated" are to be used with the "deleted" disposition type and the "autoaction" and "autosent" disposition modifiers.
“过时”、“过期”和“终止”将与“已删除”处置类型以及“自动操作”和“自动发送”处置修饰符一起使用。
disposition-modifier-extension Additional 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 UA MAY be silently ignored or placed in the user's mailbox without special inter- pretation. They MUST not cause any error message to be sent to the sender of the MDN.
处置修改器扩展将来可通过本规范的后续修订或扩展来定义其他处置修改器。以“X-”开头的处置值名称永远不会定义为标准值；这些名称保留供实验使用。不以“X-”开头的MDN处置值名称必须在互联网分配号码管理局（IANA）注册，并在IESG批准的标准跟踪RFC或实验RFC中进行说明。注册表格见第10节。接收UA无法理解具有处置修饰符名称的MDN可能会被默默忽略或放置在用户邮箱中，无需特殊解释。它们不得导致向MDN的发件人发送任何错误消息。
If an UA 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 UA implementation should follow the "X-", (e.g. "X-Foomail-fratzed").
如果UA开发者不希望注册此类处置修饰符扩展的含义，则可为此目的使用“X-”修饰符。为了避免名称冲突，UA实现的名称应该跟在“X-”后面（例如“X-Foomail-frazed”）。
It is not required that a UA be able to generate all of the possible values of the Disposition field.
UA不需要能够生成处置字段的所有可能值。
One and only one MDN may be issued on behalf of each particular recipient by their user agent. 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
每个特定接收人的用户代理可以代表每个特定接收人发布一个且仅一个MDN。也就是说，一旦代表收件人发出MDN，就不能代表该收件人再发出MDN，即使对消息执行了另一个处置。但是，如果转发消息，“已调度”MDN可能会
been issued for the recipient doing the forwarding and the recipient of the forwarded message may also cause an MDN to be generated.
已为进行转发的收件人发出，转发邮件的收件人也可能导致生成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 modifer appear. The syntax is
当出现“故障”处置类型、“错误”处置修改器和/或“警告”处置修改器时，故障、错误和警告字段用于以文本消息的形式提供附加信息。语法是
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节。
Extension MDN 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 which is specific to a particular user agent (UA). The names of such MDN fields should begin with an indication of the UA implementation which produced the MDN. (e.g. Foomail-information).
(b) 允许传输特定于特定用户代理（UA）的诊断信息。此类MDN字段的名称应以生成MDN的UA实现的指示开头。（例如，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-EDI-info").
如果应用程序开发人员不希望注册此类扩展字段的含义，则可使用“X-”字段。为了避免名称冲突，应用程序实现的名称应该跟在“X-”后面（例如，“X-Foomail-Log-ID”或“X-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 UA to send message
--用户告诉UA发送消息
-- UA passes message to MTA (original recipient information passed along)
--UA将邮件传递给MTA（传递原始收件人信息）
-- MTA sends message to next MTA
--MTA将消息发送到下一个MTA
-- Final MTA receives message
--最终MTA收到消息
-- Final MTA delivers message to UA (possibily generating DSN)
--最终MTA向UA发送消息（可能生成DSN）
-- UA performs automatic processing and generates corresponding MDNs ("dispatched", "processed", "deleted", "denied" or "failed" disposition type with "automatic-action" and "MDN-sent-automatically" disposition modes)
--UA执行自动处理并生成相应的MDN（“已调度”、“已处理”、“已删除”、“拒绝”或“失败”处置类型，具有“自动操作”和“MDN已自动发送”处置模式）
-- UA displays list of messages to user
--UA向用户显示消息列表
-- User selects a message and requests that some action be performed on it.
--用户选择一条消息并请求对其执行某些操作。
-- UA performs requested action and, with user's permission, sends appropriate MDN ("displayed", "dispatched", "processed", "deleted", "denied" or "failed" disposition type with "manual-action" and "MDN-sent-manually" or "MDN-sent-automatically" disposition mode).
--UA执行请求的操作，并在用户许可的情况下发送相应的MDN（“显示”、“已发送”、“已处理”、“已删除”、“拒绝”或“失败”处置类型，以及“手动操作”、“手动发送MDN”或“自动发送MDN”处置模式）。
-- User possibly performs other actions on message, but no further MDNs are generated.
--用户可能对消息执行其他操作，但不会生成更多的MDN。
A UA 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.
如果UA或网关根据本备忘录中定义的协议生成MDN，则其符合本规范。不必生成Disposition字段的所有可能值。
UAs 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 1891 [8] 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 UA.
UAs和网关不得生成MDN的原始收件人字段，除非邮件协议提供发件人在提交时最初指定的地址。普通SMTP不保证这一点，但RFC 1891[8]中定义的SMTP扩展允许在信封中携带此类信息（如果可用）。本文档中定义的原始收件人标头为MTA将原始收件人地址传递给UA提供了一种方法。
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 1891 [8], section 6.2.7.3), each of the recipients may issue an MDN.
每个发件人指定的收件人地址可能导致多个MDN。如果为转发给“别名”的多个收件人（如RFC 1891[8]第6.2.7.3节所定义）的收件人请求MDN，则每个收件人都可以发出MDN。
Successful distribution of a message to a mailing list exploder SHOULD be considered 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 propogated to the members of the list.
将邮件成功分发到邮件列表分解器应视为邮件的最终处置。邮件列表分解器可能会发出一个MDN，其处置类型为“已处理”，处置模式为“自动操作”和“MDN-自动发送”，表明邮件已转发到列表。在这种情况下，MDN请求不会发送给列表的成员。
Alternaively, the mailing list exploder may issue no MDN and propogate 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. It is also permissible for the mailing list exploder to 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 ocurred,
(a) 当指示的消息处理未实际发生时，伪造的处理通知，
(b) Unsolicited MDNs
(b) 未经请求的MDN
Another dimension of security is confidentiality. 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 confidential information (e.g., when the message was read). In this situation, it is acceptable for the UA to issue "denied" MDNs or to silently ignore requests for MDNs.
发送给他的信息应为已知信息，或担心发送MDN可能会泄露其他机密信息（例如，在阅读信息时）。在这种情况下，UA发出“被拒绝”的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 UA 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.
通常，如果报告UA站点或用户确定包含任何可选MDN字段会对站点保密性造成太大的损害，则可以省略该字段。这种保密性的需要必须与MDN中省略信息的效用相平衡。
Within the framework of today's Internet Mail, the MDNs defined in this document provide valuable information to the mail user; however, MDNs can not be relied upon as a guarantee that a message was or was not not seen by the recipient. Even if MDNs are not actively forged, they may be lost in transit. The MDN issuing mechanism may be bypassed in some manner by the recipient.
在当今互联网邮件的框架内，本文档中定义的MDN为邮件用户提供了有价值的信息；但是，MDN不能保证收件人看到或没有看到邮件。即使MDN不是主动伪造的，也可能在运输过程中丢失。收件人可能以某种方式绕过MDN发布机制。
NOTE: The following lexical tokens are defined in RFC 822: atom, CRLF, mailbox, msg-id, text. The definitions of attribute and value are as in the definition of the Content-Type header in RFC 2045 [4].
注意：以下词汇标记在RFC 822中定义：atom、CRLF、mailbox、msg id、text。属性和值的定义与RFC 2045[4]中内容类型标题的定义相同。
Message headers:
消息头：
mdn-request-header = "Disposition-Notification-To" ":" 1#mailbox
mdn-request-header = "Disposition-Notification-To" ":" 1#mailbox
Disposition-Notification-Options = "Disposition-Notification-Options" ":" disposition-notification-parameters
处置通知选项=“处置通知选项”：“处置通知参数”
disposition-notification-parameters = parameter *(";" parameter)
disposition-notification-parameters = parameter *(";" parameter)
parameter = attribute "=" importance "," 1#value
parameter = attribute "=" importance "," 1#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 ]
报告ua字段=“报告ua”“：“ua名称[”；“ua产品]
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 *( "," dispostion-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"
/ "dispatched"
/ "processed"
/ "deleted"
/ "denied"
/ "failed"
disposition-type = "displayed"
/ "dispatched"
/ "processed"
/ "deleted"
/ "denied"
/ "failed"
disposition-modifier = ( "error" / "warning" )
/ ( "superseded" / "expired" /
"mailbox-terminated" )
/ disposition-modifier-extension
disposition-modifier = ( "error" / "warning" )
/ ( "superseded" / "expired" /
"mailbox-terminated" )
/ 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
邮件网关可以发出MDN，以通过Internet邮件传递“外来”处置通知的内容。当存在从外部通知元素到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字段中传输信息。可以在扩展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信息的方法。
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.
同样，本例中使用的*-型子字段名或扩展字段也不应解释为这些类型名或扩展字段的定义。
9.1 This is an MDN issued after a message has been displayed to the user of an Internet Mail user agent.
9.1 这是在向Internet邮件用户代理的用户显示消息后发出的MDN。
Date: Wed, 20 Sep 1995 00:19:00 (EDT) -0400
From: Joe Recipient <Joe_Recipient@mega.edu>
Message-Id: <199509200019.12345@mega.edu>
Subject: Disposition notification
To: Jane Sender <Jane_Sender@huge.com>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=disposition-notification;
boundary="RAA14128.773615765/mega.edu"
Date: Wed, 20 Sep 1995 00:19:00 (EDT) -0400
From: Joe Recipient <Joe_Recipient@mega.edu>
Message-Id: <199509200019.12345@mega.edu>
Subject: Disposition notification
To: Jane Sender <Jane_Sender@huge.com>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=disposition-notification;
boundary="RAA14128.773615765/mega.edu"
--RAA14128.773615765/mega.edu
--RAA14128.773615765/mega.edu
The message sent on 1995 Sep 19 at 13:30:00 (EDT) -0400 to Joe Recipient <Joe_Recipient@mega.edu> 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@mega.edu>主题为“报告初稿”的文件已显示。这并不能保证信息已被阅读或理解。
--RAA14128.773615765/mega.edu content-type: message/disposition-notification
--RAA14128.773615765/mega.edu内容类型：消息/处置通知
Reporting-UA: joes-pc.cs.mega.edu; Foomail 97.1
Original-Recipient: rfc822;Joe_Recipient@mega.edu
Final-Recipient: rfc822;Joe_Recipient@mega.edu
Original-Message-ID: <199509192301.23456@huge.com>
Disposition: manual-action/MDN-sent-manually; displayed
Reporting-UA: joes-pc.cs.mega.edu; Foomail 97.1
Original-Recipient: rfc822;Joe_Recipient@mega.edu
Final-Recipient: rfc822;Joe_Recipient@mega.edu
Original-Message-ID: <199509192301.23456@huge.com>
Disposition: manual-action/MDN-sent-manually; displayed
--RAA14128.773615765/mega.edu content-type: message/rfc822
--RAA14128.773615765/mega.edu内容类型：message/rfc822
[original message goes here]
[原文如下]
--RAA14128.773615765/mega.edu--
--RAA14128.773615765/mega.edu--
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, imprecise specifications, or inappropriate names.
以下表格用于注册处置通知选项标题的新参数名称、新处置修改器名称或新MDN扩展字段。注册表格所需的每一条信息都可以通过在表格上提供信息，或者通过引用包含必要信息的已发布、公开的规范来满足。IANA可能会因为登记表不完整、规格不准确或名称不当而拒绝登记。
To register, complete the applicable form below and send it via electronic mail to <IANA@IANA.ORG>.
要注册，请填写以下适用表格，并通过电子邮件发送至<IANA@IANA.ORG>.
10.1 IANA registration form for Disposition-Notification-Options header parameter names
10.1 处置通知选项标题参数名称的IANA注册表
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 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 based on the Delivery Status Notifications document, RFC 1894 [9], by Keith Moore and Greg Vaudreuil. Contributions were made by members of the IETF Receipt Working Group, including Harald Alverstrand, Ian Bell, Urs Eppenberger, Claus Andri Faerber, Ned Freed, Jim Galvin, Carl Hage, Mike Lake, Keith Moore, Paul Overell, Pete Resnick, Chuck Shih.
本文件基于Keith Moore和Greg Vaudreuil的交付状态通知文件RFC 1894[9]。IETF收据工作组的成员做出了贡献，包括Harald Alverstrand、Ian Bell、Urs Eppenberger、Claus Andri Faerber、Ned Freed、Jim Galvin、Carl Hage、Mike Lake、Keith Moore、Paul Overell、Pete Resnick、Chuck Shih。
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[1] Postel，J.，“简单邮件传输协议”，STD 10，RFC 821，1982年8月。
[2] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[2] Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[3] Braden, R. (ed.), "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[3] Braden R.（编辑），“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
[4] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[4] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[5] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[5] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[6] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header Extensions for Non-Ascii Text", RFC 2047, November 1996.
[6] Moore，K.，“多用途互联网邮件扩展（MIME）第三部分：非Ascii文本的消息头扩展”，RFC 2047，1996年11月。
[7] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 1892, January 1996.
[7] Vaudreuil，G.“邮件系统管理消息报告的多部分/报告内容类型”，RFC 1892，1996年1月。
[8] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996.
[8] Moore，K.，“传递状态通知的SMTP服务扩展”，RFC 18911996年1月。
[9] Moore, K., and G. Vaudreuil, "An Extensible Format for Delivery Status Notifications, RFC 1894, January 1996.
[9] Moore，K.和G.Vaudreuil，“交付状态通知的可扩展格式”，RFC 1894，1996年1月。
[10] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[10] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Roger Fajman National Institutes of Health Building 12A, Room 3063 12 South Drive MSC 5659 Bethesda, Maryland 20892-5659 USA
Roger Fajman美国马里兰州贝塞斯达南大道12号3063室国家卫生研究院12A楼MSC 5659，邮编：20892-5659
EMail: raf@cu.nih.gov
Phone: +1 301 402 4265
Fax: +1 301 480 6241
EMail: raf@cu.nih.gov
Phone: +1 301 402 4265
Fax: +1 301 480 6241
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。