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

RFC 3464《投递状态通知（DSN）报文格式》中文译本

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

摘要

本备忘录定义了一种多用途互联网邮件扩展（MIME）内容类型，报文传输代理（MTA）或电子邮件网关可以用它来报告向一个或多个收件人投递某份报文的尝试结果。该内容类型旨在成为目前 Internet 电子邮件中所使用的各类投递状态通知的、可由机器处理的替代品。

由于大量报文是在 Internet 与其他消息系统（例如 X.400，或所谓「基于局域网（LAN）」的系统）之间发送的，投递状态通知（DSN）协议被设计为可在多协议的消息环境中使用。为此，本备忘录所描述的协议除了支持 Internet 邮件中通常使用的地址与错误码之外，还支持承载「外部（foreign）」地址与错误码。此外还可以定义附加属性，以支持外部通知经由 Internet 邮件进行「隧道（tunneling）」传递。

1. 引言

本备忘录为投递状态通知（DSN）定义了一种多用途互联网邮件扩展（MIME）[MIME1] 内容类型。DSN 可用于把下列若干情形之一告知报文的发送者：投递失败、投递延迟、投递成功，或者报文被网关送入了某个可能并不支持 DSN 的环境。本文所定义的 "message/delivery-status" 内容类型，旨在用于 [REPORT] 所定义的 "multipart/report" 内容类型的框架之内。

本备忘录只定义通知的格式。为完整支持此类通知而对简单邮件传输协议（SMTP）[SMTP] 所作的扩展，是另一篇备忘录 [DRPT] 的主题。

文档约定

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

1.1 目的

本备忘录所定义的 DSN 预期服务于以下几个目的：

1.2 需求

这些目的对通知协议施加了以下约束：

一份 DSN 包含一组「每报文（per-message）」字段，用以标识该报文以及提交该报文的那次事务，此外还包含适用于该 DSN 所描述的全部投递尝试的其他字段。DSN 还包含一组「每收件人（per-recipient）」字段，用以传达向一个或多个收件人中的每一个投递该报文的尝试结果。

1.3 术语

一份报文在送达收件人的途中，可能会经过若干个报文传输代理（MTA）。出于种种原因，收件人地址在此过程中可能被改写，因此每个 MTA 所看到的收件人地址都可能不同。根据 DSN 的使用目的不同，所需要的某个特定收件人地址的形式也不同。

若干 DSN 字段是以传输链路中某个特定 MTA 的视角来定义的。这些 MTA 被赋予如下名称：

图 1 说明了各类 MTA 之间的关系。

+-----+    +--------+           +---------+    +---------+      +------+
|     |    |        |           |Received-|    |         |      |      |
|     | => |Original| => ... => |  From   | => |Reporting| ===> |Remote|
| user|    |   MTA  |           |   MTA   |    |   MTA   | <No! |  MTA |
|agent|    +--------+           +---------+    +----v----+      +------+
|     |                                             |
|     | <-------------------------------------------+
+-----+      (DSN returned to sender by Reporting MTA)

     Figure 1. Original, Received-From, Reporting and Remote MTAs

上述每一个 MTA 都可能提供在 DSN 中有用的信息：

由于依据 DSN 的使用场合不同，所需要的「收件人地址」与「投递状态码」取值也不同，而发出该 DSN 的 MTA 又无法预知这些场合，因此这里描述的 DSN 格式可以同时包含收件人地址的原始形式与最终形式，以及投递状态的与传输无关的表示和特定于传输的表示。

报告 MTA 还可以按需添加扩展字段，以便为故障工单提供附加信息，或为把外部投递报告通过 Internet DSN 进行隧道传递而保留相关信息。

原始 MTA、报告 MTA 与远端 MTA 可能处于差异很大的环境中，使用互不相同的传输协议、MTA 名称、地址格式与投递状态码。因此，DSN 并不假定邮箱地址、MTA 名称或特定于传输的状态码采用任何特定格式。取而代之的是，承载这些内容的各个 DSN 字段由一个「type（类型）」子字段构成，其后跟随一个内容为普通文本字符的子字段，而后者的格式由该「type」子字段指明。这使得 DSN 能够不受格式限制地传达这些内容。

2. 投递状态通知的格式

一份 DSN 是一封 MIME 报文，其顶层内容类型为 multipart/report（在 [REPORT] 中定义）。当使用 multipart/report 内容来传送一份 DSN 时：

注意：对于由外部系统经网关转换而来的投递状态通知，原始报文的信头可能无法获得。在这种情况下，DSN 的第三个组成部分可以省略，也可以包含载有等效信息的「模拟」RFC 822 信头。尤其值得一提的是，保留原始报文的 subject、date 与 message-id（或其等价物）字段是非常可取的。

DSN 必须（MUST）被寻址（在报文信头与传输信封两处）到「随原始报文一同到达的传输信封中的回信地址」，该原始报文即是生成此 DSN 的那一份报文。（对于经由 SMTP 到达的报文，信封回信地址出现在 MAIL FROM 命令中。）

DSN 报文信头中的 From 字段应当（SHOULD）包含某位负责维护报告 MTA 站点邮件系统的人员的地址（例如 Postmaster），以便对该 DSN 的回复能够送达此人。例外情况：如果某份 DSN 是由外部投递报告翻译而来，且执行翻译的网关无法确定合适的地址，那么该 DSN 的 From 字段可以（MAY）是某位负责维护该网关的人员的地址。

DSN 的信封发件人地址应当（SHOULD）被选取为能够确保不会针对该 DSN 本身再发出任何投递状态报告，并且必须（MUST）被选取为不会使 DSN 造成邮件环路。每当使用 SMTP 事务来发送一份 DSN 时，MAIL FROM 命令必须（MUST）使用 NULL 回信地址，即 "MAIL FROM:<>"。

一份具体的 DSN 恰好描述一份报文的投递状态。不过，一个 MTA 可以（MAY）在单一 DSN 中报告同一份报文的多个收件人的投递状态。由于邮件传输系统的固有特性（把报文投递给其各收件人的责任可能分散在若干个 MTA 之间，且向任何特定收件人的投递都可能被延迟），针对一次报文提交仍有可能发出多份 DSN。

2.1 message/delivery-status 内容类型

message/delivery-status 内容类型定义如下：

MIME type name:             message
MIME subtype name:          delivery-status
Optional parameters:        none
Encoding considerations:    "7bit" encoding is sufficient and
                            MUST be used to maintain readability
                            when viewed by non-MIME mail readers.
Security considerations:    discussed in section 4 of this memo.

（译注：MIME 类型名为 message；MIME 子类型名为 delivery-status；无可选参数；编码方面的考虑是：采用 "7bit" 编码即已足够，并且必须（MUST）使用该编码，以便在非 MIME 邮件阅读器中查看时仍保持可读性；安全方面的考虑在本备忘录第 4 节讨论。）

用于 multipart/report 之中的 message/delivery-status 报告类型（report type）为 "delivery-status"。

message/delivery-status 的主体由一个或多个按照 RFC 822 信头「字段」的 ABNF 格式化的「字段」组成（参见 [RFC822]）。每报文字段首先出现，随后是一个空行。在每报文字段之后是一组或多组每收件人字段。每一组每收件人字段之前都有一个空行。使用 RFC 822 的 ABNF 表示，message/delivery-status 内容的语法如下：

        delivery-status-content =  per-message-fields 1*
                                  ( CRLF per-recipient-fields )

每报文字段在第 2.2 节描述。每收件人字段在第 2.3 节描述。

2.1.1 DSN 字段的一般约定

由于这些字段是按照 RFC 822 的规则定义的，因此续行与注释也适用同样的约定。通知字段可以通过让每一个附加行以一个 SPACE 或 HTAB 开头的方式，续接到多行之上。出现在圆括号中的文本被视为注释，不属于该通知字段内容的一部分。字段名不区分大小写，因此通知字段的名称可以用大小写字母的任意组合书写。DSN 字段中的注释可以使用 [MIME3] 所定义的 "encoded-word" 构造。

2.1.2 "*-type" 子字段

若干 DSN 字段由一个 "-type" 子字段构成，其后跟随一个分号，再跟随 "*text"。对于这些字段，用在 address-type、diagnostic-type 或 MTA-name-type 子字段中的关键字，指明了其后所跟的地址、状态码或 MTA 名称的预期格式。

各 "-type" 子字段定义如下：

(a) "address-type" 指定邮箱地址的格式。例如，Internet 邮件地址使用 "rfc822" address-type。

        address-type = atom

(b) "diagnostic-type" 指定状态码的格式。例如，当某个 DSN 字段包含经由简单邮件传输协议 [SMTP] 报告的应答码时，就使用 "smtp" diagnostic-type。

        diagnostic-type = atom

(c) "MTA-name-type" 指定 MTA 名称的格式。例如，对于 Internet 主机上的 SMTP 服务器，MTA 名称就是该主机的域名，此时使用 "dns" MTA-name-type。

        mta-name-type = atom

address-type、diagnostic-type 与 MTA-name-type 的取值不区分大小写。因此 address-type 取值 "RFC822" 与 "rfc822" 是等价的。

互联网号码分配机构（IANA）将维护一份 address-type、diagnostic-type 与 MTA-name-type 的注册表，其中包含对每一项含义与可接受取值的描述，或者指向提供此类描述的一份或多份规范的引用。（"rfc822" address-type、"smtp" diagnostic-type 与 "dns" MTA-name-type 在 [DRPT] 中定义。）address-type、diagnostic-type 与 MTA-name-type 的注册表格见附录 D。

IANA 不会接受任何以 "X-" 开头的 address-type、diagnostic-type 或 MTA-name-type 名称的注册。这类类型名称保留供实验用途。

2.1.3 自 RFC 822 引入的词法记号

下列在 [RFC822] 中定义的词法记号被用于 DSN 的 ABNF 语法之中：atom、CHAR、comment、CR、CRLF、DIGIT、LF、linear-white-space、SPACE、text。date-time 词法记号在 [HOSTREQ] 中定义。

2.2 每报文 DSN 字段

DSN 的某些字段适用于该 DSN 所描述的全部投递尝试。这些字段在任何一份 DSN 中至多出现一次。它们用于把该 DSN 与原始报文事务相关联，并提供可能对网关有用的附加信息。

       per-message-fields =
             [ original-envelope-id-field CRLF ]
             reporting-mta-field CRLF
             [ dsn-gateway-field CRLF ]
             [ received-from-mta-field CRLF ]
             [ arrival-date-field CRLF ]
             *( extension-field CRLF )

2.2.1 Original-Envelope-Id 字段

可选的 Original-Envelope-Id 字段包含一个「信封标识符（envelope identifier）」，它唯一地标识提交该报文时所处的那次事务，并且要么 (a) 由发送者指定并提供给发送者的 MTA，要么 (b) 由发送者的 MTA 生成，并在报文提交时提供给发送者。其目的是让发送者（或其用户代理）能够把退回的 DSN 与发送该报文的那次特定事务关联起来。

如果在报文到达报告 MTA 时其所附的信封中存在这样一个信封标识符，那么在因尝试投递该报文而发出的任何 DSN 中，都应当（SHOULD）在 Original-Envelope-Id 字段中提供它。除非 DSN 是由发送者的 MTA 发出，否则除非在报文到达报告 MTA 时其所附信封中存在 envelope-identifier 字段，MTA 不得（MUST NOT）提供该字段。

Original-Envelope-Id 字段定义如下：

        original-envelope-id-field =
               "Original-Envelope-Id" ":" envelope-id

         envelope-id = *text

每份 DSN 中至多有一个 Original-Envelope-Id 字段。

envelope-id 是区分大小写的。DSN 必须（MUST）保留 envelope-id 原有的大小写与拼写形式。

注意：Original-Envelope-Id 与报文信头中的 Message-Id 并不相同。Message-Id 标识报文的内容，而 Original-Envelope-Id 标识发送该报文的那次事务。

2.2.2 Reporting-MTA DSN 字段

      reporting-mta-field =
            "Reporting-MTA" ":" mta-name-type ";" mta-name

       mta-name = *text

Reporting-MTA 字段定义如下：

一份 DSN 描述向一个或多个收件人投递、中继或网关转发某报文的尝试结果。在所有情形下，Reporting-MTA 都是尝试执行该 DSN 所述投递、中继或网关转发操作的那个 MTA。此字段是必需的。

请注意，如果某个 SMTP 客户端尝试把报文中继给某个 SMTP 服务器，并收到了对 RCPT 命令的错误应答，那么由该客户端负责生成 DSN，且该客户端的域名将出现在 Reporting-MTA 字段中。（服务器的域名将出现在 Remote-MTA 字段中。）

还请注意，Reporting-MTA 未必就是实际发出该 DSN 的那个 MTA。例如，如果向 Internet 之外投递报文的尝试导致产生了一份非投递通知，而该通知又被网关转发回 Internet 邮件，那么所生成 DSN 的 Reporting-MTA 字段将是最初报告投递失败的那个 MTA，而不是把该外部通知转换为 DSN 的那个网关。参见图 2。

sender's environment                            recipient's environment
............................ ..........................................
                           : :
                       (1) : :                             (2)
  +-----+  +--------+  +--------+  +---------+  +---------+   +------+
  |     |  |        |  |        |  |Received-|  |         |   |      |
  |     |=>|Original|=>|        |->|  From   |->|Reporting|-->|Remote|
  | user|  |   MTA  |  |        |  |   MTA   |  |   MTA   |<No|  MTA |
  |agent|  +--------+  |Gateway |  +---------+  +----v----+   +------+
  |     |              |        |                    |
  |     | <============|        |<-------------------+
  +-----+              |        |(4)                (3)
                       +--------+
                           : :
...........................: :.........................................

             Figure 2. DSNs in the presence of gateways

图 2 中各步骤的含义为：

Reporting-MTA 字段中的 mta-name 部分，按照 mta-name-type 子字段所指明的约定进行格式化。如果某个 MTA 充当互不相同的邮件环境之间的网关，并因此依环境不同而拥有多个名称，那么 mta-name 子字段应当（SHOULD）包含「报告 MTA 接受该报文时所处环境」所使用的那个名称。

由于 MTA 名称的确切拼写在特定环境中可能具有重要意义，MTA 名称是区分大小写的。

2.2.3 DSN-Gateway 字段

DSN-Gateway 字段指明把某份外部（非 Internet）投递状态通知翻译为本 DSN 的那个网关或 MTA 的名称。在任何由网关从外部系统翻译为 DSN 格式的 DSN 中，此字段必须（MUST）出现；在其他情况下则不得（MUST NOT）出现。

   dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name

对于通向 Internet 邮件的网关，MTA-name-type 通常为 "dns"，而 mta-name 则是该网关的 Internet 域名。

2.2.4 Received-From-MTA DSN 字段

可选的 Received-From-MTA 字段指明接收到该报文的来源 MTA 的名称。

     received-from-mta-field =
          "Received-From-MTA" ":" mta-name-type ";" mta-name

如果报文是经由 SMTP 从某个 Internet 主机接收的，那么 mta-name 子字段的内容应当（SHOULD）是 HELO 或 EHLO 命令中所提供的 Internet 域名，并且该 SMTP 客户端所使用的网络地址应当（SHOULD）以圆括号括起的注释形式包含在内。（在这种情况下，MTA-name-type 将为 "dns"。）

Received-From-MTA 字段中的 mta-name 部分，按照 MTA-name-type 子字段所指明的约定进行格式化。

由于在某些邮件系统中大小写具有意义，MTA 名称的确切拼写（包括大小写）应当（SHOULD）予以保留。

2.2.5 Arrival-Date DSN 字段

可选的 Arrival-Date 字段指明报文到达报告 MTA 的日期与时间。如果在每收件人字段中同时提供了 Last-Attempt-Date 字段，就可以用它来确定「报文到达报告 MTA」与「针对该收件人发出报告」这两个时刻之间的间隔。

     arrival-date-field = "Arrival-Date" ":" date-time

日期与时间以 RFC 822 的 'date-time' 格式表示（并按 [HOSTREQ] 所作修改）。必须（MUST）使用数字时区（[+/-]HHMM 格式）。

2.3 每收件人 DSN 字段

一份 DSN 包含关于「向一个或多个收件人投递某报文的尝试」的信息。任何特定收件人的投递信息，都包含在一组连续的每收件人字段中。每一组每收件人字段之前都有一个空行。

每收件人字段组的语法如下：

     per-recipient-fields =
           [ original-recipient-field CRLF ]
           final-recipient-field CRLF
           action-field CRLF
           status-field CRLF
           [ remote-mta-field CRLF ]
           [ diagnostic-code-field CRLF ]
           [ last-attempt-date-field CRLF ]
           [ final-log-id-field CRLF ]
           [ will-retry-until-field CRLF ]
           *( extension-field CRLF )

2.3.1 Original-Recipient 字段

Original-Recipient 字段指明由报文发送者所指定的原始收件人地址，该报文即是发出此 DSN 所针对的那一份。

    original-recipient-field =
          "Original-Recipient" ":" address-type ";" generic-address

     generic-address = *text

address-type 字段指明原始收件人地址的类型。如果报文源自 Internet 之内，address-type 字段通常为 "rfc822"，且该地址将符合 [RFC822] 所规定的语法。如果报告 MTA 无法从报文信封中判定原始收件人地址的类型，则应使用取值 "unknown"。

此字段是可选的。仅当由发送者指定的收件人地址存在于报文信封中时（例如通过 [DRPT] 所定义的 SMTP 扩展），才应包含该字段。此地址与发送者所提供的地址相同，可用于自动关联 DSN 报告与报文事务。

2.3.2 Final-Recipient 字段

Final-Recipient 字段指明本组每收件人字段所适用的那个收件人。此字段必须（MUST）出现在每一组每收件人数据之中。

该字段的语法如下：

      final-recipient-field =
          "Final-Recipient" ":" address-type ";" generic-address

Final-Recipient 字段的 generic-address 子字段必须（MUST）包含该收件人的邮箱地址（取自传输信封），其形式为报告 MTA 接受该报文进行投递时的那个形式。

Final-Recipient 地址可能与发送者最初提供的地址不同，因为它在转发与网关转换过程中可能已被变换得面目全非。然而，在缺少可选的 Original-Recipient 字段的情况下，Final-Recipient 字段以及所退回的内容，可能是把该 DSN 与某次特定报文提交相关联的唯一可用信息。

address-type 子字段指明报告 MTA 在该上下文中所期望的地址类型。经由 SMTP 获得的收件人地址通常为 "rfc822" 这一 address-type。

注意：并不要求报告 MTA 去确保该地址实际符合其 address-type 的语法约定。相反，它必须（MUST）准确报告信封中所收到的地址，除非该地址中含有 CR 或 LF 这类在 DSN 字段中不允许出现的字符。

由于邮箱地址（包括在 Internet 中使用的邮箱地址）可能区分大小写，地址中字母字符的大小写必须（MUST）予以保留。

2.3.3 Action 字段

Action 字段指明报告 MTA 在尝试把报文投递给该收件人地址之后所执行的动作。对于 DSN 中所指名的每一个收件人，此字段必须（MUST）出现。

action-field 的语法为：

   action-field = "Action" ":" action-value

   action-value =
         "failed" / "delayed" / "delivered" / "relayed" / "expanded"

action-value 可以用大小写字符的任意组合书写。

按照 [DRPT] 第 7.2.7 节所定义的「mailing list（邮件列表）」与「alias（别名）」这两个术语：action-value 为 "expanded" 仅应在报文被投递到一个多收件人的「alias」时使用。对于把报文投递到「mailing list」时所发出的 DSN，不应（SHOULD NOT）使用取值为 "expanded" 的 action-value。

关于 action 与 status 码的说明：尽管 'action' 字段看上去似乎与 'status' 字段重复，实则不然。特别地，「临时失败」（"4"）状态码既可以与 "delayed" 的 action-value 搭配，也可以与 "failed" 搭配。例如，假设某个 SMTP 客户端反复尝试把报文中继给某收件人的邮件交换器，但由于对域名服务器的查询超时而失败。几个小时之后，它可能发出一份 "delayed" DSN，告知发送者该报文尚未投递。几天之后，该 MTA 可能放弃投递该报文的尝试，并返回一份 "failed" DSN。两份 DSN 的状态码（都会以 "4" 开头以表示「临时失败」）是相同的。

另一个 action 与 status 码看似矛盾的例子：如果某个 MTA 或邮件网关因为投递会引发导致不可接受的信息损失的转换而无法投递报文，它会发出一份 'action' 字段为 "failure"、状态码为 'XXX' 的 DSN。而如果该报文改为被中继，但伴有一定的信息损失，它可能生成一份状态码同为 XXX、但 action 字段为 "relayed" 的 DSN。

2.3.4 Status 字段

每收件人的 Status 字段包含一个与传输无关的状态码，用以指明该报文投递给该收件人的投递状态。对于 DSN 所描述的每一次投递尝试，此字段必须（MUST）出现。

status 字段的语法为：

status-field = "Status" ":" status-code

status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT

   ; White-space characters and comments are NOT allowed within
   ; a status-code, though a comment enclosed in parentheses
   ; MAY follow the last numeric sub-field of the status-code.
   ; Each numeric sub-field within the status-code MUST be
   ; expressed without leading zero digits.

（译注：状态码内部不允许出现空白字符与注释，不过以圆括号括起的注释可以（MAY）跟在状态码最后一个数字子字段之后；状态码中的每一个数字子字段必须（MUST）不带前导零书写。）

因此，状态码由以 "." 分隔的三个数字字段组成。第一个子字段指明投递尝试是否成功（2 = 成功，4 = 持续性临时失败，5 = 永久失败）。第二个子字段指明任何投递异常的可能来源，第三个子字段则在已知的情况下标明精确的错误情形。

状态码的初始集合在 [STATUS] 中定义。

2.3.5 Remote-MTA 字段

与 Remote-MTA DSN 字段相关联的取值，是向「reporting（报告）」MTA 报告投递状态的那个「remote（远端）」MTA 名称的可打印 ASCII 表示。

   remote-mta-field = "Remote-MTA" ":" mta-name-type ";" mta-name

注意：Remote-MTA 字段保留了在某些既有非投递报告中所提供的「while talking to（在与……通信时）」信息。

此字段是可选的。如果在向该收件人投递报文的尝试中没有涉及任何远端 MTA，则不得（MUST NOT）包含该字段。

2.3.6 Diagnostic-Code 字段

对于 "failed" 或 "delayed" 的收件人，Diagnostic-Code DSN 字段包含由邮件传输系统所发出的实际诊断码。由于这类码在不同邮件传输系统之间各不相同，因此需要 diagnostic-type 子字段来指明所表示的是哪一种类型的诊断码。

 diagnostic-code-field =
       "Diagnostic-Code" ":" diagnostic-type ";" *text

注意：Diagnostic-Code 字段中的信息可能与 Status 字段中的信息有些许重复。之所以需要 Status 字段，是为了让任何 DSN——无论其来源如何——都能被任何解析 DSN 的用户代理或网关所理解。由于 Status 码有时不如实际的传输诊断码精确，因此提供 Diagnostic-Code 字段以保留后者的信息。此类信息在发给报告 MTA 管理员的故障工单中，或在把外部非投递报告通过 DSN 进行隧道传递时，可能会有用。

如果 Diagnostic Code 是在尝试把报文中继给某个远端 MTA 的过程中从该远端 MTA 获得的，那么 Remote-MTA 字段应当存在。在解释一份 DSN 时，Remote-MTA 字段的存在表明该 Diagnostic Code 是由远端 MTA 发出的；Remote-MTA 的缺失则表明该 Diagnostic Code 是由报告 MTA 发出的。

除 Diagnostic-Code 本身之外，对该诊断的附加文字描述可以（MAY）出现在以圆括号括起的注释中。

此字段是可选的，因为某些邮件系统除了在 'action' 与 'status' 字段中返回的信息之外，不再提供其他信息。不过，如果可以获得特定于传输的诊断信息，则应当（SHOULD）包含该字段。

2.3.7 Last-Attempt-Date 字段

Last-Attempt-Date 字段给出报告 MTA 最后一次尝试中继、网关转发或投递该报文（无论成功与否）的日期与时间。它未必与「用于传送此投递状态通知的那封报文」信头中 Date 字段的取值相同：在 DSN 由网关生成的情形下，报文信头中的 Date 字段包含该网关发送此 DSN 的时间，而 DSN 的 Last-Attempt-Date 字段则包含最后一次投递尝试发生的时间。

   last-attempt-date-field = "Last-Attempt-Date" ":" date-time

此字段是可选的。如果最后一次投递尝试的实际日期与时间无法获得（在 DSN 由网关发出时可能就是这种情况），则不得（MUST NOT）包含该字段。

日期与时间以 RFC 822 的 'date-time' 格式表示（并按 [HOSTREQ] 所作修改）。必须（MUST）使用数字时区（[+/-]HHMM 格式）。

2.3.8 final-log-id 字段

"final-log-id" 字段给出 final-mta 为该报文所使用的 final-log-id。它可以作为索引，用于定位 final-mta 中与该次投递尝试相对应的日志条目。

   final-log-id-field = "Final-Log-ID" ":" *text

此字段是可选的。

2.3.9 Will-Retry-Until 字段

对于 "delayed" 类型的 DSN，Will-Retry-Until 字段给出一个日期，报告 MTA 预期在该日期之后放弃向该收件人投递此报文的一切尝试。Will-Retry-Until 字段对于 "delay" 类 DSN 是可选的，并且不得（MUST NOT）出现在其他 DSN 中。

   will-retry-until-field = "Will-Retry-Until" ":" date-time

日期与时间以 RFC 822 的 'date-time' 格式表示（并按 [HOSTREQ] 所作修改）。必须（MUST）使用数字时区（[+/-]HHMM 格式）。

2.4 扩展字段

未来可能通过对本规范的后续修订或扩展，定义额外的每报文或每收件人 DSN 字段。以 "X-" 开头的扩展字段名永远不会被定义为标准字段；此类名称保留供实验用途。不以 "X-" 开头的 DSN 字段名必须（MUST）向互联网号码分配机构（IANA）注册，并在 RFC 中发布。

出于以下原因，可以定义扩展 DSN 字段：

鼓励 MTA 实现者提供充分的信息（必要时通过扩展字段），使 MTA 维护者能够理解可纠正的投递失败的性质以及如何修复它们。例如，如果记录了报文投递尝试的日志，DSN 中可以包含一些信息，使 MTA 维护者能够轻松找到某次失败投递尝试所对应的日志条目。

如果某个 MTA 开发者不希望注册此类扩展字段的含义，可以为此目的使用 "X-" 字段。为避免名称冲突，MTA 实现的名称应跟在 "X-" 之后（例如 "X-Foomail-Log-ID"）。

3. 一致性与使用要求

如果某个 MTA 或网关按照本备忘录所定义的协议生成 DSN，则它符合本规范。对于不支持「请求肯定投递通知」（例如 [DRPT] 中所定义者）的 MTA 与网关而言，只要投递失败报告使用本协议即已足够。

本规范的一个最小实现，只需生成每报文的 Reporting-MTA 字段，以及针对该 DSN 所描述的每一次「向某收件人投递报文」的尝试生成 Final-Recipient、Action 与 Status 字段。强烈建议在适当情况下生成其他字段。

除非邮件传输协议提供了发送者在提交时最初所指定的地址，否则 MTA 与网关不得（MUST NOT）生成 DSN 的 Original-Recipient 字段。（普通的 SMTP 并不提供这样的保证，但 [DRPT] 所定义的 SMTP 扩展允许在此类信息可得时把它承载于信封之中。）

每一个由发送者指定的收件人地址，应当（SHOULD）至多导致针对该收件人的一份 "delivered" 或 "failed" DSN。如果针对某个收件人请求了肯定 DSN（例如在 SMTP 中使用 NOTIFY=SUCCESS），而该收件人被转发到一个「alias」（如 [DRPT] 第 7.2.7 节所定义）的多个收件人，那么执行转发的 MTA 通常应当（SHOULD）针对最初指定的收件人发出一份 "expanded" DSN，而不把 DSN 请求传播到各转发地址。或者，执行转发的 MTA 可以（MAY）把该 DSN 请求恰好中继给其中一个转发地址，而不传播给其余地址。

与此相对，把报文成功提交给邮件列表分发器则被视为该报文的最终投递。当报文被投递到与某个邮件列表分发器相对应的收件人地址时，报告 MTA 应当（SHOULD）完全按照该收件人地址是一个普通邮箱的方式，发出相应的 DSN。

注意：这实际上意在使 DSN 能够为邮件列表自身所用。任何发送给邮件列表订阅者的报文，其信封回信地址都应指向列表维护者［参见 RFC 1123 第 5.3.7(E) 节］。由于 DSN 是发送到信封回信地址的，因此由「向邮件列表各收件人投递」所产生的全部 DSN 都会被发送给列表维护者。列表维护者可以选择在收到 DSN 后以机械方式处理它们，从而自动从列表中删除无效地址。（参见本备忘录附录 C。）

本规范对用户代理或分发列表所收到的 DSN 的处理方式不作任何限制。

4. 安全考虑

使用 DSN 时适用以下安全考虑。

4.1 伪造

DSN 可以像普通 Internet 电子邮件一样被轻易伪造。希望自动利用 DSN 的用户代理与自动邮件处理设施（例如邮件分发列表分发器）应采取适当的预防措施，以尽量减少拒绝服务攻击所造成的潜在损害。

与伪造 DSN 相关的安全威胁包括发送：

4.2 机密性

安全的另一个维度是机密性。可能存在这样的情形：某位报文收件人正在自动转发邮件，但不希望透露报文被自动转发到的那个地址。随着「无线邮箱」（例如寻呼机）作为自动转发地址被越来越广泛地使用，对这种机密性的需求很可能会加剧。

鼓励 MTA 作者提供一种机制，使最终用户能够保持转发地址的机密性。取决于所需的机密程度，以及报文被转发去往的环境的性质，这可以通过下列一种或多种方式实现：

一般而言，如果报告 MTA 所在站点判定包含某个可选 DSN 字段会过度损害站点机密性，则可以省略该字段。对这种机密性的需求，必须与「所省略的信息在故障报告以及网关转发到外部环境的 DSN 中的效用」之间取得平衡。

提醒实现者注意：许多既有 MTA 会把非投递通知发送到报文信头中的回信地址（而不是信封中的回信地址），这违反了 SMTP 及其他协议。如果报文经过这样的 MTA 转发，那么执行转发的 MTA 无论采取何种合理措施，都无法阻止下游 MTA 泄露该转发地址。同样地，如果收件人的 MTA 基于报文信头中的某项请求（例如非标准但被广泛使用的 Return-Receipt-To 扩展信头）自动作出响应，它也会泄露该转发地址。

4.3 不可否认性

在当今 Internet 邮件的框架内，本备忘录所定义的 DSN 为邮件用户提供了有价值的信息；然而，即便是一份 "failed" DSN，也不能被当作「报文未被收件人收到」的保证而加以依赖。即使 DSN 未被主动伪造，仍存在这样的条件：尽管发出了失败 DSN，报文却实际得以投递。

例如，SMTP 协议中的一个竞态条件使得：如果连接在 DATA 命令完成之后、但在 SMTP 客户端看到响应之前被断开，报文就可能被重复。

这会导致 SMTP 客户端重传该报文，尽管 SMTP 服务器其实已经接受了它 [SMTPDUP]。如果这些投递尝试中的一次成功、另一次失败，那么即使报文实际已送达收件人，也可能发出一份 "failed" DSN。

5. 规范性参考文献

6. 致谢

作者谨此感谢下列人士对 RFC 1894（本文档是其修订版）早期草案的评审及其改进建议：Eric Allman、Harald Alvestrand、Allan Cargille、Jim Conklin、Peter Cowen、Dave Crocker、Roger Fajman、Ned Freed、Marko Kaittola、Steve Kille、John Klensin、John Gardiner Myers、Mark Nahabedian、Julian Onions、Jacob Palme、Jean Charles Roy 与 Gregory Sheehan。

附录 A —— 汇总语法

注意：下列词法记号在 RFC 822 中定义：atom、CHAR、comment、CR、CRLF、DIGIT、LF、linear-white-space、SPACE、text。date-time 词法记号在 [HOSTREQ] 中定义。

   action-field = "Action" ":" action-value

   action-value =  "failed" / "delayed" / "delivered"
         / "relayed" / "expanded"

   address-type = atom

   arrival-date-field = "Arrival-Date" ":" date-time

   delivery-status-content =  per-message-fields
         1*( CRLF per-recipient-fields )

   diagnostic-code-field =  "Diagnostic-Code" ":"
         diagnostic-type ";" *text

   diagnostic-type = atom

   dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name

   envelope-id = *text

   extension-field = extension-field-name ":" *text

   extension-field-name = atom

   final-recipient-field =
         "Final-Recipient" ":" address-type ";" generic-address

   final-log-id-field = "Final-Log-ID" ":" *text

   generic-address = *text

   last-attempt-date-field = "Last-Attempt-Date" ":" date-time

   mta-name = *text

   mta-name-type = atom

   original-envelope-id-field =
         "Original-Envelope-Id" ":" envelope-id

   original-recipient-field =
         "Original-Recipient" ":" address-type ";" generic-address

   per-message-fields =
         [ original-envelope-id-field CRLF ]
         reporting-mta-field CRLF
         [ dsn-gateway-field CRLF ]
         [ received-from-mta-field CRLF ]
         [ arrival-date-field CRLF ]
         *( extension-field CRLF )

   per-recipient-fields =
        [ original-recipient-field CRLF ]
        final-recipient-field CRLF
        action-field CRLF
        status-field CRLF
        [ remote-mta-field CRLF ]
        [ diagnostic-code-field CRLF ]
        [ last-attempt-date-field CRLF ]
        [ final-log-id-field CRLF ]
        [ will-retry-until-field CRLF ]
         *( extension-field CRLF )

   received-from-mta-field =
        "Received-From-MTA" ":" mta-name-type ";" mta-name

   remote-mta-field =
        "Remote-MTA" ":" mta-name-type ";" mta-name

   reporting-mta-field =
         "Reporting-MTA" ":" mta-name-type ";" mta-name

   status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT

     ; White-space characters and comments are NOT allowed within a
     ; a status-code, though a comment enclosed in parentheses
     ; MAY follow the last numeric sub-field of the status-code.
     ; Each numeric sub-field within the status-code MUST be
     ; expressed without leading zero digits.

   status-field = "Status" ":" status-code

   will-retry-until-field = "Will-Retry-Until" ":" date-time

附录 B —— DSN 网关转发指南

注意：本节为「希望在 Internet 与另一电子邮件系统之间提供半透明投递报告」的邮件网关的构建，提供不具约束力的建议。针对某一对特定邮件系统的具体 DSN 网关要求，可由其他文档另行定义。

从其他邮件系统网关转发为 DSN

邮件网关可以发出一份 DSN，以便通过 Internet 邮件传达某份「外部」投递或非投递通知的内容。当外部通知的各要素与 DSN 字段之间存在适当映射时，可以把这些信息承载于相应的 DSN 字段中。附加信息（例如可能对故障工单有用、或为把外部通知通过 Internet 隧道传递所需要的信息）可以定义在扩展 DSN 字段中。（此类字段应被赋予能够标识该外部邮件协议的名称，例如用 X400-* 表示 X.400 的 NDN 或 DN 协议要素。）

网关必须尽力为 Reporting-MTA、Final-Recipient、Action 与 Status 字段提供合理的取值。这些取值通常可以通过把远端投递或非投递通知中的值翻译为其 Internet 风格的等价形式而获得。不过，应当预料到会有一定的信息损失。例如，为 DSN 所定义的状态码集合，可能不足以完整传达来自外部系统的投递诊断码。网关应当指派最能精确描述该失败情形的状态码，必要时退回到诸如 2.0.0（成功）、4.0.0（临时失败）与 5.0.0（永久失败）这样的「通用」码。实际的外部诊断码应保留在 Diagnostic-Code 字段中（并带有合适的 diagnostic-type 取值），以供故障工单或隧道传递之用。

如果由发送者指定的收件人地址与原始 envelope-id 存在于外部传输信封中，则应把它们分别保留在 Original-Recipient 与 Original-Envelope-ID 字段中。

网关还应尽力保留来自外部系统的「最终」收件人地址与 MTA 名称。只要有可能，外部协议要素就应被编码为有意义的可打印 ASCII 字符串。

对于由外部投递或非投递通知所产生的 DSN，网关的名称必须（MUST）出现在该 DSN 的 DSN-Gateway 字段中。

从 DSN 网关转发到其他邮件系统

把 DSN 从 Internet 网关转发进入某个外部邮件系统是可能的。此类网关转发的首要目的，是以目的系统可用的形式传达投递状态信息；次要目的则是允许 DSN 在外部邮件系统中进行「隧道」传递，以便该 DSN 有可能再被网关转发回 Internet。

一般而言，DSN 的接收者（即原始报文的发送者）会希望针对每一个收件人了解：最接近原始收件人地址的可用近似形式、投递状态（成功、失败或临时失败），以及对于失败的投递，一个描述失败原因的诊断码。

如有可能，网关应尽力在所生成的外部投递状态报告中保留 Original-Recipient 地址与 Original-Envelope-ID（若存在）。

在报告投递失败时，如果 Diagnostic-Code 字段的 diagnostic-type 子字段表明目的环境能够理解原始诊断码，则应使用 Diagnostic-Code 字段中的信息。若做不到这一点，则应把 Status 字段中的信息映射为目的环境所使用的、最为接近的可用诊断码。

如果能够把 DSN 在目的环境中进行隧道传递，网关规范可以定义一种方法，在该环境所使用的投递状态报告中保留 DSN 信息。

附录 C —— 邮件列表分发器使用 DSN 的指南

本节仅涉及 [4] 第 7.2.7 节所定义的「邮件列表（mailing lists）」对 DSN 的使用。

DSN 的设计目标之一，就是供邮件列表分发器使用，使其能够检测并自动删除那些邮件投递反复失败的收件人。

在向列表订阅者转发报文时，邮件列表分发器应始终把信封回信地址（例如 SMTP MAIL FROM 地址）设为指向一个专门用于接收非投递报告的特殊地址。这样，一个「智能」的邮件列表分发器便能够拦截此类非投递报告，并在它们采用 DSN 格式时自动加以检查，以确定报文投递对哪些收件人失败或被延迟。

若 Original-Recipient 字段可用，则应使用它，因为它应当与列表所知的订阅者地址完全匹配。如果 Original-Recipient 字段不可用，收件人字段可能与列表订阅者地址相近。不过订阅者往往已把自己的邮件转发到另一个地址，或者该地址可能经历过某种改写，因此可能需要借助启发式方法才能成功匹配收件人字段中的地址。在这种情况下需要审慎行事，以尽量减少误匹配的可能性。

投递失败的原因可以从 Status 与 Action 字段获得，也可以从 Diagnostic-Code 字段获得（若其 status-type 可被识别）。对于 action 取值不为 "failed" 的收件人，其报告一般可以忽略；特别是，不应因为 "delayed" 报告而把订阅者从列表中移除。

一般而言，几乎任何失败状态码（即便是「永久」类的）都可能由临时状况引起。因此建议：列表分发器不要仅凭任何单独一份失败 DSN（无论其状态码为何）就删除某位订阅者，而应仅在投递失败于一段时间内持续存在时才这样做。

然而，某些类型的失败比其他类型更不可能由临时状况引起，而某些类型的失败则更可能被迅速察觉并纠正。一旦定义了更为精确的状态码，在决定是否删除订阅者时区分不同状态码可能会很有用。例如，在报文量很大的列表上，对于反复造成「临时」失败的收件人地址，或许更宜暂时中止向其投递，而不是简单地删除该收件人。中止的时长可以取决于错误的类型。另一方面，持续数天的「user unknown（用户不存在）」错误，则可以被视为该地址不再有效的可靠迹象。

附录 D —— DSN 类型的 IANA 注册表格

下列表格用于向互联网号码分配机构（IANA）注册新的 address-type、diagnostic-type 或 MTA-name-type。注册表格所要求的每一项信息，既可以通过在表格本身中提供该信息来满足，也可以通过给出一份包含必要信息的、已发布且公开可得的规范的引用来满足。IANA 可以（MAY）因注册表格不完整、规范不精确或类型名称不恰当而拒绝 DSN 类型的注册。

要注册一种 DSN 类型，请填写下面适用的表格，并通过 Internet 电子邮件发送至 <IANA@IANA.ORG>。

address-type 的 IANA 注册表格

DSN address-type 的注册必须（MUST）包含以下信息：

diagnostic-type 的 IANA 注册表格

DSN address-type 的注册必须（MUST）包含以下信息：

MTA-name-type 的 IANA 注册表格

DSN MTA-name-type 的注册必须包含以下信息：

附录 E —— 示例

下列示例仅作说明之用，不视为 DSN 协议规范的组成部分。如果某个示例与上文的协议定义相冲突，则以协议定义为准、该示例为误。

同样地，这些示例中对 *-type 子字段名或扩展字段的使用，也不应被解读为对那些类型名或扩展字段的定义。

这些示例是根据当时所能获得的信息，由退信报文手工翻译整理而来。

简单 DSN

这是一份在反复尝试投递报文失败后所发出的简单 DSN。在本例中，该 DSN 由发出该报文的同一个 MTA 所发出。

Date: Thu, 7 Jul 1994 17:16:05 -0400 From: Mail Delivery Subsystem
<MAILER-DAEMON@CS.UTK.EDU> Message-Id:
<199407072116.RAA14128@CS.UTK.EDU> Subject: Returned mail: Cannot
send message for 5 days To: <owner-info-mime@cs.utk.edu> MIME-
Version: 1.0 Content-Type: multipart/report; report-type=delivery-
status;
       boundary="RAA14128.773615765/CS.UTK.EDU"

--RAA14128.773615765/CS.UTK.EDU

The original message was received at Sat, 2 Jul 1994 17:10:28 -0400
from root@localhost

    ----- The following addresses had delivery problems -----
<louisl@larry.slip.umd.edu>  (unrecoverable error)

----- Transcript of session follows -----
<louisl@larry.slip.umd.edu>... Deferred: Connection timed out
            with larry.slip.umd.edu.
Message could not be delivered for 5 days
Message will be deleted from queue

--RAA14128.773615765/CS.UTK.EDU
content-type: message/delivery-status

Reporting-MTA: dns; cs.utk.edu

Original-Recipient: rfc822;louisl@larry.slip.umd.edu
Final-Recipient: rfc822;louisl@larry.slip.umd.edu
Action: failed
Status: 4.0.0
Diagnostic-Code: smtp; 426 connection timed out
Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400

--RAA14128.773615765/CS.UTK.EDU
content-type: message/rfc822

[original message goes here]

--RAA14128.773615765/CS.UTK.EDU--

多收件人 DSN

这是另一份由发送者的 MTA 所发出的 DSN，其中包含多次投递尝试的细节。其中一些是在本地检测到的，另一些则由远端 MTA 检测到。

Date: Fri, 8 Jul 1994 09:21:47 -0400
From: Mail Delivery Subsystem <MAILER-DAEMON@CS.UTK.EDU>
Subject: Returned mail: User unknown
To: <owner-ups-mib@CS.UTK.EDU>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
       boundary="JAA13167.773673707/CS.UTK.EDU"

--JAA13167.773673707/CS.UTK.EDU
content-type: text/plain; charset=us-ascii

       ----- The following addresses had delivery problems -----
<arathib@vnet.ibm.com> (unrecoverable error)
<wsnell@sdcc13.ucsd.edu> (unrecoverable error)

 --JAA13167.773673707/CS.UTK.EDU
content-type: message/delivery-status

Reporting-MTA: dns; cs.utk.edu

Original-Recipient: rfc822;arathib@vnet.ibm.com
Final-Recipient: rfc822;arathib@vnet.ibm.com
Action: failed
Status: 5.0.0 (permanent failure)
Diagnostic-Code: smtp;  550 'arathib@vnet.IBM.COM' is not a
 registered gateway user
Remote-MTA: dns; vnet.ibm.com

Original-Recipient: rfc822;johnh@hpnjld.njd.hp.com
Final-Recipient: rfc822;johnh@hpnjld.njd.hp.com
Action: delayed
Status: 4.0.0 (hpnjld.njd.jp.com: host name lookup failure)

Original-Recipient: rfc822;wsnell@sdcc13.ucsd.edu
Final-Recipient: rfc822;wsnell@sdcc13.ucsd.edu
Action: failed
Status: 5.0.0
Diagnostic-Code: smtp; 550 user unknown
Remote-MTA: dns; sdcc13.ucsd.edu

--JAA13167.773673707/CS.UTK.EDU
content-type: message/rfc822

 [original message goes here]

--JAA13167.773673707/CS.UTK.EDU--

由网关发往外部系统的 DSN

这是一份由 Message Router（MAILBUS）生成、并由 PMDF_MR 网关转换为 DSN 的投递报告。在本例中，网关没有足够的信息来提供 original-recipient 地址。

Disclose-recipients: prohibited
Date: Fri, 08 Jul 1994 09:21:25 -0400 (EDT)
From: Message Router Submission Agent <AMMGR@corp.timeplex.com>
Subject: Status of: Re: Battery current sense
To: owner-ups-mib@CS.UTK.EDU
Message-id: <01HEGJ0WNBY28Y95LN@mr.timeplex.com>
MIME-version: 1.0
content-type: multipart/report;
    report-type=delivery-status;
    boundary="84229080704991.122306.SYS30"

--84229080704991.122306.SYS30
content-type: text/plain

Invalid address - nair_s
%DIR-E-NODIRMTCH, No matching Directory Entry
Entry found

--84229080704991.122306.SYS30
content-type: message/delivery-status

Reporting-MTA: mailbus; SYS30

Final-Recipient: unknown; nair_s
Status: 5.0.0 (unknown permanent failure)
Action: failed

--84229080704991.122306.SYS30--

延迟 DSN

这是一份来自多协议 MTA 的延迟报告。请注意其中没有退回的内容，因此该 DSN 中没有出现第三个主体部分。

MIME-Version: 1.0
From: <postmaster@nsfnet-relay.ac.uk>
Message-Id: <199407092338.TAA23293@CS.UTK.EDU>
Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk
        id <g.12954-0@sun2.nsfnet-relay.ac.uk>;
        Sun, 10 Jul 1994 00:36:51 +0100
To: owner-info-mime@cs.utk.edu
Date: Sun, 10 Jul 1994 00:36:51 +0100
Subject: WARNING: message delayed at "nsfnet-relay.ac.uk"
content-type: multipart/report; report-type=delivery-status;
       boundary=foobar

--foobar
content-type: text/plain

The following message:

UA-ID: Reliable PC (...
Q-ID: sun2.nsf:77/msg.11820-0

has not been delivered to the intended recipient:

    thomas@de-montfort.ac.uk

despite repeated delivery attempts over the past 24 hours.

The usual cause of this problem is that the remote system is
temporarily unavailable.

Delivery will continue to be attempted up to a total elapsed time of
168 hours, i.e., 7 days.

You will be informed if delivery proves to be impossible within this
time.

Please quote the Q-ID in any queries regarding this mail.

--foobar
content-type: message/delivery-status

Reporting-MTA: dns; sun2.nsfnet-relay.ac.uk

Final-Recipient: rfc822;thomas@de-montfort.ac.uk
Status: 4.0.0 (unknown temporary failure)
Action: delayed

--foobar--

附录 F —— 相对于 RFC 1894 的变更

作者地址（Authors' Addresses）

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

Phone: +1-865-974-3126
Fax: +1-865-974-8296
EMail: moore@cs.utk.edu

Gregory M. Vaudreuil
Lucent Technologies
7291 Williamson Rd
Dallas, Tx. 75214
USA

Phone: +1 214 823 9325
EMail: GregV@ieee.org

版权所有 (C) 互联网协会（The Internet Society）（2003）。保留所有权利。

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

上文所授予的有限许可是永久性的，互联网协会及其继承者或受让人不会撤销该许可。

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

以下为上述版权声明的英文原文（依据许可条款一并保留）：

Copyright (C) The Internet Society (2003).  All Rights Reserved.

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）：RFC 编辑（RFC Editor）职能的经费目前由互联网协会提供。