Network Working Group K. Moore
Request for Comments: 3461 University of Tennessee
Obsoletes 1891 January 2003
Category: Standards Track
Network Working Group K. Moore
Request for Comments: 3461 University of Tennessee
Obsoletes 1891 January 2003
Category: Standards Track
Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)
用于传递状态通知（DSN）的简单邮件传输协议（SMTP）服务扩展
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service, which allows an SMTP client to specify (a) that Delivery Status Notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent.
此备忘录定义了简单邮件传输协议（SMTP）服务的扩展，该服务允许SMTP客户端指定（a）在特定条件下应生成传递状态通知（DSN），（b）此类通知是否应返回邮件内容，以及（c）随DSN返回的附加信息，这允许发送方识别为其发出DSN的收件人和发送原始邮件的事务。
Terminology
术语
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [7].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[7]中的说明进行解释。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Framework for the Delivery Status Notification Extension . . . 4
3. The Delivery Status Notification service extension . . . . . . 5
4. Additional parameters for RCPT and MAIL commands . . . . . . . 6
4.1 The NOTIFY parameter of the ESMTP RCPT command. . . . . . . . 7
4.2 The ORCPT parameter to the ESMTP RCPT command . . . . . . . . 8
4.3 The RET parameter of the ESMTP MAIL command . . . . . . . . . 9
4.4 The ENVID parameter to the ESMTP MAIL command . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Framework for the Delivery Status Notification Extension . . . 4
3. The Delivery Status Notification service extension . . . . . . 5
4. Additional parameters for RCPT and MAIL commands . . . . . . . 6
4.1 The NOTIFY parameter of the ESMTP RCPT command. . . . . . . . 7
4.2 The ORCPT parameter to the ESMTP RCPT command . . . . . . . . 8
4.3 The RET parameter of the ESMTP MAIL command . . . . . . . . . 9
4.4 The ENVID parameter to the ESMTP MAIL command . . . . . . . . 9
4.5 Restrictions on the use of Delivery Status Notification
parameters. . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Conformance requirements . . . . . . . . . . . . . . . . . . . 10
5.1 SMTP protocol interactions. . . . . . . . . . . . . . . . . . 11
5.2 Handling of messages received via SMTP. . . . . . . . . . . . 11
5.2.1 Relay of messages to other conforming SMTP servers. . . . . 12
5.2.2 Relay of messages to non-conforming SMTP servers. . . . . . 13
5.2.3 Local delivery of messages. . . . . . . . . . . . . . . . . 14
5.2.4 Gatewaying a message into a foreign environment . . . . . . 14
5.2.5 Delays in delivery. . . . . . . . . . . . . . . . . . . . . 15
5.2.6 Failure of a conforming MTA to deliver a message. . . . . . 16
5.2.7 Forwarding, aliases, and mailing lists. . . . . . . . . . . 16
5.2.7.1 mailing lists . . . . . . . . . . . . . . . . . . . . . . 17
5.2.7.2 single-recipient aliases. . . . . . . . . . . . . . . . . 18
5.2.7.3 multiple-recipient aliases. . . . . . . . . . . . . . . . 18
5.2.7.4 confidential forwarding addresses . . . . . . . . . . . . 18
5.2.8 DSNs describing delivery to multiple recipients . . . . . . 19
5.3 Handling of messages from other sources . . . . . . . . . . . 19
5.4 Implementation limits . . . . . . . . . . . . . . . . . . . . 19
6. Format of delivery notifications . . . . . . . . . . . . . . . 20
6.1 SMTP Envelope to be used with delivery status
notifications . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2 Contents of the DSN . . . . . . . . . . . . . . . . . . . . . 20
6.3 Message/delivery-status fields. . . . . . . . . . . . . . . . 21
7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 22
9. Appendix - Type-Name Definitions . . . . . . . . . . . . . . . 24
9.1 "rfc822" address-type . . . . . . . . . . . . . . . . . . . . 24
9.2 "smtp" diagnostic-type. . . . . . . . . . . . . . . . . . . . 24
9.3 "dns" MTA-name-type . . . . . . . . . . . . . . . . . . . . . 25
10. Appendix - Example. . . . . . . . . . . . . . . . . . . . . . 26
10.1 Submission . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.2 Relay to Example.COM . . . . . . . . . . . . . . . . . . . . 28
10.3 Relay to Ivory.EDU . . . . . . . . . . . . . . . . . . . . . 29
10.4 Relay to Bombs.AF.MIL. . . . . . . . . . . . . . . . . . . . 30
10.5 Forward from George@Tax-ME.GOV to Sam@Boondoggle.GOV . . . . 31
10.6 "Delivered" DSN for Bob@Example.COM. . . . . . . . . . . . . 32
10.7 Failed DSN for Carol@Ivory.EDU . . . . . . . . . . . . . . . 33
10.8 Relayed DSN For Dana@Ivory.EDU . . . . . . . . . . . . . . . 34
10.9 Failure notification for Sam@Boondoggle.GOV. . . . . . . . . 35
11. Appendix - Changes since RFC 1891 . . . . . . . . . . . . . . 35
12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 36
12.1 Normative References . . . . . . . . . . . . . . . . . . . . 36
12.2 Informative References . . . . . . . . . . . . . . . . . . . 36
13. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 37
14. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 38
4.5 Restrictions on the use of Delivery Status Notification
parameters. . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Conformance requirements . . . . . . . . . . . . . . . . . . . 10
5.1 SMTP protocol interactions. . . . . . . . . . . . . . . . . . 11
5.2 Handling of messages received via SMTP. . . . . . . . . . . . 11
5.2.1 Relay of messages to other conforming SMTP servers. . . . . 12
5.2.2 Relay of messages to non-conforming SMTP servers. . . . . . 13
5.2.3 Local delivery of messages. . . . . . . . . . . . . . . . . 14
5.2.4 Gatewaying a message into a foreign environment . . . . . . 14
5.2.5 Delays in delivery. . . . . . . . . . . . . . . . . . . . . 15
5.2.6 Failure of a conforming MTA to deliver a message. . . . . . 16
5.2.7 Forwarding, aliases, and mailing lists. . . . . . . . . . . 16
5.2.7.1 mailing lists . . . . . . . . . . . . . . . . . . . . . . 17
5.2.7.2 single-recipient aliases. . . . . . . . . . . . . . . . . 18
5.2.7.3 multiple-recipient aliases. . . . . . . . . . . . . . . . 18
5.2.7.4 confidential forwarding addresses . . . . . . . . . . . . 18
5.2.8 DSNs describing delivery to multiple recipients . . . . . . 19
5.3 Handling of messages from other sources . . . . . . . . . . . 19
5.4 Implementation limits . . . . . . . . . . . . . . . . . . . . 19
6. Format of delivery notifications . . . . . . . . . . . . . . . 20
6.1 SMTP Envelope to be used with delivery status
notifications . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2 Contents of the DSN . . . . . . . . . . . . . . . . . . . . . 20
6.3 Message/delivery-status fields. . . . . . . . . . . . . . . . 21
7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 22
9. Appendix - Type-Name Definitions . . . . . . . . . . . . . . . 24
9.1 "rfc822" address-type . . . . . . . . . . . . . . . . . . . . 24
9.2 "smtp" diagnostic-type. . . . . . . . . . . . . . . . . . . . 24
9.3 "dns" MTA-name-type . . . . . . . . . . . . . . . . . . . . . 25
10. Appendix - Example. . . . . . . . . . . . . . . . . . . . . . 26
10.1 Submission . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.2 Relay to Example.COM . . . . . . . . . . . . . . . . . . . . 28
10.3 Relay to Ivory.EDU . . . . . . . . . . . . . . . . . . . . . 29
10.4 Relay to Bombs.AF.MIL. . . . . . . . . . . . . . . . . . . . 30
10.5 Forward from George@Tax-ME.GOV to Sam@Boondoggle.GOV . . . . 31
10.6 "Delivered" DSN for Bob@Example.COM. . . . . . . . . . . . . 32
10.7 Failed DSN for Carol@Ivory.EDU . . . . . . . . . . . . . . . 33
10.8 Relayed DSN For Dana@Ivory.EDU . . . . . . . . . . . . . . . 34
10.9 Failure notification for Sam@Boondoggle.GOV. . . . . . . . . 35
11. Appendix - Changes since RFC 1891 . . . . . . . . . . . . . . 35
12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 36
12.1 Normative References . . . . . . . . . . . . . . . . . . . . 36
12.2 Informative References . . . . . . . . . . . . . . . . . . . 36
13. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 37
14. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 38
The SMTP protocol [1] requires that an SMTP server provide notification of delivery failure, if it determines that a message cannot be delivered to one or more recipients. Traditionally, such notification consists of an ordinary Internet mail message (format defined by [2]), sent to the envelope sender address (the argument of the SMTP MAIL command), containing an explanation of the error and at least the headers of the failed message.
SMTP协议[1]要求SMTP服务器在确定无法将邮件传递给一个或多个收件人时提供传递失败通知。传统上，此类通知由普通Internet邮件（格式由[2]定义）组成，发送到信封发送者地址（SMTP邮件命令的参数），其中包含错误解释，至少包含失败邮件的标题。
Experience with large mail distribution lists [8] indicates that such messages are often insufficient to diagnose problems, or even to determine at which host or for which recipients a problem occurred. In addition, the lack of a standardized format for delivery notifications in Internet mail makes it difficult to exchange such notifications with other message handling systems.
使用大型邮件分发列表[8]的经验表明，此类邮件通常不足以诊断问题，甚至不足以确定问题发生在哪个主机或哪个收件人。此外，由于缺乏互联网邮件中传递通知的标准格式，因此很难与其他邮件处理系统交换此类通知。
Such experience has demonstrated a need for a delivery status notification service for Internet electronic mail, which:
这种经验表明，需要为互联网电子邮件提供传递状态通知服务，该服务：
(a) is reliable, in the sense that any DSN request will either be honored at the time of final delivery, or result in a response that indicates that the request cannot be honored,
(a) 是可靠的，从某种意义上讲，任何DSN请求要么在最终交付时得到满足，要么导致响应表明无法满足该请求，
(b) when both success and failure notifications are requested, provides an unambiguous and nonconflicting indication of whether delivery of a message to a recipient succeeded or failed,
(b) 当同时请求成功和失败通知时，提供一个明确且无冲突的指示，指示将邮件传递给收件人是成功还是失败，
(c) is stable, in that a failed attempt to deliver a DSN should never result in the transmission of another DSN over the network,
(c) 是稳定的，因为发送DSN的失败尝试不应导致通过网络传输另一个DSN，
(d) preserves sufficient information to allow the sender to identify both the mail transaction and the recipient address which caused the notification, even when mail is forwarded or gatewayed to foreign environments, and
(d) 保留足够的信息，使发件人能够识别导致通知的邮件事务和收件人地址，即使邮件被转发或通过网关传送到外部环境，以及
(e) interfaces acceptably with non-SMTP and non-822-based mail systems, both so that notifications returned from foreign mail systems may be useful to Internet users, and so that the notification requests from foreign environments may be honored. Among the requirements implied by this goal are the ability to request non-return-of-content, and the ability to specify whether positive delivery notifications, negative delivery notifications, both, or neither, should be issued.
(e) 与非SMTP和基于非822的邮件系统进行可接受的接口，这两种系统都可以使从外部邮件系统返回的通知对Internet用户有用，并且可以满足来自外部环境的通知请求。该目标隐含的要求包括请求不返回内容的能力，以及指定是否应发布积极交付通知、消极交付通知（两者都应发布）或两者都不应发布的能力。
In an attempt to provide such a service, this memo uses the mechanism defined in [1] to define an extension to the SMTP protocol. Using this mechanism, an SMTP client may request that an SMTP server issue or not issue a Delivery Status Notification (DSN) under certain conditions. The format of a DSN is defined in [3].
为了提供此类服务，此备忘录使用[1]中定义的机制定义SMTP协议的扩展。使用此机制，SMTP客户端可以请求SMTP服务器在某些情况下发出或不发出传递状态通知（DSN）。DSN的格式在[3]中定义。
The following service extension is therefore defined:
因此，定义了以下服务扩展：
(1) The name of the SMTP service extension is "Delivery Status Notification";
(1) SMTP服务扩展名为“传递状态通知”；
(2) the EHLO keyword value associated with this extension is "DSN", the meaning of which is defined in section 3 of this memo;
(2) 与此扩展相关的EHLO关键字值为“DSN”，其含义见本备忘录第3节；
(3) no parameters are allowed with this EHLO keyword value;
(3) 此EHLO关键字值不允许使用任何参数；
(4) two optional parameters are added to the RCPT command, and two optional parameters are added to the MAIL command:
(4) RCPT命令中添加了两个可选参数，MAIL命令中添加了两个可选参数：
An optional parameter for the RCPT command, using the esmtp-keyword "NOTIFY", (to specify the conditions under which a Delivery Status Notification should be generated), is defined in section 5.1,
第5.1节中定义了RCPT命令的可选参数，该参数使用esmtp关键字“NOTIFY”（用于指定应生成交付状态通知的条件），
An optional parameter for the RCPT command, using the esmtp-keyword "ORCPT", (used to convey the "original" (sender-specified) recipient address), is defined in section 5.2, and
第5.2节定义了RCPT命令的可选参数，该参数使用esmtp关键字“ORCPT”（用于传达“原始”（发件人指定的）收件人地址），以及
An optional parameter for the MAIL command, using the esmtp-keyword "RET", (to request that DSNs containing an indication of delivery failure either return the entire contents of a message or only the message headers), is defined in section 5.3,
第5.3节中定义了邮件命令的可选参数，该参数使用esmtp关键字“RET”（用于请求包含传递失败指示的DSN返回邮件的全部内容或仅返回邮件标题），
An optional parameter for the MAIL command, using the esmtp-keyword "ENVID", (used to propagate an identifier for this message transmission envelope, which is also known to the sender and will, if present, be returned in any DSNs issued for this transmission), is defined in section 4.4;
第4.4节定义了使用esmtp关键字“ENVID”的MAIL命令的可选参数（用于传播此消息传输信封的标识符，发送方也知道该标识符，如果存在，将在为此传输发布的任何DSN中返回）；
(5) no additional SMTP verbs are defined by this extension.
(5) 此扩展未定义其他SMTP谓词。
The remainder of this memo specifies how support for the extension affects the behavior of a message transfer agent.
此备忘录的其余部分指定对扩展的支持如何影响消息传输代理的行为。
An SMTP client wishing to request a DSN for a message may issue the EHLO command to start an SMTP session, to determine if the server supports any of several service extensions. If the server responds with code 250 to the EHLO command, and the response includes the EHLO keyword DSN, then the Delivery Status Notification extension (as described in this memo) is supported.
希望为邮件请求DSN的SMTP客户端可以发出EHLO命令来启动SMTP会话，以确定服务器是否支持多个服务扩展中的任何一个。如果服务器以代码250响应EHLO命令，且响应包含EHLO关键字DSN，则支持传递状态通知扩展（如本备忘录所述）。
Ordinarily, when an SMTP server returns a positive (2xx) reply code in response to a RCPT command, it agrees to accept responsibility for either delivering the message to the named recipient, or sending a notification to the sender of the message indicating that delivery has failed. However, an extended SMTP ("ESMTP") server which implements this service extension will accept an optional NOTIFY parameter with the RCPT command. If present, the NOTIFY parameter alters the conditions for generation of Delivery Status Notifications from the default (issue notifications only on failure) specified in [1]. The ESMTP client may also request (via the RET parameter) whether the entire contents of the original message should be returned (as opposed to just the headers of that message), along with the DSN.
通常，当SMTP服务器响应RCPT命令返回肯定（2xx）回复代码时，它同意承担将邮件传递给指定收件人或向发件人发送邮件通知以指示传递失败的责任。但是，实现此服务扩展的扩展SMTP（“ESMTP”）服务器将使用RCPT命令接受可选的NOTIFY参数。如果存在，NOTIFY参数将更改从[1]中指定的默认值（仅在失败时发出通知）生成传递状态通知的条件。ESMTP客户端还可以请求（通过RET参数）是否应连同DSN一起返回原始消息的全部内容（而不仅仅是该消息的标题）。
In general, an ESMTP server which implements this service extension will propagate Delivery Status Notification requests when relaying mail to other SMTP-based MTAs which also support this extension, and make a "best effort" to ensure that such requests are honored when messages are passed into other environments.
通常，实现此服务扩展的ESMTP服务器将在将邮件中继到其他也支持此扩展的基于SMTP的MTA时传播传递状态通知请求，并“尽最大努力”确保在将邮件传递到其他环境时遵守此类请求。
In order for Delivery Status Notifications to be meaningful to the sender, ESMTP servers, which support this extension, should propagate the following information for use in generating DSNs to any other MTAs that are used to relay the message:
为了使传递状态通知对发件人有意义，支持此扩展的ESMTP服务器应传播以下信息，以用于生成DSN，并将其发送到用于中继邮件的任何其他MTA：
(a) for each recipient, a copy of the original recipient address, as used by the sender of the message.
(a) 对于每个收件人，邮件发件人使用的原始收件人地址的副本。
This address need not be the same as the mailbox specified in the RCPT command. For example, if a message was originally addressed to A@B.C and later forwarded to A@D.E, after such forwarding has taken place, the RCPT command will specify a mailbox of A@D.E. However, the original recipient address remains A@B.C.
此地址不必与RCPT命令中指定的邮箱相同。例如，如果邮件最初的地址是A@B.C然后转发给A@D.E，在进行此类转发后，RCPT命令将指定A@D.E.但是，原始收件人地址仍然保留A@B.C.
Also, if the message originated from an environment which does not use Internet-style user@domain addresses, and was gatewayed into SMTP, the original recipient address will preserve the original form of the recipient address.
此外，如果消息来源于不使用Internet样式的环境user@domain地址，并通过网关传送到SMTP，原始收件人地址将保留收件人地址的原始形式。
(b) for the entire SMTP transaction, an envelope identification string, which may be used by the sender to associate any delivery status notifications with the transaction used to send the original message.
(b) 对于整个SMTP事务，一个信封标识字符串，发件人可使用该字符串将任何传递状态通知与用于发送原始邮件的事务相关联。
The extended RCPT and MAIL commands are issued by a client when it wishes to request a DSN from the server, under certain conditions, for a particular recipient. The extended RCPT and MAIL commands are identical to the RCPT and MAIL commands defined in [1], except that one or more of the following parameters appear after the sender or recipient address, respectively. The general syntax for extended SMTP commands is defined in [1].
当客户端希望在特定条件下为特定收件人从服务器请求DSN时，会发出扩展RCPT和MAIL命令。扩展的RCPT和MAIL命令与[1]中定义的RCPT和MAIL命令相同，只是以下一个或多个参数分别出现在发件人或收件人地址之后。[1]中定义了扩展SMTP命令的通用语法。
NOTE: Although RFC 822 ABNF is used to describe the syntax of these parameters, they are not, in the language of that document, "structured field bodies". Therefore, while parentheses MAY appear within an emstp-value, they are not recognized as comment delimiters.
注：尽管RFC 822 ABNF用于描述这些参数的语法，但在该文档的语言中，它们不是“结构化字段体”。因此，尽管括号可能出现在emstp值中，但它们不能识别为注释分隔符。
The syntax for "esmtp-value" in [1] does not allow SP, "=", control characters, or characters outside the traditional ASCII range of 1-127 decimal to be transmitted in an esmtp-value. Because the ENVID and ORCPT parameters may need to convey values outside this range, the esmtp-values for these parameters are encoded as "xtext". "xtext" is formally defined as follows:
[1]中“esmtp值”的语法不允许在esmtp值中传输SP“=”、控制字符或1-127十进制的传统ASCII范围之外的字符。由于ENVID和ORCPT参数可能需要传递超出此范围的值，因此这些参数的esmtp值被编码为“xtext”。“xtext”的正式定义如下：
xtext = *( xchar / hexchar )
xtext = *( xchar / hexchar )
xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive, except for "+" and "=".
xchar=介于“！”（33）和“~”（126）之间的任意ASCII字符，但“+”和“=”除外。
; "hexchar"s are intended to encode octets that cannot appear ; as ASCII characters within an esmtp-value.
; “hexchar”用于编码不能出现的八位字节；作为esmtp值中的ASCII字符。
hexchar = ASCII "+" immediately followed by two upper case hexadecimal digits
hexchar=ASCII“+”后跟两个大写十六进制数字
When encoding an octet sequence as xtext:
将八位字节序列编码为xtext时：
+ Any ASCII CHAR between "!" and "~" inclusive, except for "+" and "=", MAY be encoded as itself. (A CHAR in this range MAY instead be encoded as a "hexchar", at the implementor's discretion.)
+ 除了“+”和“=”之外，包含“！”和“~”之间的任何ASCII字符都可以作为自身编码。（此范围内的字符可以由实现者自行决定编码为“hexchar”。）
+ ASCII CHARs that fall outside the range above must be encoded as "hexchar".
+ 超出上述范围的ASCII字符必须编码为“hexchar”。
A RCPT command issued by a client may contain the optional esmtp-keyword "NOTIFY", to specify the conditions under which the SMTP server should generate DSNs for that recipient. If the NOTIFY esmtp-keyword is used, it MUST have an associated esmtp-value, formatted according to the following rules, using the ABNF of RFC 822:
客户端发出的RCPT命令可能包含可选的esmtp关键字“NOTIFY”，以指定SMTP服务器为该收件人生成DSN的条件。如果使用NOTIFY esmtp关键字，则必须使用RFC 822的ABNF，具有根据以下规则格式化的关联esmtp值：
notify-esmtp-value = "NEVER" / 1#notify-list-element
notify-esmtp-value = "NEVER" / 1#notify-list-element
notify-list-element = "SUCCESS" / "FAILURE" / "DELAY"
notify-list-element = "SUCCESS" / "FAILURE" / "DELAY"
Notes:
笔记：
a. Multiple notify-list-elements, separated by commas, MAY appear in a NOTIFY parameter; however, the NEVER keyword MUST appear by itself.
a. 一个notify参数中可能出现多个notify list元素，以逗号分隔；但是，NEVER关键字必须单独出现。
b. Any of the keywords NEVER, SUCCESS, FAILURE, or DELAY may be spelled in any combination of upper and lower case letters.
b. 任何关键字NEVER、SUCCESS、FAILURE或DELAY都可以用大写和小写字母的任意组合拼写。
The meaning of the NOTIFY parameter values is generally as follows:
NOTIFY参数值的含义通常如下所示：
+ A NOTIFY parameter value of "NEVER" requests that a DSN not be returned to the sender under any conditions.
+ NOTIFY参数值“NEVER”请求在任何情况下都不要将DSN返回给发送方。
+ A NOTIFY parameter value containing the "SUCCESS" or "FAILURE" keywords requests that a DSN be issued on successful delivery or delivery failure, respectively.
+ 包含“成功”或“失败”关键字的NOTIFY参数值分别请求在成功传递或传递失败时发出DSN。
+ A NOTIFY parameter value containing the keyword "DELAY" indicates the sender's willingness to receive "delayed" DSNs. Delayed DSNs may be issued if delivery of a message has been delayed for an unusual amount of time (as determined by the MTA at which the message is delayed), but the final delivery status (whether successful or failure) cannot be determined. The absence of the DELAY keyword in a NOTIFY parameter requests that a "delayed" DSN NOT be issued under any conditions.
+ 包含关键字“DELAY”的NOTIFY参数值表示发送方愿意接收“DELAY”DSN。如果邮件的传递延迟了不寻常的时间（由邮件延迟的MTA确定），但无法确定最终传递状态（成功或失败），则可能会发出延迟DSN。NOTIFY参数中缺少DELAY关键字要求在任何情况下都不发布“延迟”DSN。
The actual rules governing interpretation of the NOTIFY parameter are given in section 6.
第6节给出了NOTIFY参数解释的实际规则。
For compatibility with SMTP clients that do not use the NOTIFY facility, the absence of a NOTIFY parameter in a RCPT command may be interpreted as either NOTIFY=FAILURE or NOTIFY=FAILURE,DELAY.
为了与不使用NOTIFY功能的SMTP客户端兼容，RCPT命令中缺少NOTIFY参数可能被解释为NOTIFY=FAILURE或NOTIFY=FAILURE，DELAY。
The ORCPT esmtp-keyword of the RCPT command is used to specify an "original" recipient address that corresponds to the actual recipient to which the message is to be delivered. If the ORCPT esmtp-keyword is used, it MUST have an associated esmtp-value, which consists of the original recipient address, encoded according to the rules below. The ABNF for the ORCPT parameter is:
RCPT命令的ORCPT-esmtp关键字用于指定一个“原始”收件人地址，该地址对应于邮件要传递到的实际收件人。如果使用ORCPT esmtp关键字，则必须具有关联的esmtp值，该值由原始收件人地址组成，并根据以下规则进行编码。ORCPT参数的ABNF为：
orcpt-parameter = "ORCPT=" original-recipient-address
orcpt parameter=“orcpt=”原始收件人地址
original-recipient-address = addr-type ";" xtext
原始收件人地址=地址类型“；”xtext
addr-type = atom
addr-type = atom
The "addr-type" portion MUST be an IANA-registered electronic mail address-type (as defined in [3]), while the "xtext" portion contains an encoded representation of the original recipient address using the rules in section 5 of this document. The entire ORCPT parameter MAY be up to 500 characters in length.
“地址类型”部分必须是IANA注册的电子邮件地址类型（定义见[3]），而“xtext”部分包含使用本文件第5节规则对原始收件人地址进行编码的表示。整个ORCPT参数的长度可能最多为500个字符。
When initially submitting a message via SMTP, if the ORCPT parameter is used, it MUST contain the same address as the RCPT TO address (unlike the RCPT TO address, the ORCPT parameter will be encoded as xtext). Likewise, when a mailing list submits a message via SMTP to be distributed to the list subscribers, if ORCPT is used, the ORCPT parameter MUST match the new RCPT TO address of each recipient, not the address specified by the original sender of the message.)
最初通过SMTP提交邮件时，如果使用ORCPT参数，则必须包含与RCPT TO地址相同的地址（与RCPT TO地址不同，ORCPT参数将编码为xtext）。同样，当邮件列表通过SMTP提交要分发给列表订阅者的邮件时，如果使用了ORCPT，则ORCPT参数必须与每个收件人的新RCPT地址相匹配，而不是与邮件原始发件人指定的地址相匹配。）
The "addr-type" portion of the original-recipient-address is used to indicate the "type" of the address which appears in the ORCPT parameter value. However, the address associated with the ORCPT keyword is NOT constrained to conform to the syntax rules for that "addr-type".
原始收件人地址的“addr type”部分用于指示ORCPT参数值中出现的地址的“type”。但是，与ORCPT关键字关联的地址不受约束，以符合该“addr类型”的语法规则。
Ideally, the "xtext" portion of the original-recipient-address should contain, in encoded form, the same sequence of characters that the sender used to specify the recipient. However, for a message gatewayed from an environment (such as X.400) in which a recipient address is not a simple string of printable characters, the representation of recipient address must be defined by a specification for gatewaying between DSNs and that environment.
理想情况下，原始收件人地址的“xtext”部分应以编码形式包含发件人用于指定收件人的相同字符序列。但是，对于从收件人地址不是简单的可打印字符字符串的环境（如X.400）通过网关传送的邮件，必须通过DSN和该环境之间的网关传送规范定义收件人地址的表示形式。
Due to limitations in the Delivery Status Notification format, the value of the original recipient address prior to encoding as "xtext" MUST consist entirely of printable (graphic and white space) characters from the US-ASCII [4] repertoire. If an addr-type is defined for addresses which use characters outside of this repertoire, the specification for that addr-type MUST define the means of encoding those addresses in printable US-ASCII characters when are then encoded as xtext.
由于交付状态通知格式的限制，在编码为“xtext”之前，原始收件人地址的值必须完全由US-ASCII[4]指令表中的可打印（图形和空白）字符组成。如果为使用本指令表以外字符的地址定义了addr类型，则该addr类型的规范必须定义将这些地址编码为可打印US-ASCII字符的方法，然后将这些地址编码为xtext。
The RET esmtp-keyword on the extended MAIL command specifies whether or not the message should be included in any failed DSN issued for this message transmission. If the RET esmtp-keyword is used, it MUST have an associated esmtp-value, which is one of the following keywords:
extended MAIL命令上的RET esmtp关键字指定是否应将该消息包含在为此消息传输发出的任何失败DSN中。如果使用RET esmtp关键字，则它必须具有关联的esmtp值，该值是以下关键字之一：
FULL requests that the entire message be returned in any "failed" Delivery Status Notification issued for this recipient.
完整请求在为此收件人发出的任何“失败”传递状态通知中返回整个邮件。
HDRS requests that only the headers of the message be returned.
HDRS请求只返回消息的标题。
The FULL and HDRS keywords may be spelled in any combination of upper and lower case letters.
FULL和HDRS关键字可以用大写和小写字母的任意组合拼写。
If no RET parameter is supplied, the MTA MAY return either the headers of the message or the entire message for any DSN containing indication of failed deliveries.
如果未提供RET参数，MTA可能会返回消息的标题，或者返回包含失败传递指示的任何DSN的整个消息。
Note that the RET parameter only applies to DSNs that indicate delivery failure for at least one recipient. If a DSN contains no indications of delivery failure, only the headers of the message should be returned.
请注意，RET参数仅适用于指示至少一个收件人的传递失败的DSN。如果DSN不包含传递失败的指示，则只应返回消息的标题。
The ENVID esmtp-keyword of the SMTP MAIL command is used to specify an "envelope identifier" to be transmitted along with the message and included in any DSNs issued for any of the recipients named in this SMTP transaction. The purpose of the envelope identifier is to allow the sender of a message to identify the transaction for which the DSN was issued.
SMTP邮件命令的ENVID esmtp关键字用于指定要随邮件一起传输的“信封标识符”，并包含在为此SMTP事务中指定的任何收件人发出的任何DSN中。信封标识符的用途是允许消息发送方识别为其发出DSN的交易。
The ABNF for the ENVID parameter is:
ENVID参数的ABNF为：
envid-parameter = "ENVID=" xtext
envid parameter=“envid=”xtext
The ENVID esmtp-keyword MUST have an associated esmtp-value. No meaning is assigned by the mail system to the presence or absence of this parameter or to any esmtp-value associated with this parameter; the information is used only by the sender or his user agent. The ENVID parameter MAY be up to 100 characters in length.
ENVID esmtp关键字必须具有关联的esmtp值。邮件系统未对该参数的存在或不存在或与该参数相关的任何esmtp值赋予任何含义；该信息仅由发件人或其用户代理使用。ENVID参数的长度可能最多为100个字符。
Due to limitations in the Delivery Status Notification format, the value of the ENVID parameter prior to encoding as "xtext" MUST consist entirely of printable (graphic and white space) characters from the US-ASCII [4] repertoire.
由于交付状态通知格式的限制，编码为“xtext”之前的ENVID参数值必须完全由US-ASCII[4]指令表中的可打印（图形和空白）字符组成。
The RET and ENVID parameters MUST NOT appear more than once each in any single MAIL command. If more than one of either of these parameters appears in a MAIL command, the ESMTP server SHOULD respond with "501 syntax error in parameters or arguments".
RET和ENVID参数在任何单个邮件命令中不得出现多次。如果邮件命令中出现这些参数中的一个以上，ESMTP服务器应以“参数或参数中的501语法错误”进行响应。
The NOTIFY and ORCPT parameters MUST NOT appear more than once in any RCPT command. If more than one of either of these parameters appears in a RCPT command, the ESMTP server SHOULD respond with "501 syntax error in parameters or arguments".
NOTIFY和ORCPT参数在任何RCPT命令中不得出现多次。如果RCPT命令中出现这些参数中的一个以上，ESMTP服务器应响应“参数或参数中出现501语法错误”。
The Simple Mail Transfer Protocol (SMTP) is used by Message Transfer Agents (MTAs) when accepting, relaying, or gatewaying mail, as well as User Agents (UAs) when submitting mail to the mail transport system. The DSN extension to SMTP may be used to allow UAs to convey the sender's requests as to when DSNs should be issued. A UA which claims to conform to this specification must meet certain requirements as described below.
简单邮件传输协议（SMTP）由邮件传输代理（MTA）在接受、中继或网关邮件时使用，也由用户代理（UAs）在向邮件传输系统提交邮件时使用。SMTP的DSN扩展可用于允许UAs传达发件人关于何时应发出DSN的请求。声称符合本规范的UA必须满足下述特定要求。
Typically, a message transfer agent (MTA) which supports SMTP will assume, at different times, both the role of a SMTP client and an SMTP server, and may also provide local delivery, gatewaying to foreign environments, forwarding, and mailing list expansion. An MTA which, when acting as an SMTP server, issues the DSN keyword in response to the EHLO command, MUST obey the rules below for a "conforming SMTP client" when acting as a client, and a "conforming SMTP server" when acting as a server. The term "conforming MTA" refers to an MTA which conforms to this specification, independent of its role of client or server.
通常，支持SMTP的邮件传输代理（MTA）将在不同的时间承担SMTP客户端和SMTP服务器的角色，并且还可以提供本地传递、到外部环境的网关、转发和邮件列表扩展。当作为SMTP服务器时，MTA发出DSN关键字以响应EHLO命令，当作为客户端时，MTA必须遵守以下规则“一致性SMTP客户端”，当作为服务器时，MTA必须遵守以下规则“一致性SMTP服务器”。术语“一致性MTA”指符合本规范的MTA，独立于其客户端或服务器角色。
The following rules apply to SMTP transactions in which any of the ENVID, NOTIFY, RET, or ORCPT keywords are used:
以下规则适用于使用ENVID、NOTIFY、RET或ORCPT关键字的SMTP事务：
(a) If an SMTP client issues a MAIL command containing a valid ENVID parameter and associated esmtp-value and/or a valid RET parameter and associated esmtp-value, a conforming SMTP server MUST return the same reply-code as it would to the same MAIL command without the ENVID and/or RET parameters. A conforming SMTP server MUST NOT refuse a MAIL command based on the absence or presence of valid ENVID or RET parameters, or on their associated esmtp-values.
(a) 如果SMTP客户端发出包含有效ENVID参数和相关esmtp值和/或有效RET参数和相关esmtp值的邮件命令，则一致性SMTP服务器必须返回与不带ENVID和/或RET参数的相同邮件命令相同的回复代码。一致性SMTP服务器不得基于有效ENVID或RET参数的缺失或存在，或基于其相关esmtp值拒绝邮件命令。
However, if the associated esmtp-value is not valid (i.e., contains illegal characters), or if there is more than one ENVID or RET parameter in a particular MAIL command, the server MUST issue the reply-code 501 with an appropriate message (e.g., "syntax error in parameter").
然而，如果相关联的esmtp值无效（即，包含非法字符），或者如果特定邮件命令中有多个ENVID或RET参数，则服务器必须发出带有适当消息的回复代码501（例如，“参数中的语法错误”）。
(b) If an SMTP client issues a RCPT command containing any valid NOTIFY and/or ORCPT parameters, a conforming SMTP server MUST return the same response as it would to the same RCPT command without those NOTIFY and/or ORCPT parameters. A conforming SMTP server MUST NOT refuse a RCPT command based on the presence or absence of any of these parameters.
(b) 如果SMTP客户端发出包含任何有效NOTIFY和/或ORCPT参数的RCPT命令，则一致性SMTP服务器必须返回与不包含这些NOTIFY和/或ORCPT参数的同一RCPT命令相同的响应。一致性SMTP服务器不得基于存在或不存在这些参数而拒绝RCPT命令。
However, if any of the associated esmtp-values are not valid, or if there is more than one of any of these parameters in a particular RCPT command, the server SHOULD issue the response "501 syntax error in parameter".
但是，如果任何关联的esmtp值无效，或者如果特定RCPT命令中存在多个此类参数，则服务器应发出响应“参数中的501语法错误”。
This section describes how a conforming MTA should handle any messages received via SMTP.
本节介绍合格MTA应如何处理通过SMTP接收的任何邮件。
NOTE: A DSN MUST NOT be returned to the sender for any message for which the return address from the SMTP MAIL command was NULL ("<>"), even if the sender's address is available from other sources (e.g., the message header). However, the MTA which would otherwise issue a DSN SHOULD inform the local postmaster of delivery failures through some appropriate mechanism that will not itself result in the generation of DSNs.
注意：对于SMTP邮件命令返回地址为空（“<>”）的任何邮件，即使发件人的地址可从其他来源（例如邮件标题）获得，也不得将DSN返回给发件人。但是，如果MTA不发出DSN，则应通过某种适当的机制通知当地邮政局长交付失败，这种机制本身不会导致生成DSN。
DISCUSSION: RFC 1123, section 2.3.3 requires error notifications to be sent with a NULL return address ("reverse-path"). This creates an interesting situation when a message arrives with one or more
讨论：RFC 1123第2.3.3节要求发送带有空返回地址（“反向路径”）的错误通知。当一条消息带着一条或多条消息到达时，这会产生一种有趣的情况
nonfunctional recipient addresses in addition to a nonfunctional return address. When delivery to one of the recipient addresses fails, the MTA will attempt to send a nondelivery notification to the return address, setting the return address on the notification to NULL. When the delivery of this notification fails, the MTA attempting delivery of that notification sees a NULL return address. If that MTA were not to inform anyone of the situation, the original message would be silently lost. Furthermore, a nonfunctional return address is often indicative of a configuration problem in the sender's MTA. Reporting the condition to the local postmaster may help to speed correction of such errors.
除了非功能性返回地址之外，还有非功能性收件人地址。当传递到其中一个收件人地址失败时，MTA将尝试向返回地址发送未送达通知，并将通知上的返回地址设置为NULL。当此通知传递失败时，尝试传递该通知的MTA将看到一个空返回地址。如果MTA不将情况通知任何人，原始消息将自动丢失。此外，非功能性返回地址通常表示发送方MTA中存在配置问题。向当地邮政局长报告情况可能有助于加快纠正此类错误。
The following rules govern the behavior of a conforming MTA, when relaying a message which was received via the SMTP protocol, to an SMTP server that supports the Delivery Status Notification service extension:
以下规则控制一致性MTA在将通过SMTP协议接收的邮件中继到支持传递状态通知服务扩展的SMTP服务器时的行为：
(a) Any ENVID parameter included in the MAIL command when a message was received, MUST also appear on the MAIL command with which the message is relayed, with the same associated esmtp-value. If no ENVID parameter was included in the MAIL command when the message was received, the ENVID parameter MUST NOT be supplied when the message is relayed.
(a) 接收消息时，邮件命令中包含的任何ENVID参数也必须以相同的关联esmtp值出现在转发消息的邮件命令上。如果在收到消息时邮件命令中未包含ENVID参数，则在中继消息时不得提供ENVID参数。
(b) Any RET parameter included in the MAIL command when a message was received, MUST also appear on the MAIL command with which the message is relayed, with the same associated esmtp-value. If no RET parameter was included in the MAIL command when the message was received, the RET parameter MUST NOT supplied when the message is relayed.
(b) 接收到消息时，邮件命令中包含的任何RET参数也必须以相同的关联esmtp值出现在转发消息的邮件命令上。如果在接收邮件时邮件命令中未包含RET参数，则在中继邮件时不得提供RET参数。
(c) If the NOTIFY parameter was supplied for a recipient when the message was received, the RCPT command issued when the message is relayed MUST also contain the NOTIFY parameter along with its associated esmtp-value. If the NOTIFY parameter was not supplied for a recipient when the message was received, the NOTIFY parameter MUST NOT be supplied for that recipient when the message is relayed.
(c) 如果在接收消息时为收件人提供了NOTIFY参数，则在中继消息时发出的RCPT命令还必须包含NOTIFY参数及其关联的esmtp值。如果在接收邮件时未为收件人提供NOTIFY参数，则在中继邮件时不得为该收件人提供NOTIFY参数。
(d) If any ORCPT parameter was present in the RCPT command for a recipient when the message was received, an ORCPT parameter with the identical original-recipient-address MUST appear in the RCPT command issued for that recipient when relaying the message. (For example, the MTA therefore MUST NOT change the case of any alphabetic characters in an ORCPT parameter.)
(d) 如果在接收邮件时收件人的RCPT命令中存在任何ORCPT参数，则在中继邮件时为该收件人发出的RCPT命令中必须出现具有相同原始收件人地址的ORCPT参数。（例如，MTA因此不得更改ORCPT参数中任何字母字符的大小写。）
If no ORCPT parameter was present in the RCPT command when the message was received, an ORCPT parameter MAY be added to the RCPT command when the message is relayed. If an ORCPT parameter is added by the relaying MTA, it MUST contain the recipient address from the RCPT command used when the message was received by that MTA.
如果接收到消息时RCPT命令中不存在ORCPT参数，则在中继消息时，可将ORCPT参数添加到RCPT命令中。如果中继MTA添加了ORCPT参数，则该参数必须包含该MTA接收邮件时使用的RCPT命令中的收件人地址。
The following rules govern the behavior of a conforming MTA (in the role of client), when relaying a message which was received via the SMTP protocol, to an SMTP server that does not support the Delivery Status Notification service extension:
以下规则控制一致性MTA（以客户端角色）在将通过SMTP协议接收的邮件中继到不支持传递状态通知服务扩展的SMTP服务器时的行为：
(a) ENVID, NOTIFY, RET, or ORCPT parameters MUST NOT be issued when relaying the message.
(a) 转发消息时，不得发出ENVID、NOTIFY、RET或ORCPT参数。
(b) If the NOTIFY parameter was supplied for a recipient, with an esmtp-value containing the keyword SUCCESS, and the SMTP server returns a success (2xx) reply-code in response to the RCPT command, the client MUST issue a "relayed" DSN for that recipient.
(b) 如果为收件人提供了NOTIFY参数，且esmtp值包含关键字SUCCESS，并且SMTP服务器返回成功（2xx）回复代码以响应RCPT命令，则客户端必须为该收件人发出“中继”DSN。
(c) If the NOTIFY parameter was supplied for a recipient with an esmtp-value containing the keyword FAILURE, and the SMTP server returns a permanent failure (5xx) reply-code in response to the RCPT command, the client MUST issue a "failed" DSN for that recipient.
(c) 如果为包含关键字FAILURE的esmtp值的收件人提供NOTIFY参数，并且SMTP服务器返回永久故障（5xx）回复代码以响应RCPT命令，则客户端必须为该收件人发出“failed”DSN。
(d) If the NOTIFY parameter was supplied for a recipient with an esmtp-value of NEVER, the client MUST NOT issue a DSN for that recipient, regardless of the reply-code returned by the SMTP server. However, if the server returned a failure (5xx) reply-code, the client MAY inform the local postmaster of the delivery failure via an appropriate mechanism that will not itself result in the generation of DSNs.
(d) 如果为esmtp值为NEVER的收件人提供了NOTIFY参数，则无论SMTP服务器返回的回复代码如何，客户端都不得为该收件人发出DSN。但是，如果服务器返回故障（5xx）回复代码，则客户端可以通过适当的机制通知本地邮政局长传递故障，该机制本身不会导致生成DSN。
When attempting to relay a message to an SMTP server that does not support this extension, and if NOTIFY=NEVER was specified for some recipients of that message, a conforming SMTP client MAY relay the message for those recipients in a separate SMTP transaction, using an empty reverse-path in the MAIL command. This will prevent DSNs from being issued for those recipients by MTAs that conform to [1].
尝试将邮件中继到不支持此扩展的SMTP服务器时，如果为该邮件的某些收件人指定了NOTIFY=NEVER，则一致性SMTP客户端可以在单独的SMTP事务中使用MAIL命令中的空反向路径为这些收件人中继邮件。这将阻止符合[1]的MTA为这些收件人颁发DSN。
(e) If a NOTIFY parameter was not supplied for a recipient, and the SMTP server returns a success (2xx) reply-code in response to a RCPT command, the client MUST NOT issue any DSN for that recipient.
(e) 如果未为收件人提供NOTIFY参数，并且SMTP服务器返回成功（2xx）回复代码以响应RCPT命令，则客户端不得为该收件人发出任何DSN。
(f) If a NOTIFY parameter was not supplied for a recipient, and the SMTP server returns a permanent failure (5xx) reply-code in response to a RCPT command, the client MUST issue a "failed" DSN for that recipient.
(f) 如果未为收件人提供NOTIFY参数，并且SMTP服务器返回永久故障（5xx）回复代码以响应RCPT命令，则客户端必须为该收件人发出“失败”DSN。
The following rules govern the behavior of a conforming MTA upon successful delivery of a message that was received via the SMTP protocol, to a local recipient's mailbox:
以下规则控制通过SMTP协议接收的邮件成功传递到本地收件人邮箱时，一致性MTA的行为：
"Delivery" means that the message has been placed in the recipient's mailbox. For messages which are transmitted to a mailbox for later retrieval via IMAP [9], POP [10] or a similar message access protocol, "delivery" occurs when the message is made available to the IMAP (POP, etc.) service, rather than when the message is retrieved by the recipient's user agent.
“传递”表示邮件已放置在收件人的邮箱中。对于通过IMAP[9]、POP[10]或类似的邮件访问协议传输到邮箱以便稍后检索的邮件，当邮件可用于IMAP（POP等）服务时，而不是当收件人的用户代理检索邮件时，“传递”发生。
Similarly, for a recipient address which corresponds to a mailing list exploder, "delivery" occurs when the message is made available to that list exploder, even though the list exploder might refuse to deliver that message to the list recipients.
类似地，对于与邮件列表分解器相对应的收件人地址，当邮件可供该列表分解器使用时，即发生“传递”，即使列表分解器可能拒绝将该邮件传递给列表收件人。
(a) If the NOTIFY parameter was supplied for that recipient, with an esmtp-value containing the SUCCESS keyword, the MTA MUST issue a "delivered" DSN for that recipient.
(a) 如果为该收件人提供了NOTIFY参数，且esmtp值包含SUCCESS关键字，则MTA必须为该收件人发出“已送达”DSN。
(b) If the NOTIFY parameter was supplied for that recipient which did not contain the SUCCESS keyword, the MTA MUST NOT issue a DSN for that recipient.
(b) 如果为不包含SUCCESS关键字的收件人提供了NOTIFY参数，则MTA不得为该收件人颁发DSN。
(c) If the NOTIFY parameter was not supplied for that recipient, the MTA MUST NOT issue a DSN.
(c) 如果未为该收件人提供NOTIFY参数，MTA不得发出DSN。
The following rules govern the behavior of a conforming MTA, when gatewaying a message that was received via the SMTP protocol, into a foreign (non-SMTP) environment:
将通过SMTP协议接收的邮件网关化到外部（非SMTP）环境时，以下规则控制一致性MTA的行为：
(a) If the the foreign environment is capable of issuing appropriate notifications under the conditions requested by the NOTIFY parameter, and the conforming MTA can ensure that any
(a) 如果外部环境能够在NOTIFY参数要求的条件下发出适当的通知，且符合要求的MTA可以确保
notification thus issued will be translated into a DSN and delivered to the original sender, then the MTA SHOULD gateway the message into the foreign environment, requesting notification under the desired conditions, without itself issuing a DSN.
这样发出的通知将转换为DSN并传递给原始发件人，然后MTA应将邮件网关化到外部环境，在所需条件下请求通知，而不自行发出DSN。
(b) If a NOTIFY parameter was supplied with the SUCCESS keyword, but the destination environment cannot return an appropriate notification on successful delivery, the MTA SHOULD issue a "relayed" DSN for that recipient.
(b) 如果为NOTIFY参数提供了SUCCESS关键字，但目标环境无法在成功传递时返回适当的通知，则MTA应为该收件人发出“中继”DSN。
(c) If a NOTIFY parameter was supplied with an esmtp-keyword of NEVER, a DSN MUST NOT be issued. If possible, the MTA SHOULD direct the destination environment to not issue delivery notifications for that recipient.
(c) 如果为NOTIFY参数提供的esmtp关键字为NEVER，则不得发出DSN。如果可能，MTA应指示目标环境不要为该收件人发出传递通知。
(d) If the NOTIFY parameter was not supplied for a particular recipient, a DSN SHOULD NOT be issued by the gateway. The gateway SHOULD attempt to ensure that appropriate notification will be provided by the foreign mail environment if eventual delivery failure occurs, and that no notification will be issued on successful delivery.
(d) 如果未为特定收件人提供NOTIFY参数，则网关不应发出DSN。网关应尝试确保在最终发生传递失败时，外部邮件环境将提供适当的通知，并且在成功传递时不会发出通知。
(e) When gatewaying a message into a foreign environment, the return-of-content conditions specified by any RET parameter are nonbinding; however, the MTA SHOULD attempt to honor the request using whatever mechanisms exist in the foreign environment.
(e) 将消息网关传送到外部环境时，任何RET参数指定的内容条件的返回都是非绑定的；但是，MTA应尝试使用外部环境中存在的任何机制来满足请求。
If a conforming MTA receives a message via the SMTP protocol, and is unable to deliver or relay the message to one or more recipients for an extended length of time (to be determined by the MTA), it MAY issue a "delayed" DSN for those recipients, subject to the following conditions:
如果符合条件的MTA通过SMTP协议接收邮件，并且在较长时间内（由MTA确定）无法将邮件传递或中继给一个或多个收件人，则可根据以下条件为这些收件人发出“延迟”DSN：
(a) If the NOTIFY parameter was supplied for a recipient and its value included the DELAY keyword, a "delayed" DSN MAY be issued.
(a) 如果为收件人提供了NOTIFY参数，且其值包含DELAY关键字，则可能会发出“delayed”DSN。
(b) If the NOTIFY parameter was not supplied for a recipient, a "delayed" DSN MAY be issued.
(b) 如果未为收件人提供NOTIFY参数，则可能会发出“延迟”DSN。
(c) If the NOTIFY parameter was supplied which did not contain the DELAY keyword, a "delayed" DSN MUST NOT be issued.
(c) 如果提供的NOTIFY参数不包含DELAY关键字，则不得发出“delayed”DSN。
NOTE: Although delay notifications are common in present-day electronic mail, a conforming MTA is never required to issue "delayed" DSNs. The DELAY keyword of the NOTIFY parameter is provided to allow the SMTP client to specifically request (by omitting the DELAY parameter) that "delayed" DSNs NOT be issued.
注意：尽管延迟通知在当今的电子邮件中很常见，但一致的MTA从未要求发出“延迟”DSN。NOTIFY参数的DELAY关键字用于允许SMTP客户端明确请求（通过省略DELAY参数）不发布“延迟”DSN。
The following rules govern the behavior of a conforming MTA which received a message via the SMTP protocol, and is unable to deliver a message to a recipient specified in the SMTP transaction:
以下规则控制通过SMTP协议接收邮件且无法向SMTP事务中指定的收件人传递邮件的一致性MTA的行为：
(a) If a NOTIFY parameter was supplied for the recipient with an esmtp-keyword containing the value FAILURE, a "failed" DSN MUST be issued by the MTA.
(a) 如果为收件人提供了NOTIFY参数，且esmtp关键字包含值FAILURE，则MTA必须发出“failed”DSN。
(b) If a NOTIFY parameter was supplied for the recipient which did not contain the value FAILURE, a DSN MUST NOT be issued for that recipient. However, the MTA MAY inform the local postmaster of the delivery failure via some appropriate mechanism which does not itself result in the generation of DSNs.
(b) 如果为不包含值FAILURE的收件人提供了NOTIFY参数，则不得为该收件人发出DSN。但是，MTA可能会通过某种适当的机制通知当地邮政局长投递失败，这种机制本身不会导致生成DSN。
(c) If no NOTIFY parameter was supplied for the recipient, a "failed" DSN MUST be issued.
(c) 如果没有为收件人提供NOTIFY参数，则必须发出“失败”DSN。
NOTE: Some MTAs are known to forward undeliverable messages to the local postmaster or "dead letter" mailbox. This is still considered delivery failure, and does not diminish the requirement to issue a "failed" DSN under the conditions defined elsewhere in this memo. If a DSN is issued for such a recipient, the Action value MUST be "failed".
注意：已知某些MTA会将无法投递的邮件转发到本地邮政局长或“死信”邮箱。这仍然被视为交付失败，并不会减少在本备忘录其他地方定义的条件下发布“失败”DSN的要求。如果为此类收件人发出DSN，则操作值必须为“失败”。
Delivery of a message to a local email address usually causes the message to be stored in the recipient's mailbox. However, MTAs commonly provide a facility where a local email address can be designated as an "alias" or "mailing list"; delivery to that address then causes the message to be forwarded to each of the (local or remote) recipient addresses associated with the alias or list. It is also common to allow a user to optionally "forward" her mail to one or more alternate addresses. If this feature is enabled, her mail is redistributed to those addresses instead of being deposited in her mailbox.
将邮件传递到本地电子邮件地址通常会导致邮件存储在收件人的邮箱中。然而，MTA通常提供一种设施，可以将本地电子邮件地址指定为“别名”或“邮件列表”；传递到该地址会导致邮件转发到与别名或列表关联的每个（本地或远程）收件人地址。允许用户有选择地将邮件“转发”到一个或多个备用地址也是很常见的。如果启用此功能，她的邮件将重新分发到这些地址，而不是存放在她的邮箱中。
Following the example of [11] (section 5.3.6), this document defines the difference between an "alias" and "mailing list" as follows: When forwarding a message to the addresses associated with an "alias", the
按照[11]的示例（第5.3.6节），本文件定义了“别名”和“邮件列表”之间的区别，如下所示：将邮件转发到与“别名”关联的地址时
envelope return address (e.g., SMTP MAIL FROM) remains intact. However, when forwarding a message to the addresses associated with a "mailing list", the envelope return address is changed to that of the administrator of the mailing list. This causes DSNs and other nondelivery reports resulting from delivery to the list members to be sent to the list administrator rather than the sender of the original message.
信封返回地址（例如，来自的SMTP邮件）保持不变。但是，当将邮件转发到与“邮件列表”关联的地址时，信封返回地址将更改为邮件列表管理员的地址。这会导致将DSN和其他因传递到列表成员而产生的非传递报告发送给列表管理员，而不是原始邮件的发件人。
The DSN processing for aliases and mailing lists is as follows:
别名和邮件列表的DSN处理如下：
When a message is delivered to a list submission address (i.e., placed in the list's mailbox for incoming mail, or accepted by the process that redistributes the message to the list subscribers), this is considered final delivery for the original message. If the NOTIFY parameter for the list submission address contained the SUCCESS keyword, a "delivered" DSN MUST be returned to the sender of the original message.
将邮件发送到列表提交地址（即，将邮件放入列表邮箱以接收邮件，或由将邮件重新分发给列表订阅者的流程接受）时，这被视为原始邮件的最终发送。如果列表提交地址的NOTIFY参数包含SUCCESS关键字，则必须将“已送达”DSN返回给原始邮件的发件人。
NOTE: Some mailing lists are able to reject message submissions, based on the content of the message, the sender's address, or some other criteria. While the interface between such a mailing list and its MTA is not well-defined, it is important that DSNs NOT be issued by both the MTA (to report successful delivery to the list), and the list (to report message rejection using a "failure" DSN.)
注意：某些邮件列表可以根据邮件内容、发件人地址或其他标准拒绝邮件提交。虽然此类邮件列表与其MTA之间的接口尚未明确定义，但重要的是，MTA（向列表报告成功传递）和列表（使用“失败”DSN报告邮件拒绝）均不得发布DSN
However, even if a "delivered" DSN was issued by the MTA, a mailing list which rejects a message submission MAY notify the sender that the message was rejected using an ordinary message instead of a DSN.
但是，即使MTA发出了“已送达”的DSN，拒绝邮件提交的邮件列表也可能会通知发件人该邮件是使用普通邮件而不是DSN拒绝的。
Whenever a message is redistributed to an mailing list,
每当邮件重新分发到邮件列表时，
(a) The envelope return address is rewritten to point to the list maintainer. This address MAY be that of a process that recognizes DSNs and processes them automatically, but it MUST forward unrecognized messages to the human responsible for the list.
(a) 信封返回地址被重写为指向列表维护者。此地址可能是识别DSN并自动处理它们的进程的地址，但它必须将无法识别的消息转发给负责列表的人员。
(b) The ENVID, NOTIFY, RET, and ORCPT parameters which accompany the redistributed message MUST NOT be derived from those of the original message.
(b) 重新分发的消息附带的ENVID、NOTIFY、RET和ORCPT参数不得从原始消息的参数派生。
(c) The NOTIFY and RET parameters MAY be specified by the local postmaster or the list administrator. If ORCPT parameters are supplied during redistribution to the list subscribers, they SHOULD contain the addresses of the list subscribers in the format used by the mailing list.
(c) NOTIFY和RET参数可由本地邮政局长或列表管理员指定。如果ORCPT参数是在重新分发给列表订阅者的过程中提供的，则这些参数应以邮件列表使用的格式包含列表订阅者的地址。
Under normal circumstances, when a message arrives for an "alias" which has a single forwarding address, a DSN SHOULD NOT be issued. Any ENVID, NOTIFY, RET, or ORCPT parameters SHOULD be propagated with the message as it is redistributed to the forwarding address.
在正常情况下，当具有单个转发地址的“别名”的消息到达时，不应发出DSN。任何ENVID、NOTIFY、RET或ORCPT参数都应在消息重新分发到转发地址时随消息一起传播。
An "alias" with multiple recipient addresses may be handled in any of the following ways:
具有多个收件人地址的“别名”可通过以下任一方式处理：
(a) Any ENVID, NOTIFY, RET, or ORCPT parameters are NOT propagated when relaying the message to any of the forwarding addresses. If the NOTIFY parameter for the alias contained the SUCCESS keyword, the MTA issues a "relayed" DSN. (In effect, the MTA treats the message as if it were being relayed into an environment that does not support DSNs.)
(a) 将消息中继到任何转发地址时，不会传播任何ENVID、NOTIFY、RET或ORCPT参数。如果别名的NOTIFY参数包含SUCCESS关键字，MTA将发出“中继”DSN。（实际上，MTA将邮件视为转发到不支持DSN的环境中。）
(b) Any ENVID, NOTIFY, RET, or ORCPT parameters (or the equivalent requests if the message is gatewayed) are propagated to EXACTLY one of the forwarding addresses. No DSN is issued. (This is appropriate when aliasing is used to forward a message to a "vacation" auto-responder program in addition to the local mailbox.)
(b) 任何ENVID、NOTIFY、RET或ORCPT参数（或消息网关化时的等效请求）都会传播到一个转发地址。未发布DSN。（当使用别名将邮件转发到本地邮箱之外的“休假”自动响应程序时，这是合适的。）
(c) Any ENVID, RET, or ORCPT parameters are propagated to all forwarding addresses associated with that alias. The NOTIFY parameter is propagated to the forwarding addresses, except that it any SUCCESS keyword is removed. If the original NOTIFY parameter for the alias contained the SUCCESS keyword, an "expanded" DSN is issued for the alias. If the NOTIFY parameter for the alias did not contain the SUCCESS keyword, no DSN is issued for the alias.
(c) 任何ENVID、RET或ORCPT参数都会传播到与该别名关联的所有转发地址。NOTIFY参数将传播到转发地址，除非它删除了任何SUCCESS关键字。如果别名的原始NOTIFY参数包含SUCCESS关键字，则会为别名发出“扩展”DSN。如果别名的NOTIFY参数不包含SUCCESS关键字，则不会为别名发出DSN。
If it is desired to maintain the confidentiality of a recipient's forwarding address, the forwarding may be treated as if it were a mailing list. A DSN will be issued, if appropriate, upon "delivery" to the recipient address specified by the sender. When the message is forwarded it will have a new envelope return address. Any DSNs which result from delivery failure of the forwarded message will not be returned to the original sender of the message and thus not expose the recipient's forwarding address.
如果希望保持收件人转发地址的机密性，可以将转发视为邮件列表。如果合适，DSN将在“交付”到发件人指定的收件人地址时发出。当邮件被转发时，它将有一个新的信封返回地址。由于转发邮件的传递失败而导致的任何DSN都不会返回给邮件的原始发件人，因此不会公开收件人的转发地址。
A single DSN may describe attempts to deliver a message to multiple recipients of that message. If a DSN is issued for some recipients in an SMTP transaction and not for others according to the rules above, the DSN SHOULD NOT contain information for recipients for whom DSNs would not otherwise have been issued.
单个DSN可以描述将消息传递给该消息的多个收件人的尝试。如果在SMTP事务中为某些收件人而不是根据上述规则为其他收件人发出DSN，则DSN不应包含不会为其发出DSN的收件人的信息。
For messages which originated from "local" users (whatever that means), the specifications under which DSNs should be generated can be communicated to the MTA via any protocol agreed on between the sender's mail composer (user agent) and the MTA. The local MTA can then either relay the message, or issue appropriate delivery status notifications. However, if such requests are transmitted within the message itself (for example in the message headers), the requests MUST be removed from the message before it is transmitted via SMTP.
对于来自“本地”用户的邮件（无论是什么意思），可以通过发件人的邮件生成器（用户代理）和MTA之间商定的任何协议将生成DSN的规范传达给MTA。然后，本地MTA可以中继邮件，或发出相应的传递状态通知。但是，如果此类请求在邮件本身内传输（例如在邮件标题中），则在通过SMTP传输之前，必须从邮件中删除这些请求。
For messages gatewayed from non-SMTP sources and further relayed by SMTP, the gateway SHOULD, using the SMTP extensions described here, attempt to provide the delivery reporting conditions expected by the source mail environment. If appropriate, any DSNs returned to the source environment SHOULD be translated into the format expected in that environment.
对于从非SMTP源通过网关传送并由SMTP进一步中继的邮件，网关应使用此处描述的SMTP扩展，尝试提供源邮件环境预期的传递报告条件。如果合适，任何返回到源环境的DSN都应转换为该环境中预期的格式。
A conforming MTA MUST accept ESMTP parameters of at least the following sizes:
合格MTA必须接受至少以下尺寸的ESMTP参数：
(a) ENVID parameter: 100 characters.
(a) ENVID参数：100个字符。
(b) NOTIFY parameter: 28 characters.
(b) 通知参数：28个字符。
(c) ORCPT parameter: 500 characters.
(c) ORCPT参数：500个字符。
(d) RET parameter: 8 characters.
(d) RET参数：8个字符。
The maximum sizes for the ENVID and ORCPT parameters are intended to be adequate for the transmission of "foreign" envelope identifier and original recipient addresses. However, user agents which use SMTP as a message submission protocol SHOULD NOT generate ENVID parameters which are longer than 38 characters in length.
ENVID和ORCPT参数的最大大小应足以传输“外来”信封标识符和原始收件人地址。但是，使用SMTP作为邮件提交协议的用户代理不应生成长度超过38个字符的ENVID参数。
A conforming MTA MUST be able to accept SMTP command-lines which are at least 1036 characters long (530 characters for the ORCPT and NOTIFY parameters of the RCPT command, in addition to the 512
合格的MTA必须能够接受长度至少为1036个字符（ORCPT为530个字符）的SMTP命令行，并通知RCPT命令的参数，以及512个字符
characters required by [1]). If other SMTP extensions are supported by the MTA, the MTA MUST be able to accept a command-line large enough for each SMTP command and any combination of ESMTP parameters which may be used with that command.
[1]所需的字符。如果MTA支持其他SMTP扩展，则MTA必须能够接受足够大的命令行，以容纳每个SMTP命令以及可能与该命令一起使用的任何ESMTP参数组合。
The format of Delivery Status Notifications is defined in [3], which uses the framework defined in [5]. Delivery Status Notifications are to be returned to the sender of the original message as outlined below.
[3]中定义了交付状态通知的格式，它使用了[5]中定义的框架。传递状态通知将返回给原始邮件的发件人，如下所述。
The DSN sender address (in the SMTP MAIL command) MUST be a null reverse-path ("<>"), as required by section 5.3.3 of [11]. The DSN recipient address (in the RCPT command) is copied from the MAIL command which accompanied the message for which the DSN is being issued. When transmitting a DSN via SMTP, the RET parameter MUST NOT be used. The NOTIFY parameter MAY be used, but its value MUST be NEVER. The ENVID parameter (with a newly generated envelope-id) and/or ORCPT parameter MAY be used.
根据[11]第5.3.3节的要求，DSN发件人地址（在SMTP邮件命令中）必须为空反向路径（“<>”）。DSN收件人地址（在RCPT命令中）从为其发出DSN的邮件附带的MAIL命令中复制。通过SMTP传输DSN时，不得使用RET参数。可以使用NOTIFY参数，但其值不能为空。可以使用ENVID参数（具有新生成的信封id）和/或ORCPT参数。
A DSN is transmitted as a MIME message with a top-level content-type of multipart/report (as defined in [3]).
DSN作为MIME消息传输，其顶级内容类型为多部分/报告（如[3]中所定义）。
The multipart/report content-type may be used for any of several kinds of reports generated by the mail system. When multipart/report is used to convey a DSN, the report-type parameter of the multipart/report content-type is "delivery-status".
多部分/报告内容类型可用于邮件系统生成的多种报告中的任何一种。当使用multipart/report传递DSN时，multipart/report内容类型的report type参数为“delivery status”。
As described in [5], the first component of a multipart/report content-type is a human readable explanation of the report. For a DSN, the second component of the multipart/report is of content-type message/delivery-status (defined in [3]). The third component of the multipart/report consists of the original message or some portion thereof. When the value of the RET parameter is FULL, the full message SHOULD be returned for any DSN which conveys notification of delivery failure. (However, if the length of the message is greater than some implementation-specified length, the MTA MAY return only the headers even if the RET parameter specified FULL.) If a DSN contains no notifications of delivery failure, the MTA SHOULD return only the headers.
如[5]所述，多部分/报告内容类型的第一个组件是报告的可读解释。对于DSN，多部分/报告的第二个组件为内容类型消息/传递状态（定义见[3]）。多部分/报告的第三个组件由原始消息或其部分组成。当RET参数的值为FULL时，对于传递传递传递失败通知的任何DSN，都应返回FULL消息。（但是，如果邮件长度大于某个实现指定的长度，则MTA可能仅返回邮件头，即使RET参数已指定为FULL。）如果DSN不包含传递失败通知，MTA应仅返回邮件头。
The third component must have an appropriate content-type label. Issues concerning selection of the content-type are discussed in [5].
第三个组件必须具有适当的内容类型标签。[5]中讨论了有关内容类型选择的问题。
The message/delivery-status content-type defines a number of fields, with general specifications for their contents. The following requirements for any DSNs generated in response to a message received by the SMTP protocol by a conforming SMTP server, are in addition to the requirements defined in [3] for the message/delivery-status type.
message/delivery status内容类型定义了许多字段，并对其内容进行了一般规范。除了[3]中定义的邮件/传递状态类型的要求外，以下要求是对符合SMTP协议的SMTP服务器接收到的邮件的响应而生成的任何DSN的要求。
When generating a DSN for a message which was received via the SMTP protocol, a conforming MTA will generate the following fields of the message/delivery-status body part:
为通过SMTP协议接收的邮件生成DSN时，一致性MTA将生成邮件/传递状态正文部分的以下字段：
(a) if an ENVID parameter was present on the MAIL command, an Original-Envelope-ID field MUST be supplied, and the value associated with the ENVID parameter must appear in that field. If the message was received via SMTP with no ENVID parameter, the Original-Envelope-ID field MUST NOT be supplied.
(a) 如果MAIL命令中存在ENVID参数，则必须提供原始信封ID字段，并且与ENVID参数关联的值必须出现在该字段中。如果通过SMTP接收的邮件没有ENVID参数，则不能提供原始信封ID字段。
Since the ENVID parameter is encoded as xtext, but the Original-Envelope-ID header is NOT encoded as xtext, the MTA must decode the xtext encoding when copying the ENVID value to the Original-Envelope-ID field.
由于ENVID参数编码为xtext，但原始信封ID标头未编码为xtext，因此MTA在将ENVID值复制到原始信封ID字段时必须解码xtext编码。
(b) The Reporting-MTA field MUST be supplied. If Reporting MTA can determine its fully-qualified Internet domain name, the MTA-name-type subfield MUST be "dns", and the field MUST contain the fully-qualified domain name of the Reporting MTA. If the fully-qualified Internet domain name of the Reporting MTA is not known (for example, for an SMTP server which is not directly connected to the Internet), the Reporting-MTA field may contain any string identifying the MTA, however, in this case the MTA-name-type subfield MUST NOT be "dns". A MTA-name-type subfield value of "x-local-hostname" is suggested.
(b) 必须提供报告MTA字段。如果报告MTA可以确定其完全限定的Internet域名，则MTA名称类型子字段必须为“dns”，并且该字段必须包含报告MTA的完全限定域名。如果报告MTA的完全限定Internet域名未知（例如，对于未直接连接到Internet的SMTP服务器），则报告MTA字段可能包含标识MTA的任何字符串，但在这种情况下，MTA名称类型子字段不得为“dns”。建议MTA名称类型子字段值为“x-local-hostname”。
(c) Other per-message fields as defined in [3] MAY be supplied as appropriate.
(c) 可酌情提供[3]中定义的其他每消息字段。
(d) If the ORCPT parameter was provided for this recipient, the Original-Recipient field MUST be supplied, with its value taken from the ORCPT parameter. If no ORCPT parameter was provided for this recipient, the Original-Recipient field MUST NOT appear.
(d) 如果为此收件人提供了ORCPT参数，则必须提供原始收件人字段，其值取自ORCPT参数。如果未为此收件人提供ORCPT参数，则不得显示原始收件人字段。
(e) The Final-Recipient field MUST be supplied. It MUST contain the recipient address from the message envelope. If the message was received via SMTP, the address-type will be "rfc822".
(e) 必须提供最终收件人字段。它必须包含邮件信封中的收件人地址。如果邮件是通过SMTP接收的，则地址类型将为“rfc822”。
(f) The Action field MUST be supplied.
(f) 必须提供操作字段。
(g) The Status field MUST be supplied, using a status-code from [6]. If there is no specific code which suitably describes a delivery failure, either 4.0.0 (temporary failure), or 5.0.0 (permanent failure) MUST be used.
(g) 必须使用[6]中的状态代码提供状态字段。如果没有适当描述交付故障的特定代码，则必须使用4.0.0（临时故障）或5.0.0（永久故障）。
(h) For DSNs resulting from attempts to relay a message to one or more recipients via SMTP, the Remote-MTA field MUST be supplied for each of those recipients. The mta-name-type subfields of those Remote-MTA fields will be "dns".
(h) 对于试图通过SMTP将邮件中继到一个或多个收件人而产生的DSN，必须为每个收件人提供“远程MTA”字段。这些远程mta字段的mta名称类型子字段将为“dns”。
(i) For DSNs resulting from attempts to relay a message to one or more recipients via SMTP, the Diagnostic-Code MUST be supplied for each of those recipients. The diagnostic-type subfield will be "smtp". See section 9.2 of this document for a description of the "smtp" diagnostic-code.
(i) 对于试图通过SMTP将邮件中继到一个或多个收件人而产生的DSN，必须为每个收件人提供诊断代码。诊断类型子字段将为“smtp”。有关“smtp”诊断代码的说明，请参阅本文档第9.2节。
(j) For DSNs resulting from attempts to relay a message to one or more recipients via SMTP, an SMTP-Remote-Recipient extension field MAY be supplied for each recipient, which contains the address of that recipient which was presented to the remote SMTP server.
(j) 对于因尝试通过SMTP将邮件中继到一个或多个收件人而产生的DSN，可以为每个收件人提供SMTP远程收件人扩展字段，其中包含显示给远程SMTP服务器的该收件人的地址。
(k) Other per-recipient fields defined in [3] MAY appear, as appropriate.
(k) 可能会出现[3]中定义的其他每个收件人字段（视情况而定）。
The author wishes to thank Eric Allman, Harald Alvestrand, Jim Conklin, Bryan Costales, Peter Cowen, Dave Crocker, Roger Fajman, Ned Freed, Marko Kaittola, Steve Kille, John Klensin, Anastasios Kotsikonas, John Gardiner Myers, Julian Onions, Jacob Palme, Marshall Rose, Greg Vaudreuil, and Klaus Weide for their suggestions for improvement of this document.
作者希望感谢埃里克·奥尔曼、哈拉尔德·阿尔维斯特朗、吉姆·康克林、布莱恩·科斯塔尔斯、彼得·考恩、戴夫·克罗克、罗杰·法曼、内德·弗里德、马尔科·凯特拉、史蒂夫·基勒、约翰·克林森、阿纳斯塔西奥斯·科茨科纳斯、约翰·加德纳·迈尔斯、朱利安·奥尼斯、雅各布·帕尔梅、马歇尔·罗斯、格雷格·沃德鲁伊、，以及Klaus Weide对本文件的改进建议。
The SMTP extension described in this document does not change the fundamental nature of the SMTP service and hence does not create any new security exposures in and of itself. It necessarily adds complexity to implementations, however, and with added complexity comes an increased risk of implementation errors.
本文档中描述的SMTP扩展不会改变SMTP服务的基本性质，因此不会在其内部和自身创建任何新的安全暴露。然而，这必然会增加实现的复杂性，随着复杂性的增加，实现错误的风险也随之增加。
Previous ad-hoc delivery notification mechanisms sometimes produced a storm of receipts due to unanticipated interactions with mailing list expansion software. In this specification notification of successful delivery is carefully designed so, if properly implemented, it cannot interact with a list expander in this way.
由于与邮件列表扩展软件的意外交互，以前的即席交付通知机制有时会产生大量收据。在本规范中，成功交付的通知是经过精心设计的，因此，如果正确实现，它将无法以这种方式与列表扩展器交互。
The security considerations section in [5] describes security issues associated with multipart/report objects in general and the security considerations section in [3] describes security issues with DSNs in particular.
[5]中的“安全注意事项”部分描述了与多部分/报表对象相关的一般安全问题，[3]中的“安全注意事项”部分特别描述了与DSN相关的安全问题。
The following type names are defined for use in DSN fields generated by conforming SMTP-based MTAs:
定义了以下类型名称，以便在符合标准的基于SMTP的MTA生成的DSN字段中使用：
The "rfc822" address-type is to be used when reporting Internet electronic mail address in the Original-Recipient and Final-Recipient DSN fields.
在原始收件人和最终收件人DSN字段中报告Internet电子邮件地址时，将使用“rfc822”地址类型。
(a) address-type name: rfc822
(a) 地址类型名称：rfc822
(b) syntax for mailbox addresses
(b) 邮箱地址的语法
RFC822 mailbox addresses are generally expected to be of the form
RFC822邮箱地址通常应为
[route] addr-spec
[路线]地址规格
where "route" and "addr-spec" are defined in [2], and the "domain" portions of both "route" and "addr-spec" are fully-qualified domain names that are registered in the DNS. However, an MTA MUST NOT modify an address obtained from the message envelope to force it to conform to syntax rules.
其中[2]中定义了“路由”和“地址规范”，并且“路由”和“地址规范”的“域”部分都是在DNS中注册的完全限定域名。但是，MTA不得修改从邮件信封获取的地址，以强制其符合语法规则。
(c) If addresses of this type 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 DSN Original-Recipient or Final-Recipient DSN field.
(c) 如果此类地址不完全由US-ASCII指令表中的图形字符组成，则说明如何在DSN原始收件人或最终收件人DSN字段中将其编码为图形US-ASCII字符。
RFC822 addresses consist entirely of graphic characters from the US-ASCII repertoire, so no translation is necessary.
RFC822地址完全由US-ASCII指令表中的图形字符组成，因此无需翻译。
The "smtp" diagnostic-type is to be used when reporting SMTP reply-codes in Diagnostic-Code DSN fields.
在诊断代码DSN字段中报告smtp回复代码时，将使用“smtp”诊断类型。
(a) diagnostic-type name: SMTP
(a) 诊断类型名称：SMTP
(b) A description of the syntax to be used for expressing diagnostic codes of this type as graphic characters from the US-ASCII repertoire.
(b) 用于将此类诊断代码表示为US-ASCII指令表中图形字符的语法说明。
An SMTP diagnostic-code is of the form
SMTP诊断代码的格式为
*( 3*DIGIT "-" *text ) 3*DIGIT SPACE *text
*( 3*DIGIT "-" *text ) 3*DIGIT SPACE *text
For a single-line SMTP reply to an SMTP command, the diagnostic-code SHOULD be an exact transcription of the reply. For multi-line SMTP replies, it is necessary to insert a SPACE before each line after the first. For example, an SMTP reply of:
对于SMTP命令的单行SMTP回复，诊断代码应为回复的精确转录。对于多行SMTP回复，必须在第一行之后的每行之前插入空格。例如，SMTP答复为：
550-mailbox unavailable 550 user has moved with no forwarding address
550邮箱不可用550用户已移动，但没有转发地址
could appear as follows in a Diagnostic-Code DSN field:
可能在诊断代码DSN字段中显示如下：
Diagnostic-Code: smtp ; 550-mailbox unavailable 550 user has moved with no forwarding address
诊断代码：smtp；550邮箱不可用550用户已移动，但没有转发地址
(c) A list of valid diagnostic codes of this type and the meaning of each code.
(c) 此类型的有效诊断代码列表以及每个代码的含义。
SMTP reply-codes are currently defined in [1] and [11]. Additional codes may be defined by other RFCs.
SMTP回复代码当前在[1]和[11]中定义。其他代码可由其他RFC定义。
The "dns" MTA-name-type should be used in the Reporting-MTA field. An MTA-name of type "dns" is a fully-qualified domain name. The name must be registered in the DNS, and the address Postmaster@{mta-name} must be valid.
报告MTA字段中应使用“dns”MTA名称类型。类型为“dns”的MTA名称是完全限定的域名。该名称必须在DNS中注册，并且地址Postmaster@{mta name}必须有效。
(a) MTA-name-type name: dns
(a) MTA名称类型名称：dns
(b) A description of the syntax of MTA names of this type, using BNF, regular expressions, ASN.1, or other non-ambiguous language.
(b) 此类型MTA名称的语法说明，使用BNF、正则表达式、ASN.1或其他非歧义语言。
MTA names of type "dns" SHOULD be valid Internet domain names. If such domain names are not available, a domain-literal containing the internet protocol address is acceptable. Such domain names generally conform to the following syntax:
类型为“dns”的MTA名称应为有效的Internet域名。如果此类域名不可用，则可接受包含internet协议地址的域文字。此类域名通常符合以下语法：
domain = real-domain / domain-literal
domain = real-domain / domain-literal
real-domain = sub-domain *("." sub-domain)
实域=子域*（“”子域）
sub-domain = atom
sub-domain = atom
domain-literal = "[" 1*3DIGIT 3("." 1*3DIGIT) "]"
domain-literal = "[" 1*3DIGIT 3("." 1*3DIGIT) "]"
where "atom" and "DIGIT" are defined in [2].
其中，在[2]中定义了“原子”和“数字”。
(c) If MTA names of this type do not consist entirely of graphic characters from the US-ASCII repertoire, a specification for how an MTA name of this type should be expressed as a sequence of graphic US-ASCII characters.
(c) 如果此类型的MTA名称不完全由US-ASCII指令表中的图形字符组成，则说明如何将此类型的MTA名称表示为图形US-ASCII字符序列。
MTA names of type "dns" consist entirely of graphic US-ASCII characters, so no translation is needed.
类型为“dns”的MTA名称完全由图形US-ASCII字符组成，因此不需要翻译。
This example traces the flow of a single message addressed to multiple recipients. The message is sent by Alice@Example.ORG to Bob@Example.COM, Carol@Ivory.EDU, Dana@Ivory.EDU, Eric@Bombs.AF.MIL, Fred@Bombs.AF.MIL, and George@Tax-ME.GOV, with a variety of per-recipient options. The message is successfully delivered to Bob, Dana (via a gateway), Eric, and Fred. Delivery fails for Carol and George.
此示例跟踪发送给多个收件人的单个邮件的流程。这条消息是通过电子邮件发送的Alice@Example.ORG到Bob@Example.COM, Carol@Ivory.EDU, Dana@Ivory.EDU, Eric@Bombs.AF.MIL, Fred@Bombs.AF.MIL和George@Tax-ME.GOV，每个收件人有多种选择。消息已成功传递给Bob、Dana（通过网关）、Eric和Fred。卡罗尔和乔治的送货失败了。
NOTE: Formatting rules for RFCs require that no line be longer than 72 characters. Therefore, in the following examples, some SMTP commands longer than 72 characters are printed on two lines, with the first line ending in "\". In an actual SMTP transaction, such a command would be sent as a single line (i.e., with no embedded CRLFs), and without the "\" character that appears in these examples.
注意：RFC的格式规则要求行长度不得超过72个字符。因此，在以下示例中，某些长度超过72个字符的SMTP命令打印在两行上，第一行以“\”结尾。在实际的SMTP事务中，这样的命令将作为单行发送（即，没有嵌入CRLF），并且没有出现在这些示例中的“\”字符。
Alice's user agent sends the message to the SMTP server at Example.ORG. Note that while this example uses SMTP as a mail submission protocol, other protocols could also be used.
Alice的用户代理将消息发送到Example.ORG上的SMTP服务器。请注意，虽然此示例使用SMTP作为邮件提交协议，但也可以使用其他协议。
<<< 220 Example.ORG SMTP server here
>>> EHLO Example.ORG
<<< 250-Example.ORG
<<< 250-DSN
<<< 250-EXPN
<<< 250 SIZE
>>> MAIL FROM:<Alice@Example.ORG> RET=HDRS ENVID=QQ314159
<<< 250 <Alice@Example.ORG> sender ok
>>> RCPT TO:<Bob@Example.COM> NOTIFY=SUCCESS \
ORCPT=rfc822;Bob@Example.COM
<<< 250 <Bob@Example.COM> recipient ok
>>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE \
ORCPT=rfc822;Carol@Ivory.EDU
<<< 250 <Carol@Ivory.EDU> recipient ok
>>> RCPT TO:<Dana@Ivory.EDU> NOTIFY=SUCCESS,FAILURE \
ORCPT=rfc822;Dana@Ivory.EDU
<<< 250 <Dana@Ivory.EDU> recipient ok
>>> RCPT TO:<Eric@Bombs.AF.MIL> NOTIFY=FAILURE \
ORCPT=rfc822;Eric@Bombs.AF.MIL
<<< 250 <Eric@Bombs.AF.MIL> recipient ok
>>> RCPT TO:<Fred@Bombs.AF.MIL> NOTIFY=NEVER
<<< 250 <Fred@Bombs.AF.MIL> recipient ok
>>> RCPT TO:<George@Tax-ME.GOV> NOTIFY=FAILURE \
ORCPT=rfc822;George@Tax-ME.GOV
<<< 250 <George@Tax-ME.GOV> recipient ok
>>> DATA
<<< 354 okay, send message
>>> (message goes here)
>>> .
<<< 250 message accepted
>>> QUIT
<<< 221 goodbye
<<< 220 Example.ORG SMTP server here
>>> EHLO Example.ORG
<<< 250-Example.ORG
<<< 250-DSN
<<< 250-EXPN
<<< 250 SIZE
>>> MAIL FROM:<Alice@Example.ORG> RET=HDRS ENVID=QQ314159
<<< 250 <Alice@Example.ORG> sender ok
>>> RCPT TO:<Bob@Example.COM> NOTIFY=SUCCESS \
ORCPT=rfc822;Bob@Example.COM
<<< 250 <Bob@Example.COM> recipient ok
>>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE \
ORCPT=rfc822;Carol@Ivory.EDU
<<< 250 <Carol@Ivory.EDU> recipient ok
>>> RCPT TO:<Dana@Ivory.EDU> NOTIFY=SUCCESS,FAILURE \
ORCPT=rfc822;Dana@Ivory.EDU
<<< 250 <Dana@Ivory.EDU> recipient ok
>>> RCPT TO:<Eric@Bombs.AF.MIL> NOTIFY=FAILURE \
ORCPT=rfc822;Eric@Bombs.AF.MIL
<<< 250 <Eric@Bombs.AF.MIL> recipient ok
>>> RCPT TO:<Fred@Bombs.AF.MIL> NOTIFY=NEVER
<<< 250 <Fred@Bombs.AF.MIL> recipient ok
>>> RCPT TO:<George@Tax-ME.GOV> NOTIFY=FAILURE \
ORCPT=rfc822;George@Tax-ME.GOV
<<< 250 <George@Tax-ME.GOV> recipient ok
>>> DATA
<<< 354 okay, send message
>>> (message goes here)
>>> .
<<< 250 message accepted
>>> QUIT
<<< 221 goodbye
The SMTP at Example.ORG then relays the message to Example.COM. (For the purpose of this example, mail.Example.COM is the primary mail exchanger for Example.COM).
然后Example.ORG上的SMTP将消息转发到Example.COM。（在本例中，mail.example.COM是example.COM的主邮件交换器）。
<<< 220 mail.Example.COM says hello
>>> EHLO Example.ORG
<<< 250-mail.Example.COM
<<< 250 DSN
>>> MAIL FROM:<Alice@Example.ORG> RET=HDRS ENVID=QQ314159
<<< 250 sender okay
>>> RCPT TO:<Bob@Example.COM> NOTIFY=SUCCESS \
ORCPT=rfc822;Bob@Example.COM
<<< 250 recipient okay
>>> DATA
<<< 354 send message
>>> (message goes here)
>>> .
<<< 250 message received
>>> QUIT
<<< 221 bcnu
<<< 220 mail.Example.COM says hello
>>> EHLO Example.ORG
<<< 250-mail.Example.COM
<<< 250 DSN
>>> MAIL FROM:<Alice@Example.ORG> RET=HDRS ENVID=QQ314159
<<< 250 sender okay
>>> RCPT TO:<Bob@Example.COM> NOTIFY=SUCCESS \
ORCPT=rfc822;Bob@Example.COM
<<< 250 recipient okay
>>> DATA
<<< 354 send message
>>> (message goes here)
>>> .
<<< 250 message received
>>> QUIT
<<< 221 bcnu
The SMTP at Example.ORG relays the message to Ivory.EDU, which (as it happens) is a gateway to a LAN-based mail system that accepts SMTP mail and supports the DSN extension.
Example.ORG上的SMTP将消息转发到Ivory.EDU，它（碰巧）是基于LAN的邮件系统的网关，该系统接受SMTP邮件并支持DSN扩展。
<<< 220 Ivory.EDU gateway to FooMail(tm) here
>>> EHLO Example.ORG
<<< 250-Ivory.EDU
<<< 250 DSN
>>> MAIL FROM:<Alice@Example.ORG> RET=HDRS ENVID=QQ314159
<<< 250 ok
>>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE \
ORCPT=rfc822;Carol@Ivory.EDU
<<< 550 error - no such recipient
>>> RCPT TO:<Dana@Ivory.EDU> NOTIFY=SUCCESS,FAILURE \
ORCPT=rfc822;Dana@Ivory.EDU
<<< 250 recipient ok
>>> DATA
<<< 354 send message, end with '.'
>>> (message goes here)
>>> .
<<< 250 message received
>>> QUIT
<<< 221 bye
<<< 220 Ivory.EDU gateway to FooMail(tm) here
>>> EHLO Example.ORG
<<< 250-Ivory.EDU
<<< 250 DSN
>>> MAIL FROM:<Alice@Example.ORG> RET=HDRS ENVID=QQ314159
<<< 250 ok
>>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE \
ORCPT=rfc822;Carol@Ivory.EDU
<<< 550 error - no such recipient
>>> RCPT TO:<Dana@Ivory.EDU> NOTIFY=SUCCESS,FAILURE \
ORCPT=rfc822;Dana@Ivory.EDU
<<< 250 recipient ok
>>> DATA
<<< 354 send message, end with '.'
>>> (message goes here)
>>> .
<<< 250 message received
>>> QUIT
<<< 221 bye
Note that since the Ivory.EDU refused to accept mail for Carol@Ivory.EDU, and the sender specified NOTIFY=FAILURE, the sender-SMTP (in this case Example.ORG) must generate a DSN.
请注意，由于Ivory.EDU拒绝接受Carol@Ivory.EDU，并且发件人指定的NOTIFY=FAILURE，则发件人SMTP（在本例中为Example.ORG）必须生成DSN。
The SMTP at Example.ORG relays the message to Bombs.AF.MIL, which does not support the SMTP extension. Because the sender specified NOTIFY=NEVER for recipient Fred@Bombs.AF.MIL, the SMTP at Example.ORG chooses to send the message for that recipient in a separate transaction with a reverse-path of <>.
Example.ORG上的SMTP将消息转发到Bombs.AF.MIL，后者不支持SMTP扩展。因为发件人为收件人指定了NOTIFY=NEVERFred@Bombs.AF.MIL，Example.ORG上的SMTP选择在反向路径为<>的单独事务中为该收件人发送邮件。
<<< 220-Bombs.AF.MIL reporting for duty.
<<< 220 Electronic mail is to be used for official business only.
>>> EHLO Example.ORG
<<< 502 command not implemented
>>> RSET
<<< 250 reset
>>> HELO Example.ORG
<<< 250 Bombs.AF.MIL
>>> MAIL FROM:<Alice@Example.ORG>
<<< 250 ok
>>> RCPT TO:<Eric@Bombs.AF.MIL>
<<< 250 ok
>>> DATA
<<< 354 send message
>>> (message goes here)
>>> .
<<< 250 message accepted
>>> MAIL FROM:<>
<<< 250 ok
>>> RCPT TO:<Fred@Bombs.AF.MIL>
<<< 250 ok
>>> DATA
<<< 354 send message
>>> (message goes here)
>>> .
<<< 250 message accepted
>>> QUIT
<<< 221 Bombs.AF.MIL closing connection
<<< 220-Bombs.AF.MIL reporting for duty.
<<< 220 Electronic mail is to be used for official business only.
>>> EHLO Example.ORG
<<< 502 command not implemented
>>> RSET
<<< 250 reset
>>> HELO Example.ORG
<<< 250 Bombs.AF.MIL
>>> MAIL FROM:<Alice@Example.ORG>
<<< 250 ok
>>> RCPT TO:<Eric@Bombs.AF.MIL>
<<< 250 ok
>>> DATA
<<< 354 send message
>>> (message goes here)
>>> .
<<< 250 message accepted
>>> MAIL FROM:<>
<<< 250 ok
>>> RCPT TO:<Fred@Bombs.AF.MIL>
<<< 250 ok
>>> DATA
<<< 354 send message
>>> (message goes here)
>>> .
<<< 250 message accepted
>>> QUIT
<<< 221 Bombs.AF.MIL closing connection
The SMTP at Example.ORG relays the message to Tax-ME.GOV. (this step is not shown). MTA Tax-ME.GOV then forwards the message to Sam@Boondoggle.GOV (shown below). Both Tax-ME.GOV and Example.ORG support the SMTP DSN extension. Note that RET, ENVID, and ORCPT all retain their original values.
Example.ORG上的SMTP将消息转发到Tax-ME.GOV。（未显示此步骤）。MTA Tax-ME.GOV然后将邮件转发至Sam@Boondoggle.GOV（如下所示）。Tax-ME.GOV和Example.ORG都支持SMTP DSN扩展。请注意，RET、ENVID和ORCPT都保留其原始值。
<<< 220 BoonDoggle.GOV says hello
>>> EHLO Example.ORG
<<< 250-mail.Example.COM
<<< 250 DSN
>>> MAIL FROM:<Alice@Example.ORG> RET=HDRS ENVID=QQ314159
<<< 250 sender okay
>>> RCPT TO:<Sam@Boondoggle.GOV> NOTIFY=SUCCESS \
ORCPT=rfc822;George@Tax-ME.GOV
<<< 250 recipient okay
>>> DATA
<<< 354 send message
>>> (message goes here)
>>> .
<<< 250 message received
>>> QUIT
<<< 221 bcnu
<<< 220 BoonDoggle.GOV says hello
>>> EHLO Example.ORG
<<< 250-mail.Example.COM
<<< 250 DSN
>>> MAIL FROM:<Alice@Example.ORG> RET=HDRS ENVID=QQ314159
<<< 250 sender okay
>>> RCPT TO:<Sam@Boondoggle.GOV> NOTIFY=SUCCESS \
ORCPT=rfc822;George@Tax-ME.GOV
<<< 250 recipient okay
>>> DATA
<<< 354 send message
>>> (message goes here)
>>> .
<<< 250 message received
>>> QUIT
<<< 221 bcnu
MTA mail.Example.COM successfully delivers the message to Bob@Example.COM. Because the sender specified NOTIFY=SUCCESS, mail.Example.COM issues the following DSN, and sends it to Alice@Example.ORG.
MTA mail.Example.COM已成功将邮件传递到Bob@Example.COM. 由于发件人指定NOTIFY=SUCCESS，mail.Example.COM会发出以下DSN，并将其发送到Alice@Example.ORG.
To: Alice@Example.ORG
From: postmaster@mail.Example.COM
Subject: Delivery Notification (success) for Bob@Example.COM
Content-Type: multipart/report; report-type=delivery-status;
boundary=abcde
MIME-Version: 1.0
To: Alice@Example.ORG
From: postmaster@mail.Example.COM
Subject: Delivery Notification (success) for Bob@Example.COM
Content-Type: multipart/report; report-type=delivery-status;
boundary=abcde
MIME-Version: 1.0
--abcde
Content-type: text/plain; charset=us-ascii
--abcde
Content-type: text/plain; charset=us-ascii
Your message (id QQ314159) was successfully delivered to Bob@Example.COM.
您的邮件（id QQ14159）已成功送达Bob@Example.COM.
--abcde Content-type: message/delivery-status
--abcde内容类型：消息/传递状态
Reporting-MTA: dns; mail.Example.COM Original-Envelope-ID: QQ314159
报告MTA:dns；mail.Example.COM原始信封ID:QQ14159
Original-Recipient: rfc822;Bob@Example.COM
Final-Recipient: rfc822;Bob@Example.COM
Action: delivered
Status: 2.0.0
Original-Recipient: rfc822;Bob@Example.COM
Final-Recipient: rfc822;Bob@Example.COM
Action: delivered
Status: 2.0.0
--abcde Content-type: message/rfc822
--abcde内容类型：消息/rfc822
(headers of returned message go here)
（返回消息的标题位于此处）
--abcde--
--abcde--
Because delivery to Carol failed and the sender specified NOTIFY=FAILURE for Carol@Ivory.EDU, MTA Example.ORG (the SMTP client to which the failure was reported via SMTP) issues the following DSN.
因为向Carol的传递失败，并且发件人指定的NOTIFY=失败Carol@Ivory.EDU，MTA Example.ORG（通过SMTP向其报告故障的SMTP客户端）发出以下DSN。
To: Alice@Example.ORG
From: postmaster@Example.ORG
Subject: Delivery Notification (failure) for Carol@Ivory.EDU
Content-Type: multipart/report; report-type=delivery-status;
boundary=bcdef
MIME-Version: 1.0
To: Alice@Example.ORG
From: postmaster@Example.ORG
Subject: Delivery Notification (failure) for Carol@Ivory.EDU
Content-Type: multipart/report; report-type=delivery-status;
boundary=bcdef
MIME-Version: 1.0
--bcdef
Content-type: text/plain; charset=us-ascii
--bcdef
Content-type: text/plain; charset=us-ascii
Your message (id QQ314159) could not be delivered to Carol@Ivory.EDU.
无法将您的邮件（id QQ14159）传递到Carol@Ivory.EDU.
A transcript of the session follows:
会议记录如下：
(while talking to Ivory.EDU)
>>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE
<<< 550 error - no such recipient
(while talking to Ivory.EDU)
>>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE
<<< 550 error - no such recipient
--bcdef Content-type: message/delivery-status
--bcdef内容类型：邮件/传递状态
Reporting-MTA: dns; Example.ORG Original-Envelope-ID: QQ314159
报告MTA:dns；Example.ORG原始信封ID:QQ14159
Original-Recipient: rfc822;Carol@Ivory.EDU
Final-Recipient: rfc822;Carol@Ivory.EDU
SMTP-Remote-Recipient: Carol@Ivory.EDU
Diagnostic-Code: smtp; 550 error - no such recipient
Action: failed
Status: 5.0.0
Original-Recipient: rfc822;Carol@Ivory.EDU
Final-Recipient: rfc822;Carol@Ivory.EDU
SMTP-Remote-Recipient: Carol@Ivory.EDU
Diagnostic-Code: smtp; 550 error - no such recipient
Action: failed
Status: 5.0.0
--bcdef Content-type: message/rfc822
--bcdef内容类型：消息/rfc822
(headers of returned message go here)
（返回消息的标题位于此处）
--bcdef--
--bcdef--
Although the mail gateway Ivory.EDU supports the DSN SMTP extension, the LAN mail system attached to its other side does not generate positive delivery confirmations. So Ivory.EDU issues a "relayed" DSN:
尽管mail gateway Ivory.EDU支持DSN SMTP扩展，但连接到其另一端的LAN邮件系统不会生成正向传递确认。因此，Ivory.EDU发布了一个“中继”DSN：
To: Alice@Example.ORG
From: postmaster@Ivory.EDU
Subject: mail relayed for Dana@Ivory.EDU
Content-Type: multipart/report; report-type=delivery-status;
boundary=cdefg
MIME-Version: 1.0
To: Alice@Example.ORG
From: postmaster@Ivory.EDU
Subject: mail relayed for Dana@Ivory.EDU
Content-Type: multipart/report; report-type=delivery-status;
boundary=cdefg
MIME-Version: 1.0
--cdefg
Content-type: text/plain; charset=us-ascii
--cdefg
Content-type: text/plain; charset=us-ascii
Your message (addressed to Dana@Ivory.EDU) was successfully relayed to:
你的留言（致Dana@Ivory.EDU)已成功中继到：
ymail!Dana
伊梅尔！达纳
by the FooMail gateway at Ivory.EDU.
通过位于Ivory.EDU的FooMail网关。
Unfortunately, the remote mail system does not support confirmation of actual delivery. Unless delivery to ymail!Dana fails, this will be the only Delivery Status Notification sent.
不幸的是，远程邮件系统不支持确认实际送达。除非交给ymail！Dana失败，这将是唯一发送的传递状态通知。
--cdefg Content-type: message/delivery-status
--cdefg内容类型：消息/传递状态
Reporting-MTA: dns; Ivory.EDU Original-Envelope-ID: QQ314159
报告MTA:dns；Ivory.EDU原始信封ID:QQ14159
Original-Recipient: rfc822;Dana@Ivory.EDU
Final-Recipient: rfc822;Dana@Ivory.EDU
Action: relayed
Status: 2.0.0
Original-Recipient: rfc822;Dana@Ivory.EDU
Final-Recipient: rfc822;Dana@Ivory.EDU
Action: relayed
Status: 2.0.0
--cdefg Content-type: message/rfc822
--cdefg内容类型：消息/rfc822
(headers of returned message go here)
（返回消息的标题位于此处）
--cdefg--
--cdefg--
The message originally addressed to George@Tax-ME.GOV was forwarded to Sam@Boondoggle.GOV, but the MTA for Boondoggle.GOV was unable to deliver the message due to a lack of disk space in Sam's mailbox. After trying for several days, Boondoggle.GOV returned the following DSN:
这封信原本是写给George@Tax-ME.GOV已转发至Sam@Boondoggle.GOV，但Boondogle.GOV的MTA无法发送邮件，因为Sam的邮箱中缺少磁盘空间。在尝试了几天后，Boondogle.GOV返回了以下DSN：
To: Alice@Example.ORG
From: Postmaster@Boondoggle.GOV
Subject: Delivery failure for Sam@Boondoggle.GOV
Content-Type: multipart/report; report-type=delivery-status;
boundary=defgh
MIME-Version: 1.0
To: Alice@Example.ORG
From: Postmaster@Boondoggle.GOV
Subject: Delivery failure for Sam@Boondoggle.GOV
Content-Type: multipart/report; report-type=delivery-status;
boundary=defgh
MIME-Version: 1.0
--defgh Your message, originally addressed to George@Tax-ME.GOV, and forwarded from there to Sam@Boondoggle.GOV could not be delivered, for the following reason:
--删除您的邮件，原收件人：George@Tax-ME.GOV，并从那里转发到Sam@Boondoggle.GOV无法交付，原因如下：
write error to mailbox, disk quota exceeded
向邮箱写入错误，超过磁盘配额
--defgh Content-type: message/delivery-status
--定义内容类型：消息/传递状态
Reporting-MTA: Boondoggle.GOV Original-Envelope-ID: QQ314159
报告MTA:Boondoggle.GOV原始信封ID:QQ14159
Original-Recipient: rfc822;George@Tax-ME.GOV
Final-Recipient: rfc822;Sam@Boondoggle.GOV
Action: failed
Status: 4.2.2 (disk quota exceeded)
Original-Recipient: rfc822;George@Tax-ME.GOV
Final-Recipient: rfc822;Sam@Boondoggle.GOV
Action: failed
Status: 4.2.2 (disk quota exceeded)
--defgh Content-type: message/rfc822
--定义内容类型：消息/rfc822
(headers of returned message go here)
（返回消息的标题位于此处）
--defgh--
--德夫--
- updated author's address
- 更新作者地址
- In examples, changed Pure-Heart.ORG and Big-Bucks.COM to Example.ORG and Example.COM, respectively. Since publication of RFC 1891, the former two domains have been registered.
- 在示例中，将Pure-Heart.ORG和Big-Bucks.COM分别更改为Example.ORG和Example.COM。自RFC1891出版以来，前两个域名已经注册。
- Clarified that ENVID and ORCPT parameters must consist entirely of US-ASCII characters prior to encoding as xtext.
- 阐明在编码为xtext之前，ENVID和ORCPT参数必须完全由US-ASCII字符组成。
- A Security Considerations section was added.
- 增加了安全注意事项部分。
[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] Moore, K., and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[3] Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 3464，2003年1月。
[4] Coded Character Set - 7-Bit American Standard Code for Information Interchange, ANSI X3.4-1986.
[4] 编码字符集.信息交换用7位美国标准代码，ANSI X3.4-1986。
[5] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.
[5] Vaudreuil，G.“邮件系统管理消息报告的多部分/报告内容类型”，RFC 3462，2003年1月。
[6] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[6] Vaudreuil，G.，“增强型邮件系统状态代码”，RFC 3463，2003年1月。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[8] Westine, A. and J. Postel, "Problems with the Maintenance of Large Mailing Lists.", RFC 1211, March 1991.
[8] Westine，A.和J.Postel，“维护大型邮件列表的问题”，RFC 12111991年3月。
[9] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996.
[9] Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 2060，1996年12月。
[10] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[10] Myers，J.和M.Rose，“邮局协议-第3版”，STD 53，RFC 1939，1996年5月。
[11] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[11] Braden，R.，Ed.“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
Keith Moore University of Tennessee 1122 Volunteer Blvd, Suite 203 Knoxville, TN 37996-3450 USA
基思穆尔田纳西大学1122志愿BLVD，套房203诺克斯维尔，TN 37 963-3550美国
EMail: moore@cs.utk.edu
EMail: moore@cs.utk.edu
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。