非官方中文译本声明：本页为 IETF RFC 3461《Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)》 的非官方中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布、不受版权限制；依据 BCP 78，本译本为署名翻译作品，译文力求忠实但不构成官方版本，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc3461。

RFC 3461《DSN 的 SMTP 服务扩展》中文译本

IETF · RFC 3461 · 标准跟踪（Standards Track）· 2003 年 1 月

摘要（Abstract）

本备忘录定义了简单邮件传输协议（SMTP）服务的一项扩展，它允许 SMTP 客户端指定：(a) 应当在何种条件下生成投递状态通知（Delivery Status Notification，DSN）；(b) 此类通知是否应当返回消息的内容；以及 (c) 随 DSN 一同返回的附加信息，使发送方既能识别出该 DSN 是为哪些收件人签发的，也能识别出原始消息是在哪一次事务中发送的。

本文档废止（Obsoletes）RFC 1891。

术语（Terminology）

本文档中的关键词 "MUST"（必须）、"MUST NOT"（不得）、"REQUIRED"（需要）、"SHALL"（应）、"SHALL NOT"（不应）、"SHOULD"（应当）、"SHOULD NOT"（不应）、"RECOMMENDED"（推荐）、"MAY"（可以）和 "OPTIONAL"（可选）应按照 BCP 14、RFC 2119 [7] 中的描述进行解释。

1. 引言

SMTP 协议 [1] 要求：如果 SMTP 服务器确定某条消息无法投递给一个或多个收件人，它必须提供投递失败的通知。传统上，此类通知由一封普通的互联网邮件消息（格式由 [2] 定义）构成，被发送到信封发件人地址（即 SMTP MAIL 命令的参数），其中包含对该错误的说明，以及至少失败消息的信头。

大型邮件分发列表的实践经验 [8] 表明，此类消息往往不足以诊断问题，甚至不足以判定问题发生在哪台主机上、或是针对哪些收件人发生的。此外，互联网邮件中缺少一种标准化的投递通知格式，这使得与其他消息处理系统交换此类通知变得困难。

这些经验说明，互联网电子邮件需要一种投递状态通知服务，它应当：

可靠：任何 DSN 请求要么在最终投递时得到满足，要么导致一个表明该请求无法被满足的响应；
当同时请求成功通知与失败通知时，能够就消息向某收件人的投递究竟是成功还是失败，给出明确且不相互冲突的指示；
稳定：投递某个 DSN 的失败尝试绝不应导致又一个 DSN 在网络上传输；
保留足够的信息，使发送方既能识别引发该通知的邮件事务，也能识别引发该通知的收件人地址，即便邮件被转发或网关转送到外部（foreign）环境时亦然；以及
能够与非 SMTP、非基于 RFC 822 的邮件系统进行可接受的对接，从而既使从外部邮件系统返回的通知对互联网用户有用，也使来自外部环境的通知请求能够得到满足。该目标所隐含的要求之中，包括请求「不回送内容」（non-return-of-content）的能力，以及指定应当签发肯定投递通知、否定投递通知、两者皆签发还是两者皆不签发的能力。

为尝试提供这样一种服务，本备忘录使用 [1] 中定义的机制来定义 SMTP 协议的一项扩展。借助该机制，SMTP 客户端可以请求 SMTP 服务器在特定条件下签发或不签发投递状态通知（DSN）。DSN 的格式在 [3] 中定义。

2. 投递状态通知扩展的框架

因此，定义如下服务扩展：

该 SMTP 服务扩展的名称为 "Delivery Status Notification"（投递状态通知）；
与该扩展关联的 EHLO 关键词值为 "DSN"，其含义在本备忘录第 3 节中定义；
该 EHLO 关键词值不允许携带任何参数；
为 RCPT 命令新增两个可选参数，为 MAIL 命令新增两个可选参数：
RCPT 命令的一个可选参数，使用 esmtp-keyword "NOTIFY"（用于指定应当在何种条件下生成投递状态通知），在第 5.1 节中定义；

RCPT 命令的一个可选参数，使用 esmtp-keyword "ORCPT"（用于传递「原始」的（由发送方指定的）收件人地址），在第 5.2 节中定义；以及

MAIL 命令的一个可选参数，使用 esmtp-keyword "RET"（用于请求：含有投递失败指示的 DSN 究竟返回消息的全部内容，还是仅返回消息信头），在第 5.3 节中定义；

MAIL 命令的一个可选参数，使用 esmtp-keyword "ENVID"（用于传播本次消息传输信封的一个标识符，该标识符同时为发送方所知，且若存在，将在为本次传输签发的任何 DSN 中被返回），在第 4.4 节中定义；
该扩展不定义任何额外的 SMTP 动词（verb）。

本备忘录的其余部分规定了对该扩展的支持将如何影响消息传输代理（MTA）的行为。

3. 投递状态通知服务扩展

希望为某条消息请求 DSN 的 SMTP 客户端，可以签发 EHLO 命令来开启一次 SMTP 会话，以判定服务器是否支持若干服务扩展中的某一种。如果服务器以 250 应答码响应 EHLO 命令，且响应中包含 EHLO 关键词 DSN，则表明支持投递状态通知扩展（如本备忘录所述）。

通常，当 SMTP 服务器对 RCPT 命令返回肯定（2xx）应答码时，即表示它同意承担如下责任：要么把消息投递给所指定的收件人，要么向该消息的发送方发送一条表明投递已失败的通知。然而，实现了本服务扩展的扩展 SMTP（"ESMTP"）服务器将接受 RCPT 命令上的可选 NOTIFY 参数。若该参数存在，NOTIFY 参数会改变生成投递状态通知的条件，使其不同于 [1] 中规定的默认行为（仅在失败时签发通知）。ESMTP 客户端还可以（通过 RET 参数）请求：随 DSN 一同返回的，是原始消息的全部内容，还是仅其信头。

一般而言，实现了本服务扩展的 ESMTP 服务器，在向同样支持该扩展的其他基于 SMTP 的 MTA 中继邮件时，会传播投递状态通知请求；而当消息被传入其他环境时，则会尽「最大努力」（best effort）确保此类请求得到满足。

为使投递状态通知对发送方有意义，支持该扩展的 ESMTP 服务器应当把下列信息传播给用于中继该消息的任何其他 MTA，以便生成 DSN：

对每个收件人，提供一份原始收件人地址的副本，即发送方所使用的那个地址。

该地址不必与 RCPT 命令中指定的邮箱相同。例如，若某消息最初寄给 A@B.C，随后被转发到 A@D.E，那么在此类转发发生之后，RCPT 命令将指定邮箱 A@D.E；然而，原始收件人地址仍然是 A@B.C。

此外，如果该消息源自一个不使用互联网风格 user@domain 地址的环境，并被网关转送到 SMTP，那么原始收件人地址将保留收件人地址的原始形式。
对整个 SMTP 事务，提供一个信封标识字符串（envelope identification string），发送方可用它把任何投递状态通知与用于发送原始消息的那次事务关联起来。

4. RCPT 与 MAIL 命令的附加参数

当客户端希望在特定条件下、针对某个特定收件人向服务器请求 DSN 时，就会签发扩展的 RCPT 与 MAIL 命令。扩展的 RCPT 与 MAIL 命令与 [1] 中定义的 RCPT 与 MAIL 命令完全相同，区别仅在于：在发件人地址或收件人地址之后，分别出现下列参数中的一个或多个。扩展 SMTP 命令的通用语法在 [1] 中定义。

注意：虽然此处使用 RFC 822 的 ABNF 来描述这些参数的语法，但按该文档的说法，它们并不是「结构化字段体」（structured field bodies）。因此，尽管圆括号可以（MAY）出现在 esmtp-value 之中，它们并不会被识别为注释定界符。

[1] 中 "esmtp-value" 的语法不允许在 esmtp-value 中传输 SP、"="、控制字符，以及传统 ASCII 范围（十进制 1–127）之外的字符。由于 ENVID 与 ORCPT 参数可能需要传递该范围之外的值，这两个参数的 esmtp-value 被编码为 "xtext"。"xtext" 的形式化定义如下：

   xtext = *( xchar / hexchar )

   xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive,
           except for "+" and "=".

   ; "hexchar"s are intended to encode octets that cannot appear
   ; as ASCII characters within an esmtp-value.

   hexchar = ASCII "+" immediately followed by two upper case
             hexadecimal digits

当把一个八位位组序列编码为 xtext 时：

介于 "!" 与 "~" 之间（含两端）的任何 ASCII CHAR，除 "+" 与 "=" 之外，可以（MAY）按其本身编码。（由实现者自行决定，该范围内的 CHAR 也可以改为编码为 "hexchar"。）
落在上述范围之外的 ASCII CHAR 必须编码为 "hexchar"。

4.1 ESMTP RCPT 命令的 NOTIFY 参数

客户端签发的 RCPT 命令可以包含可选的 esmtp-keyword "NOTIFY"，用于指定 SMTP 服务器应当在何种条件下为该收件人生成 DSN。如果使用了 NOTIFY 这一 esmtp-keyword，它必须（MUST）带有一个关联的 esmtp-value，并按照下列规则、使用 RFC 822 的 ABNF 进行格式化：

   notify-esmtp-value = "NEVER" / 1#notify-list-element

   notify-list-element = "SUCCESS" / "FAILURE" / "DELAY"

注：

NOTIFY 参数中可以（MAY）出现多个以逗号分隔的 notify-list-element；但 NEVER 关键词必须（MUST）单独出现。
关键词 NEVER、SUCCESS、FAILURE 或 DELAY 中的任何一个，都可以用大小写字母的任意组合来拼写。

NOTIFY 参数取值的含义大体如下：

NOTIFY 参数值为 "NEVER" 时，请求在任何条件下都不要向发送方返回 DSN。
NOTIFY 参数值中包含 "SUCCESS" 或 "FAILURE" 关键词时，分别请求在投递成功或投递失败时签发 DSN。
NOTIFY 参数值中包含关键词 "DELAY" 时，表明发送方愿意接收「延迟」（delayed）类 DSN。当某条消息的投递被延迟了异常长的时间（由消息被延迟处所在的 MTA 判定），而最终投递状态（无论成功还是失败）尚无法确定时，可以签发延迟类 DSN。NOTIFY 参数中缺少 DELAY 关键词，即请求在任何条件下都不要签发「延迟」类 DSN。

实际支配 NOTIFY 参数解释方式的规则，在第 6 节中给出。

为与不使用 NOTIFY 机制的 SMTP 客户端保持兼容，RCPT 命令中缺少 NOTIFY 参数时，可以被解释为 NOTIFY=FAILURE 或 NOTIFY=FAILURE,DELAY。

4.2 ESMTP RCPT 命令的 ORCPT 参数

RCPT 命令的 ORCPT 这一 esmtp-keyword 用于指定一个「原始」收件人地址，它对应于消息将要投递到的那个实际收件人。如果使用了 ORCPT 这一 esmtp-keyword，它必须（MUST）带有一个关联的 esmtp-value，该值由原始收件人地址构成，并按下述规则编码。ORCPT 参数的 ABNF 为：

   orcpt-parameter = "ORCPT=" original-recipient-address

   original-recipient-address = addr-type ";" xtext

   addr-type = atom

其中 "addr-type" 部分必须（MUST）是一个已在 IANA 注册的电子邮件地址类型（address-type，定义见 [3]），而 "xtext" 部分则包含按本文档第 5 节的规则对原始收件人地址所作的编码表示。整个 ORCPT 参数的长度可以（MAY）达到 500 个字符。

在通过 SMTP 首次提交消息时，若使用了 ORCPT 参数，它必须（MUST）包含与 RCPT TO 地址相同的地址（与 RCPT TO 地址不同的是，ORCPT 参数将被编码为 xtext）。同样，当某个邮件列表通过 SMTP 提交消息以分发给列表订阅者时，若使用了 ORCPT，则 ORCPT 参数必须（MUST）与每个收件人新的 RCPT TO 地址相匹配，而不是与该消息原始发送方所指定的地址相匹配。

original-recipient-address 的 "addr-type" 部分用于指明出现在 ORCPT 参数值中的地址的「类型」。然而，与 ORCPT 关键词关联的地址并不被强制要求符合该 "addr-type" 的语法规则。

理想情况下，original-recipient-address 的 "xtext" 部分应当以编码形式包含发送方用来指定收件人的那同一串字符。然而，对于从某个环境（例如 X.400）网关转送而来、其收件人地址并非简单可打印字符串的消息，收件人地址的表示形式必须由一份关于「在 DSN 与该环境之间进行网关转送」的规范来定义。

由于投递状态通知格式的限制，原始收件人地址在被编码为 "xtext" 之前的取值，必须（MUST）完全由 US-ASCII [4] 字符集中的可打印字符（图形字符与空白字符）构成。如果为使用该字符集之外字符的地址定义了某个 addr-type，则该 addr-type 的规范必须（MUST）定义：如何先把这些地址编码为可打印的 US-ASCII 字符，然后再编码为 xtext。

4.3 ESMTP MAIL 命令的 RET 参数

扩展 MAIL 命令上的 RET 这一 esmtp-keyword 用于指定：在为本次消息传输签发的任何失败类 DSN 中，是否应当包含该消息本身。如果使用了 RET 这一 esmtp-keyword，它必须（MUST）带有一个关联的 esmtp-value，其取值为下列关键词之一：

FULL：请求在为该收件人签发的任何「失败」（failed）投递状态通知中返回整条消息。
HDRS：请求仅返回该消息的信头。

FULL 与 HDRS 关键词可以用大小写字母的任意组合来拼写。

如果未提供 RET 参数，则对于任何含有投递失败指示的 DSN，MTA 可以（MAY）返回该消息的信头，也可以返回整条消息。

请注意，RET 参数仅适用于那些指示至少一个收件人投递失败的 DSN。如果某个 DSN 不含任何投递失败的指示，则应当仅返回该消息的信头。

4.4 ESMTP MAIL 命令的 ENVID 参数

SMTP MAIL 命令的 ENVID 这一 esmtp-keyword 用于指定一个「信封标识符」（envelope identifier），它将随消息一同传输，并被包含在为本次 SMTP 事务中所指定的任一收件人签发的任何 DSN 之中。信封标识符的用途，是让消息的发送方能够识别出该 DSN 是为哪一次事务签发的。

ENVID 参数的 ABNF 为：

   envid-parameter = "ENVID=" xtext

ENVID 这一 esmtp-keyword 必须（MUST）带有一个关联的 esmtp-value。邮件系统不会为该参数的存在与否、也不会为与该参数关联的任何 esmtp-value 赋予任何含义；这些信息仅供发送方或其用户代理使用。ENVID 参数的长度可以（MAY）达到 100 个字符。

由于投递状态通知格式的限制，ENVID 参数在被编码为 "xtext" 之前的取值，必须（MUST）完全由 US-ASCII [4] 字符集中的可打印字符（图形字符与空白字符）构成。

4.5 对投递状态通知参数使用的限制

在任何单个 MAIL 命令中，RET 与 ENVID 参数各自不得（MUST NOT）出现一次以上。如果某个 MAIL 命令中这两个参数中的任何一个出现了多次，ESMTP 服务器应当（SHOULD）以 "501 syntax error in parameters or arguments"（参数或实参语法错误）作出响应。

在任何 RCPT 命令中，NOTIFY 与 ORCPT 参数不得（MUST NOT）出现一次以上。如果某个 RCPT 命令中这两个参数中的任何一个出现了多次，ESMTP 服务器应当（SHOULD）以 "501 syntax error in parameters or arguments" 作出响应。

5. 一致性要求

消息传输代理（MTA）在接收、中继或网关转送邮件时会使用简单邮件传输协议（SMTP）；用户代理（UA）在向邮件传输系统提交邮件时同样会使用它。SMTP 的 DSN 扩展可用于让 UA 传达发送方关于「何时应当签发 DSN」的请求。声称符合本规范的 UA 必须满足下文所述的若干要求。

通常，支持 SMTP 的消息传输代理（MTA）会在不同时刻同时承担 SMTP 客户端与 SMTP 服务器两种角色，并且还可能提供本地投递、向外部环境的网关转送、转发以及邮件列表展开等功能。若某个 MTA 在充当 SMTP 服务器时，在对 EHLO 命令的响应中给出了 DSN 关键词，则它在充当客户端时必须（MUST）遵守下文关于「符合规范的 SMTP 客户端」的规则，在充当服务器时必须（MUST）遵守下文关于「符合规范的 SMTP 服务器」的规则。术语「符合规范的 MTA」（conforming MTA）指的是符合本规范的 MTA，与其充当客户端还是服务器的角色无关。

5.1 SMTP 协议交互

下列规则适用于使用了 ENVID、NOTIFY、RET 或 ORCPT 中任一关键词的 SMTP 事务：

如果 SMTP 客户端签发的 MAIL 命令中含有有效的 ENVID 参数及其关联的 esmtp-value，和／或有效的 RET 参数及其关联的 esmtp-value，则符合规范的 SMTP 服务器必须（MUST）返回与「同一条不带 ENVID 和／或 RET 参数的 MAIL 命令」相同的应答码。符合规范的 SMTP 服务器不得（MUST NOT）因有效的 ENVID 或 RET 参数存在与否、或因其关联的 esmtp-value 而拒绝某条 MAIL 命令。

然而，如果关联的 esmtp-value 无效（即含有非法字符），或者某条 MAIL 命令中出现了多个 ENVID 或 RET 参数，则服务器必须（MUST）签发应答码 501 并附上恰当的说明（例如 "syntax error in parameter"，参数语法错误）。
如果 SMTP 客户端签发的 RCPT 命令中含有任何有效的 NOTIFY 和／或 ORCPT 参数，则符合规范的 SMTP 服务器必须（MUST）返回与「同一条不带这些 NOTIFY 和／或 ORCPT 参数的 RCPT 命令」相同的响应。符合规范的 SMTP 服务器不得（MUST NOT）因这些参数中任何一个的存在与否而拒绝某条 RCPT 命令。

然而，如果任何关联的 esmtp-value 无效，或者某条 RCPT 命令中这些参数中的任何一个出现了多次，则服务器应当（SHOULD）签发响应 "501 syntax error in parameter"。

5.2 对经由 SMTP 接收的消息的处理

本节描述符合规范的 MTA 应当如何处理经由 SMTP 接收到的各类消息。

注意：对于 SMTP MAIL 命令中回信地址为 NULL（"<>"）的任何消息，不得（MUST NOT）向发送方返回 DSN，即便发送方地址可以从其他来源（例如消息信头）获得也是如此。不过，本应签发 DSN 的那个 MTA 应当（SHOULD）通过某种恰当的、其本身不会导致再生成 DSN 的机制，把投递失败的情况告知本地 postmaster。

讨论：RFC 1123 第 2.3.3 节要求错误通知须以 NULL 回信地址（"reverse-path"）发送。当一条消息在带有不可用回信地址的同时，还带有一个或多个不可用的收件人地址时，就会出现一种有趣的情形。当向其中某个收件人地址的投递失败时，MTA 会尝试向回信地址发送一封投递失败通知，并把该通知的回信地址设为 NULL。当这封通知的投递也失败时，试图投递该通知的 MTA 看到的是一个 NULL 回信地址。若该 MTA 不把这一情况告知任何人，原始消息就会被悄无声息地丢失。此外，不可用的回信地址往往意味着发送方 MTA 存在配置问题。把该状况报告给本地 postmaster，有助于加快此类错误的纠正。

5.2.1 向其他符合规范的 SMTP 服务器中继消息

当符合规范的 MTA 把一条经由 SMTP 协议接收到的消息，中继给某台支持投递状态通知服务扩展的 SMTP 服务器时，其行为受下列规则支配：

接收该消息时 MAIL 命令中所含的任何 ENVID 参数，必须（MUST）同样出现在中继该消息所用的 MAIL 命令中，且带有相同的关联 esmtp-value。如果接收该消息时 MAIL 命令中未含 ENVID 参数，则中继该消息时不得（MUST NOT）提供 ENVID 参数。
接收该消息时 MAIL 命令中所含的任何 RET 参数，必须（MUST）同样出现在中继该消息所用的 MAIL 命令中，且带有相同的关联 esmtp-value。如果接收该消息时 MAIL 命令中未含 RET 参数，则中继该消息时不得（MUST NOT）提供 RET 参数。
如果接收该消息时为某个收件人提供了 NOTIFY 参数，则中继该消息时所签发的 RCPT 命令必须（MUST）同样含有 NOTIFY 参数及其关联的 esmtp-value。如果接收该消息时未为某个收件人提供 NOTIFY 参数，则中继该消息时不得（MUST NOT）为该收件人提供 NOTIFY 参数。
如果接收该消息时，某个收件人的 RCPT 命令中存在任何 ORCPT 参数，则中继该消息时为该收件人签发的 RCPT 命令中，必须（MUST）出现一个带有完全相同 original-recipient-address 的 ORCPT 参数。（例如，因此 MTA 不得（MUST NOT）改变 ORCPT 参数中任何字母字符的大小写。）

如果接收该消息时 RCPT 命令中不存在 ORCPT 参数，则中继该消息时可以（MAY）向 RCPT 命令添加一个 ORCPT 参数。如果由中继的 MTA 添加了 ORCPT 参数，它必须（MUST）包含该 MTA 接收此消息时所用 RCPT 命令中的收件人地址。

5.2.2 向不符合规范的 SMTP 服务器中继消息

当符合规范的 MTA（充当客户端角色）把一条经由 SMTP 协议接收到的消息，中继给某台不支持投递状态通知服务扩展的 SMTP 服务器时，其行为受下列规则支配：

中继该消息时不得（MUST NOT）签发 ENVID、NOTIFY、RET 或 ORCPT 参数。
如果为某个收件人提供了 NOTIFY 参数、其 esmtp-value 含有关键词 SUCCESS，且 SMTP 服务器对 RCPT 命令返回了成功（2xx）应答码，则客户端必须（MUST）为该收件人签发一个「已中继」（relayed）类 DSN。
如果为某个收件人提供了 NOTIFY 参数、其 esmtp-value 含有关键词 FAILURE，且 SMTP 服务器对 RCPT 命令返回了永久失败（5xx）应答码，则客户端必须（MUST）为该收件人签发一个「失败」（failed）类 DSN。
如果为某个收件人提供了 esmtp-value 为 NEVER 的 NOTIFY 参数，则无论 SMTP 服务器返回何种应答码，客户端不得（MUST NOT）为该收件人签发 DSN。不过，如果服务器返回了失败（5xx）应答码，客户端可以（MAY）通过某种恰当的、其本身不会导致生成 DSN 的机制，把该投递失败告知本地 postmaster。

当试图把消息中继给不支持本扩展的 SMTP 服务器，且该消息的某些收件人被指定了 NOTIFY=NEVER 时，符合规范的 SMTP 客户端可以（MAY）在一次单独的 SMTP 事务中为这些收件人中继该消息，并在 MAIL 命令中使用空的反向路径（reverse-path）。这样可以防止符合 [1] 的 MTA 为这些收件人签发 DSN。
如果未为某个收件人提供 NOTIFY 参数，且 SMTP 服务器对 RCPT 命令返回了成功（2xx）应答码，则客户端不得（MUST NOT）为该收件人签发任何 DSN。
如果未为某个收件人提供 NOTIFY 参数，且 SMTP 服务器对 RCPT 命令返回了永久失败（5xx）应答码，则客户端必须（MUST）为该收件人签发一个「失败」类 DSN。

5.2.3 消息的本地投递

当符合规范的 MTA 成功把一条经由 SMTP 协议接收到的消息投递到本地收件人的邮箱时，其行为受下列规则支配：

「投递」（delivery）意味着消息已被放入收件人的邮箱。对于那些被传输到某个邮箱、以供之后经由 IMAP [9]、POP [10] 或类似消息访问协议取回的消息而言，「投递」发生在该消息可为 IMAP（POP 等）服务所取用之时，而不是发生在收件人的用户代理取回该消息之时。

同样，对于对应某个邮件列表展开器（list exploder）的收件人地址而言，「投递」发生在该消息可为该列表展开器所取用之时，即便该列表展开器随后可能拒绝把这条消息投递给列表收件人。

如果为该收件人提供了 NOTIFY 参数、且其 esmtp-value 含有 SUCCESS 关键词，则 MTA 必须（MUST）为该收件人签发一个「已投递」（delivered）类 DSN。
如果为该收件人提供了 NOTIFY 参数、但其中不含 SUCCESS 关键词，则 MTA 不得（MUST NOT）为该收件人签发 DSN。
如果未为该收件人提供 NOTIFY 参数，则 MTA 不得（MUST NOT）签发 DSN。

5.2.4 把消息网关转送到外部环境

当符合规范的 MTA 把一条经由 SMTP 协议接收到的消息，网关转送到某个外部（非 SMTP）环境时，其行为受下列规则支配：

如果该外部环境有能力在 NOTIFY 参数所请求的条件下签发恰当的通知，并且符合规范的 MTA 能够确保由此签发的任何通知都将被转换为 DSN 并投递给原始发送方，那么该 MTA 应当（SHOULD）把消息网关转送到该外部环境、并按所需条件请求通知，而其自身不签发 DSN。
如果提供了带 SUCCESS 关键词的 NOTIFY 参数，但目的环境无法在投递成功时返回恰当的通知，则 MTA 应当（SHOULD）为该收件人签发一个「已中继」类 DSN。
如果提供了 esmtp-keyword 为 NEVER 的 NOTIFY 参数，则不得（MUST NOT）签发 DSN。如有可能，MTA 应当（SHOULD）指示目的环境不要为该收件人签发投递通知。
如果未为某个特定收件人提供 NOTIFY 参数，则网关不应（SHOULD NOT）签发 DSN。网关应当（SHOULD）尽力确保：若最终发生投递失败，外部邮件环境将提供恰当的通知；而在投递成功时不会签发任何通知。
当把消息网关转送到外部环境时，任何 RET 参数所指定的「回送内容」条件都不具有约束力；不过，MTA 应当（SHOULD）设法利用该外部环境中现有的任何机制来满足该请求。

5.2.5 投递中的延迟

如果符合规范的 MTA 经由 SMTP 协议收到一条消息，并在一段较长时间内（时长由该 MTA 判定）无法把该消息投递或中继给一个或多个收件人，则它可以（MAY）为这些收件人签发一个「延迟」（delayed）类 DSN，但须满足下列条件：

如果为某个收件人提供了 NOTIFY 参数、且其取值中包含 DELAY 关键词，则可以（MAY）签发「延迟」类 DSN。
如果未为某个收件人提供 NOTIFY 参数，则可以（MAY）签发「延迟」类 DSN。
如果提供了不含 DELAY 关键词的 NOTIFY 参数，则不得（MUST NOT）签发「延迟」类 DSN。

注意：尽管延迟通知在当今的电子邮件中十分常见，但符合规范的 MTA 从来没有被要求必须签发「延迟」类 DSN。提供 NOTIFY 参数的 DELAY 关键词，是为了让 SMTP 客户端能够（通过省略 DELAY 参数）明确请求不要签发「延迟」类 DSN。

5.2.6 符合规范的 MTA 投递消息失败

当符合规范的 MTA 经由 SMTP 协议收到一条消息，却无法把该消息投递给 SMTP 事务中所指定的某个收件人时，其行为受下列规则支配：

如果为该收件人提供了 NOTIFY 参数、且其 esmtp-keyword 中含有取值 FAILURE，则该 MTA 必须（MUST）签发一个「失败」类 DSN。
如果为该收件人提供了 NOTIFY 参数、但其中不含取值 FAILURE，则不得（MUST NOT）为该收件人签发 DSN。不过，该 MTA 可以（MAY）通过某种恰当的、其本身不会导致生成 DSN 的机制，把该投递失败告知本地 postmaster。
如果未为该收件人提供 NOTIFY 参数，则必须（MUST）签发一个「失败」类 DSN。

注意：已知有些 MTA 会把无法投递的消息转发给本地 postmaster 或「死信」（dead letter）邮箱。这仍然被视为投递失败，并不减损本备忘录别处所定义条件下「必须签发『失败』类 DSN」的要求。如果为此类收件人签发了 DSN，则 Action 值必须（MUST）为 "failed"。

5.2.7 转发、别名与邮件列表

把消息投递到某个本地电子邮件地址，通常会导致该消息被存入收件人的邮箱。然而，MTA 普遍提供这样一种功能：可以把某个本地电子邮件地址指定为「别名」（alias）或「邮件列表」（mailing list）；此时向该地址的投递会导致消息被转发给与该别名或列表关联的每一个（本地或远程）收件人地址。此外，允许用户可选地把自己的邮件「转发」到一个或多个备用地址，也是常见做法。若启用了该功能，她的邮件将被重新分发到这些地址，而不再存入她的邮箱。

参照 [11]（第 5.3.6 节）的做法，本文档对「别名」与「邮件列表」的差别定义如下：当把消息转发到与某个「别名」关联的地址时，信封回信地址（例如 SMTP MAIL FROM）保持不变；然而，当把消息转发到与某个「邮件列表」关联的地址时，信封回信地址会被改为该邮件列表管理员的地址。这会使得因向列表成员投递而产生的 DSN 及其他非投递报告，被发送给列表管理员，而不是原始消息的发送方。

针对别名与邮件列表的 DSN 处理如下：

5.2.7.1 邮件列表

当一条消息被投递到某个列表提交地址（即被放入该列表用于接收来件的邮箱，或被负责把消息重新分发给列表订阅者的进程所接受）时，这即被视为原始消息的最终投递。如果该列表提交地址的 NOTIFY 参数中含有 SUCCESS 关键词，则必须（MUST）向原始消息的发送方返回一个「已投递」类 DSN。

注意：有些邮件列表能够依据消息内容、发送方地址或其他准则来拒绝消息提交。虽然此类邮件列表与其 MTA 之间的接口并没有良好的定义，但重要的是：不要由 MTA（用以报告向列表投递成功）与列表本身（用以以「失败」类 DSN 报告消息被拒）双方都签发 DSN。

不过，即便 MTA 已签发了「已投递」类 DSN，拒绝某次消息提交的邮件列表仍可以（MAY）使用一封普通消息（而非 DSN）来通知发送方该消息已被拒绝。

每当一条消息被重新分发到某个邮件列表时：

信封回信地址会被改写为指向列表维护者。该地址可以（MAY）是某个能够识别 DSN 并自动处理它们的进程的地址，但它必须（MUST）把无法识别的消息转发给负责该列表的人。
随被重新分发的消息一同出现的 ENVID、NOTIFY、RET 与 ORCPT 参数，不得（MUST NOT）由原始消息的相应参数派生而来。
NOTIFY 与 RET 参数可以（MAY）由本地 postmaster 或列表管理员来指定。如果在向列表订阅者重新分发的过程中提供了 ORCPT 参数，则它们应当（SHOULD）以该邮件列表所使用的格式包含列表订阅者的地址。

5.2.7.2 单收件人别名

在正常情况下，当一条消息到达某个只有单一转发地址的「别名」时，不应（SHOULD NOT）签发 DSN。在该消息被重新分发到转发地址的过程中，任何 ENVID、NOTIFY、RET 或 ORCPT 参数都应当（SHOULD）随消息一同传播。

5.2.7.3 多收件人别名

对于带有多个收件人地址的「别名」，可以采用下列任一方式处理：

在把消息中继给任何一个转发地址时，均不传播任何 ENVID、NOTIFY、RET 或 ORCPT 参数。如果该别名的 NOTIFY 参数中含有 SUCCESS 关键词，则 MTA 签发一个「已中继」类 DSN。（实际上，此时 MTA 把该消息视为正被中继进入一个不支持 DSN 的环境。）
把任何 ENVID、NOTIFY、RET 或 ORCPT 参数（若消息被网关转送，则为等效的请求）恰好传播给其中一个转发地址，且不签发任何 DSN。（当别名被用于在本地邮箱之外，把消息额外转发给某个「休假」自动回复程序时，这种做法是恰当的。）
把任何 ENVID、RET 或 ORCPT 参数传播给与该别名关联的所有转发地址。NOTIFY 参数也被传播给这些转发地址，但其中任何 SUCCESS 关键词会被移除。如果该别名原本的 NOTIFY 参数中含有 SUCCESS 关键词，则为该别名签发一个「已展开」（expanded）类 DSN；如果该别名的 NOTIFY 参数中不含 SUCCESS 关键词，则不为该别名签发任何 DSN。

5.2.7.4 保密的转发地址

如果希望对收件人的转发地址保密，可以把该转发按邮件列表的方式来处理。此时，在向发送方所指定的收件人地址完成「投递」时，会（在适当情况下）签发 DSN。当该消息被转发时，它将带有一个新的信封回信地址。因转发后的消息投递失败而产生的任何 DSN，都不会被返回给该消息的原始发送方，从而不会暴露收件人的转发地址。

5.2.8 描述向多个收件人投递的 DSN

单个 DSN 可以描述把某条消息投递给该消息多个收件人的若干次尝试。如果按上述规则，在一次 SMTP 事务中为某些收件人签发了 DSN 而未为另一些收件人签发，则该 DSN 不应（SHOULD NOT）包含那些本来就不会为其签发 DSN 的收件人的信息。

5.3 对来自其他来源的消息的处理

对于源自「本地」用户（无论这意味着什么）的消息，关于应当如何生成 DSN 的规定，可以通过发送方的邮件撰写程序（用户代理）与 MTA 之间约定的任何协议来传达给 MTA。本地 MTA 随后既可以中继该消息，也可以签发恰当的投递状态通知。然而，如果此类请求是在消息内部传输的（例如放在消息信头中），则在该消息经由 SMTP 传输之前，这些请求必须（MUST）从消息中移除。

对于从非 SMTP 来源网关转送而来、并进一步经由 SMTP 中继的消息，网关应当（SHOULD）使用此处所述的 SMTP 扩展，设法提供源邮件环境所期望的投递报告条件。在适当情况下，返回到源环境的任何 DSN 都应当（SHOULD）被转换为该环境所期望的格式。

5.4 实现限制

符合规范的 MTA 必须（MUST）接受至少达到下列大小的 ESMTP 参数：

ENVID 参数：100 个字符。
NOTIFY 参数：28 个字符。
ORCPT 参数：500 个字符。
RET 参数：8 个字符。

ENVID 与 ORCPT 参数的最大长度，意在足以传输「外部」的信封标识符与原始收件人地址。不过，把 SMTP 用作消息提交协议的用户代理，不应（SHOULD NOT）生成长度超过 38 个字符的 ENVID 参数。

符合规范的 MTA 必须（MUST）能够接受长度至少为 1036 个字符的 SMTP 命令行（在 [1] 所要求的 512 个字符之外，再加上 RCPT 命令的 ORCPT 与 NOTIFY 参数所需的 530 个字符）。如果该 MTA 还支持其他 SMTP 扩展，则它必须（MUST）能够接受足以容纳每条 SMTP 命令、以及可与该命令搭配使用的任意 ESMTP 参数组合的命令行长度。

6. 投递通知的格式

投递状态通知的格式在 [3] 中定义，它使用了 [5] 中定义的框架。投递状态通知应按下文所述返回给原始消息的发送方。

6.1 与投递状态通知搭配使用的 SMTP 信封

按照 [11] 第 5.3.3 节的要求，DSN 的发件人地址（位于 SMTP MAIL 命令中）必须（MUST）是空反向路径（"<>"）。DSN 的收件人地址（位于 RCPT 命令中）取自随「被签发 DSN 的那条消息」一同到达的 MAIL 命令。经由 SMTP 传输 DSN 时，不得（MUST NOT）使用 RET 参数；可以（MAY）使用 NOTIFY 参数，但其取值必须（MUST）为 NEVER。ENVID 参数（带有一个新生成的 envelope-id）和／或 ORCPT 参数可以（MAY）使用。

6.2 DSN 的内容

DSN 以一封顶层内容类型为 multipart/report（定义见 [3]）的 MIME 消息形式传输。

multipart/report 内容类型可用于邮件系统生成的多种报告。当用 multipart/report 承载 DSN 时，multipart/report 内容类型的 report-type 参数取值为 "delivery-status"。

如 [5] 所述，multipart/report 内容类型的第一个部分是该报告的人类可读说明。对 DSN 而言，multipart/report 的第二个部分的内容类型为 message/delivery-status（定义见 [3]）。multipart/report 的第三个部分由原始消息或其某一部分构成。当 RET 参数的取值为 FULL 时，对于任何传达投递失败通知的 DSN，都应当（SHOULD）返回完整的消息。（然而，如果消息长度超过某个由实现指定的长度，即便 RET 参数指定了 FULL，MTA 也可以（MAY）仅返回信头。）如果某个 DSN 不含任何投递失败的通知，则 MTA 应当（SHOULD）仅返回信头。

第三个部分必须带有恰当的 content-type 标注。关于如何选择 content-type，[5] 中有相关讨论。

6.3 message/delivery-status 字段

message/delivery-status 内容类型定义了若干字段，并对其内容给出了通用规定。下列针对「符合规范的 SMTP 服务器为经由 SMTP 协议接收的消息所生成的任何 DSN」的要求，是在 [3] 为 message/delivery-status 类型所定义要求之外的附加要求。

当为一条经由 SMTP 协议接收到的消息生成 DSN 时，符合规范的 MTA 将生成 message/delivery-status 正文部分的下列字段：

如果 MAIL 命令中存在 ENVID 参数，则必须（MUST）提供 Original-Envelope-ID 字段，且与 ENVID 参数关联的取值必须出现在该字段中。如果该消息是在没有 ENVID 参数的情况下经由 SMTP 接收的，则不得（MUST NOT）提供 Original-Envelope-ID 字段。

由于 ENVID 参数被编码为 xtext，而 Original-Envelope-ID 信头不作 xtext 编码，因此 MTA 在把 ENVID 值复制到 Original-Envelope-ID 字段时，必须先解码其 xtext 编码。
必须（MUST）提供 Reporting-MTA 字段。如果报告方 MTA 能够确定自己的全限定互联网域名，则 MTA-name-type 子字段必须（MUST）为 "dns"，且该字段必须（MUST）包含该报告方 MTA 的全限定域名。如果报告方 MTA 的全限定互联网域名未知（例如对于未直接连接到互联网的 SMTP 服务器），则 Reporting-MTA 字段可以包含任何用于标识该 MTA 的字符串；但在这种情况下，MTA-name-type 子字段不得（MUST NOT）为 "dns"，建议采用 "x-local-hostname" 作为 MTA-name-type 子字段的取值。
[3] 中定义的其他每消息（per-message）字段可以（MAY）酌情提供。
如果为该收件人提供了 ORCPT 参数，则必须（MUST）提供 Original-Recipient 字段，其取值取自 ORCPT 参数。如果未为该收件人提供 ORCPT 参数，则 Original-Recipient 字段不得（MUST NOT）出现。
必须（MUST）提供 Final-Recipient 字段。它必须（MUST）包含来自消息信封的收件人地址。如果该消息是经由 SMTP 接收的，则 address-type 将为 "rfc822"。
必须（MUST）提供 Action 字段。
必须（MUST）提供 Status 字段，并使用 [6] 中的状态码。如果没有能够恰当描述某次投递失败的具体状态码，则必须（MUST）使用 4.0.0（临时失败）或 5.0.0（永久失败）。
对于因试图经由 SMTP 向一个或多个收件人中继消息而产生的 DSN，必须（MUST）为其中每一个收件人提供 Remote-MTA 字段。这些 Remote-MTA 字段的 mta-name-type 子字段将为 "dns"。
对于因试图经由 SMTP 向一个或多个收件人中继消息而产生的 DSN，必须（MUST）为其中每一个收件人提供 Diagnostic-Code 字段，其 diagnostic-type 子字段将为 "smtp"。关于 "smtp" 类诊断码的说明，参见本文档第 9.2 节。
对于因试图经由 SMTP 向一个或多个收件人中继消息而产生的 DSN，可以（MAY）为每个收件人提供一个 SMTP-Remote-Recipient 扩展字段，其中包含呈现给远端 SMTP 服务器的该收件人地址。
[3] 中定义的其他每收件人（per-recipient）字段可以（MAY）酌情出现。

7. 致谢

作者谨此感谢 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 与 Klaus Weide，感谢他们为改进本文档所提出的建议。

8. 安全考虑

本文档所述的 SMTP 扩展并未改变 SMTP 服务的根本性质，因此其本身不会带来任何新的安全暴露面。不过，它必然会增加实现的复杂度，而复杂度的增加会带来更高的实现错误风险。

以往那些临时性（ad-hoc）的投递通知机制，有时会因与邮件列表展开软件之间未曾预料的相互作用而产生大量回执风暴。在本规范中，成功投递通知经过了审慎设计，只要实现得当，就不会以这种方式与列表展开器发生相互作用。

[5] 的安全考虑一节描述了与 multipart/report 对象总体相关的安全问题；[3] 的安全考虑一节则专门描述了与 DSN 相关的安全问题。

9. 附录 —— 类型名定义

下列类型名被定义用于由符合规范的、基于 SMTP 的 MTA 所生成的 DSN 字段之中：

9.1 "rfc822" 地址类型（address-type）

在 Original-Recipient 与 Final-Recipient 这两个 DSN 字段中报告互联网电子邮件地址时，应使用 "rfc822" 地址类型。

address-type 名称：rfc822
邮箱地址的语法

一般预期 RFC 822 邮箱地址具有如下形式：
```
           [route] addr-spec
```
其中 "route" 与 "addr-spec" 在 [2] 中定义，且 "route" 与 "addr-spec" 两者的 "domain" 部分都是已在 DNS 中注册的全限定域名。然而，MTA 不得（MUST NOT）为了强行使某个从消息信封中取得的地址符合语法规则而修改该地址。
若此类型的地址并非完全由 US-ASCII 字符集中的图形字符构成，则需要一份规范，说明它们在 DSN 的 Original-Recipient 或 Final-Recipient 字段中应如何被编码为图形 US-ASCII 字符。

RFC 822 地址完全由 US-ASCII 字符集中的图形字符构成，因此无需任何转换。

9.2 "smtp" 诊断类型（diagnostic-type）

在 Diagnostic-Code 这一 DSN 字段中报告 SMTP 应答码时，应使用 "smtp" 诊断类型。

diagnostic-type 名称：SMTP
关于「如何以 US-ASCII 字符集中的图形字符表达此类型诊断码」的语法说明。

SMTP 诊断码具有如下形式：
```
           *( 3*DIGIT "-" *text ) 3*DIGIT SPACE *text
```
对于针对某条 SMTP 命令的单行 SMTP 应答，diagnostic-code 应当（SHOULD）是该应答的精确转录。对于多行 SMTP 应答，需要在首行之后的每一行前插入一个 SPACE。例如，如下 SMTP 应答：
```
           550-mailbox unavailable
           550 user has moved with no forwarding address
```
在 Diagnostic-Code 这一 DSN 字段中可以表现为：
```
           Diagnostic-Code: smtp ; 550-mailbox unavailable
            550 user has moved with no forwarding address
```
此类型有效诊断码的列表及各码的含义。

SMTP 应答码目前在 [1] 与 [11] 中定义，其他 RFC 也可能定义额外的应答码。

9.3 "dns" MTA 名类型（MTA-name-type）

Reporting-MTA 字段中应使用 "dns" 这一 MTA-name-type。类型为 "dns" 的 MTA 名是一个全限定域名。该名称必须已在 DNS 中注册，且地址 Postmaster@{mta-name} 必须有效。

MTA-name-type 名称：dns
使用 BNF、正则表达式、ASN.1 或其他无歧义语言对此类型 MTA 名语法的说明。

类型为 "dns" 的 MTA 名应当（SHOULD）是有效的互联网域名。如果没有可用的此类域名，则可以接受一个包含互联网协议地址的 domain-literal。此类域名通常符合下列语法：
```
           domain = real-domain / domain-literal

           real-domain = sub-domain *("." sub-domain)

           sub-domain = atom

           domain-literal = "[" 1*3DIGIT 3("." 1*3DIGIT) "]"
```
其中 "atom" 与 "DIGIT" 在 [2] 中定义。
若此类型的 MTA 名并非完全由 US-ASCII 字符集中的图形字符构成，则需要一份规范，说明此类型的 MTA 名应如何表达为一串图形 US-ASCII 字符。

类型为 "dns" 的 MTA 名完全由图形 US-ASCII 字符构成，因此无需任何转换。

10. 附录 —— 示例

本示例追踪一封寄给多个收件人的消息的流转过程。该消息由 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；对 Carol 与 George 的投递则失败。

注意：RFC 的排版规则要求任何一行都不得超过 72 个字符。因此在下列示例中，某些长度超过 72 个字符的 SMTP 命令被打印为两行，首行以 "\" 结尾。在真实的 SMTP 事务中，此类命令会作为单独一行发送（即不含嵌入的 CRLF），且不含这些示例中出现的 "\" 字符。

10.1 提交

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

10.2 中继到 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

10.3 中继到 Ivory.EDU

Example.ORG 的 SMTP 把该消息中继到 Ivory.EDU，后者（恰好）是通往某个基于局域网的邮件系统的网关，它接受 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

请注意，由于 Ivory.EDU 拒绝接收寄给 Carol@Ivory.EDU 的邮件，而发送方又指定了 NOTIFY=FAILURE，因此发送方 SMTP（此处为 Example.ORG）必须生成一个 DSN。

10.4 中继到 Bombs.AF.MIL

Example.ORG 的 SMTP 把该消息中继到 Bombs.AF.MIL，后者不支持该 SMTP 扩展。由于发送方为收件人 Fred@Bombs.AF.MIL 指定了 NOTIFY=NEVER，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

10.5 从 George@Tax-ME.GOV 转发到 Sam@Boondoggle.GOV

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

10.6 为 Bob@Example.COM 签发的「已投递」DSN

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

   --abcde
   Content-type: text/plain; charset=us-ascii

   Your message (id QQ314159) was successfully delivered to
   Bob@Example.COM.

   --abcde
   Content-type: message/delivery-status

   Reporting-MTA: dns; mail.Example.COM
   Original-Envelope-ID: QQ314159

   Original-Recipient: rfc822;Bob@Example.COM
   Final-Recipient: rfc822;Bob@Example.COM
   Action: delivered
   Status: 2.0.0

   --abcde
   Content-type: message/rfc822

   (headers of returned message go here)

   --abcde--

10.7 为 Carol@Ivory.EDU 签发的「失败」DSN

由于向 Carol 的投递失败，且发送方为 Carol@Ivory.EDU 指定了 NOTIFY=FAILURE，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

   --bcdef
   Content-type: text/plain; charset=us-ascii

   Your message (id QQ314159) could not be delivered to
   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

   --bcdef
   Content-type: message/delivery-status

   Reporting-MTA: dns; Example.ORG
   Original-Envelope-ID: QQ314159

   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

   (headers of returned message go here)

   --bcdef--

10.8 为 Dana@Ivory.EDU 签发的「已中继」DSN

尽管邮件网关 Ivory.EDU 支持 DSN 这一 SMTP 扩展，但连接在其另一侧的局域网邮件系统并不生成肯定投递确认。于是 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

   --cdefg
   Content-type: text/plain; charset=us-ascii

   Your message (addressed to Dana@Ivory.EDU) was successfully
   relayed to:

   ymail!Dana

   by the FooMail gateway at Ivory.EDU.

   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.

   --cdefg
   Content-type: message/delivery-status

   Reporting-MTA: dns; Ivory.EDU
   Original-Envelope-ID: QQ314159

   Original-Recipient: rfc822;Dana@Ivory.EDU
   Final-Recipient: rfc822;Dana@Ivory.EDU
   Action: relayed
   Status: 2.0.0

   --cdefg
   Content-type: message/rfc822

   (headers of returned message go here)

   --cdefg--

10.9 为 Sam@Boondoggle.GOV 签发的失败通知

原本寄给 George@Tax-ME.GOV 的消息被转发到了 Sam@Boondoggle.GOV，但由于 Sam 的邮箱磁盘空间不足，Boondoggle.GOV 的 MTA 未能投递该消息。在尝试数日之后，Boondoggle.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

   --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:

   write error to mailbox, disk quota exceeded

   --defgh
   Content-type: message/delivery-status

   Reporting-MTA: Boondoggle.GOV
   Original-Envelope-ID: QQ314159

   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

   (headers of returned message go here)

   --defgh--

11. 附录 —— 自 RFC 1891 以来的变更

更新了作者地址。
在示例中，把 Pure-Heart.ORG 与 Big-Bucks.COM 分别改为 Example.ORG 与 Example.COM。自 RFC 1891 发布以来，前述两个域名已被注册。
澄清了 ENVID 与 ORCPT 参数在编码为 xtext 之前必须完全由 US-ASCII 字符构成。
新增了「安全考虑」一节。

12. 参考文献

12.1 规范性参考文献

[1] Postel, J., "Simple Mail Transfer Protocol"（简单邮件传输协议）, STD 10, RFC 821, August 1982.
[2] Crocker, D., "Standard for the format of ARPA Internet Text Messages"（ARPA 互联网文本消息格式标准）, STD 11, RFC 822, August 1982.
[3] Moore, K., and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications"（用于投递状态通知的可扩展消息格式）, RFC 3464, January 2003.
[4] Coded Character Set - 7-Bit American Standard Code for Information Interchange（编码字符集 —— 七位美国信息交换标准代码）, ANSI X3.4-1986.
[5] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages"（用于报告邮件系统管理消息的 Multipart/Report 内容类型）, RFC 3462, January 2003.
[6] Vaudreuil, G., "Enhanced Mail System Status Codes"（增强型邮件系统状态码）, RFC 3463, January 2003.
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels"（在 RFC 中用以标示需求级别的关键词）, BCP 14, RFC 2119, March 1997.

12.2 资料性参考文献

[8] Westine, A. and J. Postel, "Problems with the Maintenance of Large Mailing Lists."（大型邮件列表维护中的问题）, RFC 1211, March 1991.
[9] Crispin, M., "Internet Message Access Protocol - Version 4rev1"（互联网消息访问协议 —— 版本 4rev1）, RFC 2060, December 1996.
[10] Myers, J. and M. Rose, "Post Office Protocol - Version 3"（邮局协议 —— 版本 3）, STD 53, RFC 1939, May 1996.
[11] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support"（互联网主机的要求 —— 应用与支持）, STD 3, RFC 1123, October 1989.

13. 作者地址

Keith Moore
University of Tennessee
1122 Volunteer Blvd, Suite 203
Knoxville, TN 37996-3450
USA

EMail: moore@cs.utk.edu

14. 完整版权声明

本文档及其译本可以被复制并提供给他人；对本文档进行评注、以其他方式加以解释，或有助于其实现的派生作品，也可以被全部或部分地准备、复制、出版与分发，不受任何形式的限制，但前提是上述版权声明与本段文字须包含在所有此类副本与派生作品之中。然而，本文档本身不得以任何方式被修改，例如移除版权声明、或移除对互联网协会（Internet Society）及其他互联网组织的引用，除非是出于制定互联网标准的需要（此时必须遵循互联网标准流程中定义的版权处理程序），或是出于将其翻译为英语以外语言的需要。

上述授予的有限许可是永久性的，不会被互联网协会或其继承者或受让方撤销。

本文档及其中所含信息以「按现状」（AS IS）为基础提供，互联网协会与互联网工程任务组不作任何明示或默示的保证，包括但不限于任何关于「使用此处信息不会侵犯任何权利」的保证，以及任何关于适销性或特定用途适用性的默示保证。

鸣谢（Acknowledgement）

RFC 编辑（RFC Editor）职能的经费目前由互联网协会提供。