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

RFC 8098《邮件处置通知（MDN）》中文译本

IETF · RFC 8098 · 标准跟踪（Standards Track）· 2017 年 2 月

摘要

本文档定义了一种 MIME 内容类型，可供邮件用户代理（MUA）或电子邮件网关在消息被成功投递给收件人之后，报告该消息的处置情况。该内容类型旨在可供机器处理。本文档还定义了额外的报文头字段，以允许消息的发送方请求邮件处置通知（MDN）。其目的是扩展 Internet 邮件，以支持其他消息系统（如 X.400 以及专有的"基于 LAN"的系统）中常见的功能，这些功能通常被称为"已读回执"、"确认"或"收讫通知"。这样做的初衷是尊重过去讨论此类功能时经常被提及的隐私关切。

由于许多消息在 Internet 与其他消息系统（如 X.400 或专有的"基于 LAN"的系统）之间往来传输，MDN 协议被设计成在多协议消息环境中也能发挥作用。为此，本文档所描述的协议除承载 Internet 邮件中常规使用的地址外，还提供对"外部"（foreign）地址的承载。还可以定义额外的属性，以支持通过 Internet 邮件对外部通知进行"隧道"（tunneling）传输。

本文档是一项 Internet 标准。它废弃（obsoletes）了 RFC 3798，并更新（updates）了 RFC 2046（message/partial 媒体类型的处理）与 RFC 3461（Original-Recipient 信头字段的生成要求）。

1. 引言

本文档为邮件处置通知（MDN）定义了一种媒体类型 [RFC2046]。MDN 可用于在成功投递后，将消息可能发生的若干状况通知消息的发送方，例如消息内容的显示、消息的打印、消息的删除（未显示）或收件人拒绝提供 MDN。本文档定义的 "message/disposition-notification" 内容类型，旨在用于 RFC-REPORT [RFC6522] 所定义的 "multipart/report" 内容类型框架之内。

本文档定义了通知的格式，以及用于请求这些通知的 RFC-MSGFMT [RFC5322] 信头字段。

1.1. 目的

本文档定义的 MDN 预期服务于以下几个目的：

以基本独立于人类语言的方式，将消息成功投递后的处置情况告知人类；
允许邮件用户代理通过将返回的 MDN 与先前的消息发送相关联，来跟踪所发送消息的处置情况；
通过网关在 Internet 邮件与"外部"邮件系统之间传递处置通知请求与处置通知；
允许"外部"通知通过支持 MIME 的消息系统被隧道传输，并回到发出原始通知的原始消息系统，甚至传到第三个消息系统；
提供与语言无关、但足够精确的指示，以传达消息的处置情况。

1.2. 要求

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

它必须可被人类阅读，且必须可被机器解析。
它必须提供足够的信息，使消息发送方（或其用户代理）能够将 MDN 明确地与所发送的消息以及为其签发 MDN 的原始收件人地址（若此类信息可得）相关联，即使该消息被转发给了另一个收件人地址。
它还必须能够描述消息的处置情况，而独立于任何特定的人类语言或任何特定邮件系统的术语。
该规范必须具有可扩展性，以适应未来的需求。

1.3. 术语

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

所有语法描述使用 RFC-MSGFMT [RFC5322] 所指定的 ABNF，其中定义了下列词法记号（下文使用）："CRLF"、"FWS"、"CFWS"、"field-name"、"mailbox-list"、"msg-id" 和 "text"。下列词法记号在 RFC-SMTP [RFC5321] 中定义："Atom"。

2. 请求邮件处置通知

通过在消息中包含 Disposition-Notification-To 信头字段，并在其中给出一个或多个指定处置应发送往何处地址，即可请求邮件处置通知。收件人的邮件用户代理（MUA）[RFC5598] 在生成 MDN 时所需的更多信息，也可以通过同时在消息中包含 Original-Recipient 和/或 Disposition-Notification-Options 信头字段来提供。

2.1. Disposition-Notification-To 信头

通过在消息中放置 Disposition-Notification-To 信头字段，即可请求接收方用户代理签发邮件处置通知。该信头字段的语法为：

mdn-request-header = "Disposition-Notification-To" ":"
           mailbox-list CRLF

Disposition-Notification-To 信头字段在一条消息中最多只能出现一次。

消息中存在 Disposition-Notification-To 信头字段，仅仅是一个签发 MDN 的请求。收件人的用户代理始终可自由地悄然忽略此类请求。

MDN 本身不得（MUST NOT）带有 Disposition-Notification-To 信头字段。MDN不得（MUST NOT）为响应另一条 MDN 而生成。

用户代理不得（MUST NOT）代表每个特定收件人签发超过一个 MDN。也就是说，一旦为某收件人签发了 MDN，同一用户代理便不得再为该收件人签发更多的 MDN，即使对该消息执行了其他处置。然而，如果一条消息被转发，则可能为执行转发的收件人已经签发过一个 MDN，而被转发消息的收件人也可能引发生成另一个 MDN。

同样有可能发生的情况是：如果同一消息正被多个用户代理访问（例如使用 POP3），则可能为同一收件人生成多个处置。用户代理应当（SHOULD）利用底层消息访问协议的支持，防止生成多个 MDN。特别是，当用户代理使用 RFC-IMAP [RFC3501] 访问消息时，它应当（SHOULD）实现 RFC-IMAP-MDN [RFC3503] 中规定的过程。

虽然 Internet 标准通常不规定用户界面的行为，但强烈建议用户代理在发送 MDN 之前取得用户的同意。这种同意可以通过某种提示或对话框针对每一条消息获取，也可以通过用户设置的偏好全局性地获取。用户也可以全局地表示永不发送 MDN。取得用户同意的目的是为了保护用户的隐私。默认值应为不发送 MDN。

如果 Disposition-Notification-To 信头字段中的地址与 Return-Path 信头字段中的地址不同（见 RFC-MSGFMT [RFC5322]），则不得（MUST NOT）自动发送 MDN。在这种情况下，如果可能，必须（MUST）取得用户的确认。如果无法取得同意（例如，因为当时用户不在线，或者客户端不是交互式电子邮件客户端），则不得（MUST NOT）发送 MDN。

如果消息中没有 Return-Path 信头字段，或者 Disposition-Notification-To 信头字段中存在多个不同的地址，则必须（MUST）取得用户的确认（否则不发送 MDN）。

地址的比较仅使用 addr-spec（local-part "@" domain）部分，排除任何尖括号、短语（phrase）和路由（route）。按照 RFC 5322 的规定，比较对 local-part 区分大小写，对 domain 部分不区分大小写。local-part 的比较应当（SHOULD）在执行 local-part 规范化之后进行，即：若有的话，先去除两侧的直双引号字符以及任何转义 "\ " 字符。（详见 RFC-MSGFMT [RFC5322]。）出于比较目的，实现可以（MAY）将已知的域别名视为等价。

注意，使用子地址（见 [RFC5233]）可能导致两个 local-part 无法匹配，从而可能抑制 MDN 的发送。本文档不建议针对此情形做特殊处理，因为接收方 MUA 无法可靠地知道发送方是否在使用子地址。

如果消息包含多个 Return-Path 信头字段，实现可以挑选其中一个用于比较，也可以将该情形视为比较失败。

在比较失败或指定了多个地址时不自动发送 MDN 的原因，是为了降低邮件环（mail loop）以及将 MDN 用于邮件轰炸（mail bombing）的可能性。

特别重要的是，包含 Disposition-Notification-To 信头字段的消息也应当包含 Message-ID 信头字段，以便用户代理能够自动将 MDN 与其原始消息相关联。

如果希望对一部分收件人而非其他收件人请求消息处置通知，则应发送该消息的两份副本，一份带有 Disposition-Notification-To 信头字段，一份不带。消息的许多其他信头字段（如 To、Cc）在这两份副本中将是相同的。各份消息信封中的收件人决定了向谁请求消息处置通知、不向谁请求。如果需要，Message-ID 信头字段在这两份消息副本中可以相同。注意，在其他情形（例如 Bcc）下，也有必要发送信头字段略有不同的多份消息副本。此类情形的组合，加上仅需对全部收件人的一个子集请求 MDN 的需求，可能导致发送超过两份的消息副本，其中一些带有 Disposition-Notification-To 信头字段，一些不带。

如果能够确定某收件人是一个新闻组（newsgroup），则不要为该收件人包含 Disposition-Notification-To 信头字段。类似地，如果一条已有消息被转发或网关到某个新闻组，执行转发/网关操作的代理应当（SHOULD）去除 Disposition-Notification-To 信头字段。更多讨论见第 5 节。在新闻组消息中看到形式上有效的 Disposition-Notification-To 信头字段的客户端，不应（SHOULD NOT）生成 MDN。

2.2. Disposition-Notification-Options 信头

对本规范的扩展可能要求向收件人的 MUA 提供信息，以便对 MDN 的生成方式与内容做额外控制。Disposition-Notification-Options 信头字段为这类信息提供了一种可扩展的机制。该信头字段的语法如下：

Disposition-Notification-Options =
            "Disposition-Notification-Options" ":" [FWS]
                           disposition-notification-parameter-list CRLF

disposition-notification-parameter-list =
            disposition-notification-parameter
            *([FWS] ";" [FWS] disposition-notification-parameter)

disposition-notification-parameter = attribute [FWS] "="
            [FWS] importance [FWS] "," [FWS] value
            *([FWS] "," [FWS] value)

importance = "required" / "optional"

attribute = Atom

value = word

Disposition-Notification-Options 信头字段在一条消息中最多只能出现一次。

"required"（需要）的重要性表明，为正确生成响应此请求的 MDN，解释该 disposition-notification-parameter 是必要的。"optional"（可选）的重要性表明，不理解该 disposition-notification-parameter 含义的 MUA可以（MAY）仍然生成响应此请求的 MDN，而忽略该 disposition-notification-parameter 的值。

本规范未定义任何 disposition-notification-parameter 属性名。属性名可在未来由本规范的后续修订或扩展来定义。Disposition-Notification-Options 参数属性名必须（MUST）使用 "Specification Required"（需要规范）注册策略 [RFC5226] 在 Internet Assigned Numbers Authority（IANA）注册。"X-" 前缀历史上被用来表示未注册的"实验性"协议元素，并假定其不会成为通用用法。本规范及其他协议的部署经验表明，这一假定常常是错误的。本文档允许使用 "X-" 前缀，主要目的是允许注册已经在通用使用中的属性。该前缀对新的属性没有意义。在全新的属性中大量使用它可能令人困惑，因此不鼓励。（注册表单见第 10 节。）

2.3. Original-Recipient 信头字段

由于电子邮件地址可能在消息传输途中被改写，由投递消息传输代理（MTA）[RFC5598] 提供原始收件人地址是有用的。投递 MTA 可以从 SMTP RCPT TO 命令的 ORCPT 参数获取此信息，如 RFC-SMTP [RFC5321] 与 RFC-DSN-SMTP [RFC3461] 中所定义。

RFC-DSN-SMTP [RFC3461] 修订如下：如果 ORCPT 信息可得，投递 MTA应当（SHOULD）在消息开头（连同 Return-Path 信头字段一起）插入一个 Original-Recipient 信头字段。投递 MTA可以（MAY）删除消息中出现的任何其他 Original-Recipient 信头字段。该信头字段的语法如下：

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

OWS = [CFWS]
        ; Optional whitespace.
        ; MDN generators SHOULD use "*WSP"
        ; (Typically a single space or nothing.
        ; It SHOULD be nothing at the end of a field.),
        ; unless an RFC 5322 "comment" is required.
        ;
        ; MDN parsers MUST parse it as "[CFWS]".

address-type 与 generic-address 记号如第 3.2.3 节中 Original-Recipient 字段的描述所规定。

携带原始收件人信息并在 MDN 中返回它的目的，是允许以每个收件人为基础将 MDN 与原始消息自动相关联。

2.4. 与 message/partial 媒体类型的配合

将信头字段 Disposition-Notification-To、Disposition-Notification-Options 和 Original-Recipient 与 MIME message/partial 内容类型（RFC-MIME-MEDIA [RFC2046]）配合使用，需要进一步的定义。

当一条消息被分片为两个或更多 message/partial 片段时，上述段落提到的三个信头字段应当（SHOULD）放置在"内部"或"被封装"的消息中（使用 RFC-MIME-MEDIA [RFC2046] 的术语）。如果在任何片段的信头字段中发现这些信头字段，则忽略它们。

当多个 message/partial 片段被重新组装时，适用以下规则。如果这些信头字段与某个 message/partial 片段消息的其他信头字段一同出现，则它们对应于将为该片段生成的 MDN。如果这些信头字段出现在"内部"或"被封装"消息的信头字段中（使用 RFC-MIME-MEDIA [RFC2046] 的术语），则它们对应于将为重新组装后的消息生成的 MDN。RFC-MIME-MEDIA [RFC2046] 的 5.2.2.1 节被修订，规定除其中指定的信头字段外，本规范描述的三个信头字段还需按顺序追加到重新组装后消息的信头字段之后。此处定义的三个信头字段在初始封装消息的信头字段中的任何出现，不得（MUST NOT）复制到重新组装后的消息中。

3. 邮件处置通知的格式

邮件处置通知是一种 MIME 消息，其顶层内容类型为 multipart/report（定义于 RFC-REPORT [RFC6522]）。当 multipart/report 内容用于传输 MDN 时：

multipart/report 的 report-type 参数为 "disposition-notification"。
multipart/report 的第一个组成部分包含对 MDN 的人类可读说明，如 RFC-REPORT [RFC6522] 中所述。
multipart/report 的第二个组成部分的内容类型为 message/disposition-notification，见本文档第 3.1 节的描述。
如果原始消息或其一部分要返回给发送方，则它作为 multipart/report 的第三个组成部分出现。是否返回消息或其一部分，由生成 MDN 的 MUA 决定。然而，在加密消息请求 MDN 的情况下，如果返回原始消息或其一部分，则必须（MUST）以其原始加密形式返回。

注意：对于从外部系统网关过来的邮件处置通知，原始消息的信头字段可能不可得。在此情况下，可以省略 MDN 的第三个组成部分，也可以包含含有等价信息的"模拟"RFC-MSGFMT [RFC5322] 信头字段。特别希望保留原始消息的主题（subject）和日期（date）字段。

MDN必须（MUST）在报文信头字段和传输信封中，都被寻址到正在生成 MDN 的原始消息的 Disposition-Notification-To 信头字段中的地址。

MDN 的 From 信头字段必须（MUST）包含为其签发邮件处置通知的人员的地址。

MDN 的信封发送方地址（即 SMTP 的 "MAIL FROM"）必须（MUST）为空（<>），指明不应发送投递状态通知消息，也不应发送指示投递成功或失败的其他消息来响应 MDN。

邮件处置通知本身不得（MUST NOT）请求 MDN。也就是说，它不得（MUST NOT）包含 Disposition-Notification-To 信头字段。

MDN 的 Message-ID 信头字段（若存在）必须（MUST）与为其签发 MDN 的消息的 Message-ID 不同。

特定的 MDN 恰好描述一个消息对一个收件人的处置情况。一次消息提交可能产生多个 MDN，每个收件人一个。然而，由于第 2.1 节所述的情形，很可能部分被请求了 MDN 的收件人不会生成 MDN。

3.1. Message/Disposition-Notification 媒体类型

message/disposition-notification 媒体类型定义如下：

Type name:          message

Subtype name:       disposition-notification

Required parameters:  none

Optional parameters:  none

Encoding considerations:  "7bit" encoding is sufficient and MUST be
                      used to maintain readability when viewed by
                      non-MIME mail readers.

Security considerations:  discussed in Section 6 of RFC 8098.

Interoperability considerations:  none

Published specification:  RFC 8098

Applications that use this media type:  Mail Transfer Agents and
                      email clients that support multipart/report
                      generation and/or parsing.

Fragment identifier considerations:  N/A

Additional information:

                         Deprecated alias names for this type: N/A

                         Magic number(s): none

                         File extension(s): .disposition-notification

                         Macintosh file type code(s): The 'TEXT' type
                         code is suggested as files of this type are
                         typically used for diagnostic purposes and
                         suitable for analysis in a text editor.  A
                         Uniform Type Identifier (UTI) of "public.utf8-
                         email-message-header" is suggested.  This type
                         conforms to "public.plain-text".

Person & email address to contact for further information:
                      ART Area Mailing List <art@ietf.org>

Intended usage:     COMMON

Restrictions on usage:  This media type contains textual data in the
                      US-ASCII charset, which is always 7bit.

Author:             See the Authors' Addresses section of RFC 8098.

Change controller:  IETF

Provisional registration?  no

（虽然 7bit 限制适用于 multipart/report 内容的 message/disposition-notification 部分，但它不适用于 multipart/report 内容可选的第三部分。）

用于 multipart/report 的 message/disposition-notification 报告类型为 "disposition-notification"。

message/disposition-notification 的主体由一个或多个按照 RFC-MSGFMT [RFC5322] 信头"字段"的 ABNF 格式化的"字段"组成。message/disposition-notification 内容的语法如下：

disposition-notification-content = [ reporting-ua-field CRLF ]
            [ mdn-gateway-field CRLF ]
            [ original-recipient-field CRLF ]
            final-recipient-field CRLF
            [ original-message-id-field CRLF ]
            disposition-field CRLF
            *( error-field CRLF )
            *( extension-field CRLF )

extension-field = extension-field-name ":" *([FWS] text)

extension-field-name = field-name

注意，上述字段的顺序是推荐的，但并非固定。扩展字段可以出现在任何位置。

3.1.1. 字段的通用约定

由于这些字段是根据 RFC-MSGFMT [RFC5322] 的规则定义的，因此关于续行与注释的相同约定也适用。通知字段可以通过将每一附加行以 SPACE 或 HTAB 开头而延续到多行。出现在圆括号中的文本被视为注释，不属于该通知字段的内容。字段名不区分大小写，因此通知字段的名称可以用大写和小写字母的任意组合拼写。通知字段中 RFC-MSGFMT [RFC5322] 的注释可以使用 RFC-MIME-HEADER [RFC2047] 中定义的 "encoded-word" 构造。

3.1.2. "*-type" 子字段

若干字段由 "-type" 子字段、一个分号，以及后续 "*text" 组成。对于这些字段，address-type 或 MTA-type 子字段中使用的关键字指示了后续地址或 MTA-name 的预期格式。

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

"address-type" 指定邮箱地址的格式。例如，Internet 邮件地址使用 "rfc822" address-type。其他值可按 RFC-DSN-FORMAT [RFC3464] 建立的 "Address Types"（地址类型）IANA 子注册表中指定的方式出现在本字段中。

address-type = Atom

Atom = <The version from RFC 5321 (not from RFC 5322)
             is used in this document.>

"MTA-name-type" 指定邮件传输代理名称的格式。例如，对于 Internet 主机上的 SMTP 服务器，MTA 名称是该主机的域名，使用 "dns" MTA-name-type。其他值可按 RFC-DSN-FORMAT [RFC3464] 建立的 "MTA Name Types"（MTA 名称类型）IANA 子注册表中指定的方式出现在本字段中。

mta-name-type = Atom

address-type 和 mta-name-type 的值不区分大小写。因此，address-type 值 "RFC822" 与 "rfc822" 是等价的。

Internet Assigned Numbers Authority（IANA）维护了一个 address-type 和 mta-name-type 值的注册表，并附有各值含义的描述，或提供此类描述的一个或多个规范的引用。（"rfc822" address-type 定义于 RFC-DSN-SMTP [RFC3461]。）address-type 与 mta-name-type 的注册表单见 RFC-DSN-FORMAT [RFC3464]。

3.2. Message/Disposition-Notification 内容字段

3.2.1. Reporting-UA 字段

reporting-ua-field = "Reporting-UA" ":" OWS ua-name OWS
                       [ ";" OWS ua-product OWS ]

ua-name = *text-no-semi

ua-product = *([FWS] text)

text-no-semi = %d1-9 /         ; "text" characters excluding NUL, CR,
               %d11 / %d12 / %d14-58 / %d60-127  ; LF, or semi-colon

Reporting-UA 字段定义如下：

MDN 描述消息被投递给收件人后的处置情况。在所有情形下，Reporting-UA 都是执行 MDN 中所描述处置的 MUA。

"Reporting-UA" 字段包含关于生成 MDN 的 MUA 的信息，服务器常利用它来帮助确定所报告互操作问题的范围、规避或定制响应以避免特定 MUA 的局限，并用于关于 MUA 或操作系统使用情况的分析。MUA应当（SHOULD）发送 "Reporting-UA" 字段，除非被特别配置为不发送。

如果生成报告的 MUA 由多个组件构成（例如一个基础程序和若干插件），可以通过包含一系列产品名称来指示这一点。

生成报告的 MUA应当（SHOULD）将所生成的产品标识符限制在识别该产品所必需的范围内；发送方不得（MUST NOT）在产品标识符中生成广告或其他非必要信息。

生成报告的 MUA不应（SHOULD NOT）生成包含不必要细粒度细节的 "Reporting-UA" 字段，并应当（SHOULD）限制第三方添加子产品。过长过细的 "Reporting-UA" 字段取值会增加用户在违背其意愿的情况下被识别（"指纹识别"，fingerprinting）的风险。

同样，鼓励实现不要使用其他实现的 product 令牌来声明与之兼容，因为这规避了该字段的初衷。如果某 MUA 伪装成另一个 MUA，收件人可能假定该用户确实希望看到为该被标识的 MUA 定制的响应，即便这些响应对于实际使用的 MUA 可能并不奏效。

示例：

Reporting-UA:  Foomail 97.1

3.2.2. MDN-Gateway 字段

MDN-Gateway 字段指示将外部（非 Internet）消息处置通知转换为本 MDN 的网关或 MTA 的名称。该字段必须（MUST）出现在任何由网关从外部系统翻译为 MDN 格式的 MDN 中，除此之外不得（MUST NOT）出现。

mdn-gateway-field = "MDN-Gateway" ":" OWS mta-name-type OWS
                      ";" OWS mta-name OWS

mta-name = *text

对于进入 Internet 邮件的网关，MTA-name-type 通常为 "dns"，mta-name 为该网关的 Internet 域名。

3.2.3. Original-Recipient 字段

Original-Recipient 字段指示为其签发 MDN 的消息的发送方所指定的原始收件人地址。对于 Internet 邮件消息，Original-Recipient 字段的值取自正在生成 MDN 的消息的 Original-Recipient 信头字段。如果消息中存在 Original-Recipient 信头字段，或者关于原始收件人的信息可以其他方式可靠获得，则必须（MUST）包含 Original-Recipient 字段。否则，不得（MUST NOT）包含 Original-Recipient 字段。如果消息中有多个 Original-Recipient 信头字段，MUA 可以选择使用哪一个，或者视作不存在 Original-Recipient 信头字段来处理。

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

generic-address = *text

address-type 字段指示原始收件人地址的类型。如果消息源自 Internet 内部，address-type 字段通常为 "rfc822"，地址则符合 RFC-MSGFMT [RFC5322] 中指定的语法。如果 Reporting MUA 无法从消息信封确定原始收件人地址的类型，则应使用值 "unknown"。该地址与发送方提供的相同，可用于以每个收件人为基础将 MDN 报告与原始消息自动相关联。

3.2.4. Final-Recipient 字段

Final-Recipient 字段指示为其签发 MDN 的收件人。该字段必须（MUST）存在。

该字段的语法如下：

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

Final-Recipient 字段的 generic-address 子字段应当（SHOULD）包含收件人的邮箱地址（将与 MDN 的 From 信头字段相同），即 MUA 生成 MDN 时的地址。

该字段可能不包含消息最终收件人地址的一个例子是：当某个别名（例如 <customer-support@example.com>）将邮件转发给某个特定的个人地址（例如 <bob@example.com>）时。Bob 可能希望发送 MDN，但不愿暴露其个人电子邮件地址。在此情况下，Final-Recipient 字段可以包含：

   Final-Recipient: rfc822;customer-support@example.com

以替代：

   Final-Recipient: rfc822;bob@example.com

Final-Recipient 地址可能不同于发送方最初提供的地址，因为它可能在转发和网关过程中被转换为完全无法辨认的样子。然而，在缺少可选的 Original-Recipient 字段时，Final-Recipient 字段与任何返回的内容，可能是将 MDN 与特定消息收件人相关联的唯一可用信息。

address-type 子字段指示在该上下文中报告 MTA 所期望的地址类型。通过 SMTP 获得的收件人地址通常为 address-type "rfc822"，但也可以是从 "Delivery Status Notification (DSN) Types" IANA 注册表的 "Address Types" 子注册表中取的其他值。

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

3.2.5. Original-Message-ID 字段

Original-Message-ID 字段指示为其签发 MDN 的消息的 message-ID。它取自为其签发 MDN 的消息的 Message-ID 信头字段。当且仅当原始消息包含 Message-ID 信头字段时，该字段必须（MUST）存在。该字段的语法如下：

original-message-id-field =
            "Original-Message-ID" ":" msg-id

msg-id 记号如 RFC-MSGFMT [RFC5322] 中所指定。

3.2.6. Disposition 字段

Disposition 字段指示 Reporting MUA 代表用户所执行的动作。该字段必须（MUST）存在。

Disposition 字段的语法为：

disposition-field =
            "Disposition" ":" OWS disposition-mode OWS ";"
            OWS disposition-type
            [ OWS "/" OWS disposition-modifier
            *( OWS "," OWS disposition-modifier ) ] OWS

disposition-mode = action-mode OWS "/" OWS sending-mode

action-mode = "manual-action" / "automatic-action"

sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"

disposition-type = "displayed" / "deleted" / "dispatched" /
            "processed"

disposition-modifier = "error" / disposition-modifier-extension

disposition-modifier-extension = Atom

disposition-mode、disposition-type 和 disposition-modifier 的值可以用大写和小写 US-ASCII 字符的任意组合拼写。

3.2.6.1. Disposition 模式

Disposition 模式由两部分组成：动作模式（action mode）与发送模式（sending mode）。

定义了以下动作模式：

"manual-action"（手动动作）：处置类型所描述的处置是用户明确指令的结果，而非某种自动执行的动作。（这可能包括用户手动将其 MUA 配置为自动响应有效的 MDN 请求的情形。）除非在特定邮件环境中有另行规定，为保护用户隐私，这必须（MUST）作为 MUA 的默认值。
"automatic-action"（自动动作）：处置类型所描述的处置是自动动作的结果，而非用户针对此消息的明确指令。这通常由邮件投递代理生成（例如，Sieve 的 reject 动作 [RFC5429] 生成的 MDN、Fax-over-Email [RFC3249]、语音消息系统（见 Voice Profile for Internet Mail (VPIM) [RFC3801]），或在投递到邮件列表时生成）。

"manual-action" 与 "automatic-action" 互斥。必须指定其中之一。

定义了以下发送模式：

"MDN-sent-manually"（MDN 手动发送）：用户明确许可发送这一特定的 MDN。除非在特定邮件环境中有另行规定，为保护用户隐私，这必须（MUST）作为 MUA 的默认值。
"MDN-sent-automatically"（MDN 自动发送）：MDN 是因 MUA 先前被配置为自动发送而发出的。

"MDN-sent-manually" 与 "MDN-sent-automatically" 互斥。必须指定其中之一。

3.2.6.2. Disposition 类型

定义了以下 disposition-type：

"displayed"（已显示）：消息已被 MUA 显示给阅读收件人邮箱的人。并不保证内容已被阅读或理解。
"dispatched"（已分发）：消息已被以某种方式发往某处（例如打印、传真、转发），而不一定事先显示给用户。用户之后可能看到也可能看不到该消息。
"processed"（已处理）：消息已被以某种方式处理（即，通过某种规则或服务器），而未显示给用户。用户之后可能看到也可能看不到该消息，甚至可能没有与该邮箱关联的人类用户。
"deleted"（已删除）：消息已被删除。收件人可能看到也可能没看到该消息。收件人之后可能"反删除"消息并阅读它。

3.2.6.3. Disposition 修饰符

仅定义了扩展的 disposition 修饰符：

disposition-modifier-extension（disposition 修饰符扩展）：disposition 修饰符可在未来由本规范的后续修订或扩展来定义。MDN disposition 值名称必须（MUST）使用 "Specification Required" 注册策略在 Internet Assigned Numbers Authority（IANA）注册。（注册表单见第 10 节。）带有接收方 MUA 无法理解的 disposition 修饰符名称的 MDN，可以被悄然忽略，或置入用户邮箱而不做特殊解释。它们不得（MUST NOT）导致向 MDN 的发送方发出任何错误消息。

并不要求 MUA 能够生成 Disposition 字段所有可能的取值。

用户代理不得（MUST NOT）代表每个特定收件人签发超过一个 MDN。也就是说，一旦为某收件人签发了 MDN，便不得再为该收件人签发进一步的 MDN，即使对该消息执行了其他处置。然而，如果一条消息被转发，则可以为执行转发的收件人签发一个 "dispatched" MDN，而被转发消息的收件人也可能引发生成 MDN。

3.2.7. Error 字段

当 "error" disposition 修饰符出现时，Error 字段用于以文本消息的形式提供额外信息。语法如下：

error-field = "Error" ":" *([FWS] text)

注意，这些信头字段的语法不包含注释，因此 RFC-MIME-HEADER [RFC2047] 中定义的 "encoded-word" 构造不能用于传达非 ASCII 文本。需要在这些字段中传达非 ASCII 文本的应用，应当考虑实现 [RFC6533] 中规定的 message/global-disposition-notification 媒体类型，而非本规范。

3.3. Extension-Fields

未来的本规范修订或扩展可以定义额外的 MDN 字段。MDN 字段名称必须（MUST）使用 "Specification Required" 注册策略在 Internet Assigned Numbers Authority（IANA）注册。（注册表单见第 10 节。）MDN 扩展字段可因以下原因定义：

允许来自外部处置报告的其他信息通过 Internet MDN 进行隧道传输。此类 MDN 字段的名称应以外部环境名称的指示开头（例如 X400-Physical-Forwarding-Address）。
允许传输特定于某个邮件用户代理（MUA）的诊断信息。此类 MDN 字段的名称应以产生该 MDN 的 MUA 实现的指示开头（例如 Foomail-information）。

4. 事件时间线

以下时间线展示了在消息处理和 MDN 生成过程中，各类事件发生的时机：

用户撰写消息。
用户指示 MUA 发送消息。
MUA 将消息传递给邮件提交代理（MSA），并传递原始收件人信息。
MSA 将消息发送给下一个 MTA。
最终 MTA 收到消息。
最终 MTA 将消息投递到收件人的邮箱（可能生成投递状态通知（DSN））。
（收件人的）MUA 发现收件人邮箱中有新消息，并决定是否应生成 MDN。如果 MUA 已知该消息的 MDN 已经生成，则不再执行下述进一步的 MDN 处理。如果 MUA 判定无法生成 MDN，则不再执行下述进一步的 MDN 处理。
MUA 执行自动处理，并可能生成相应的 MDN（"dispatched"、"processed" 或 "deleted" disposition 类型，配合 "automatic-action" 与 "MDN-sent-automatically" disposition 模式）。MUA 记录已生成 MDN。
MUA 向用户显示消息列表。
用户选择一条消息，并请求对其执行某些动作。
MUA 执行所请求的动作；如果尚未生成自动 MDN，则在用户许可下发送适当的 MDN（"displayed"、"dispatched"、"processed" 或 "deleted" disposition 类型，配合 "manual-action" 与 "MDN-sent-manually" 或 "MDN-sent-automatically" disposition 模式）。MUA 记录已生成 MDN。
用户可能对该消息执行其他动作，但不再生成进一步的 MDN。

5. 一致性与使用要求

如果某 MUA 或网关按照本文档定义的协议生成 MDN，则它符合本规范。并不要求必须能够生成 Disposition 字段所有可能的取值。

MUA 和网关不得（MUST NOT）生成 MDN 的 Original-Recipient 字段，除非邮件协议在提交时提供了发送方最初指定的地址。普通 SMTP 不提供该保证，但 RFC-DSN-SMTP [RFC3461] 中定义的 SMTP 扩展允许在信封中携带此类信息（若可得）。本文档定义的 Original-Recipient 信头字段为 MTA 向 MUA 传递原始收件人地址提供了一种方式。

每个发送方指定的收件人地址可能导致多于一个 MDN。如果为某个被转发给"别名"（如 RFC-DSN-SMTP [RFC3461] 的 6.2.7.3 节所定义）的多个收件人的收件人请求了 MDN，则每个收件人都可以签发 MDN。

将消息成功分发到邮件列表扩展器或到 Usenet 新闻组的网关，应当（SHOULD）视为消息的最终处置。邮件列表扩展器可以（MAY）签发一个 disposition 类型为 "processed"、disposition 模式为 "automatic-action" 和 "MDN-sent-automatically" 的 MDN，表明消息已被转发到该列表。在此情况下，MDN 的请求不传播给列表的成员。

另一种做法（如果不将消息成功分发到邮件列表扩展器/Usenet 新闻组视为消息的最终处置），邮件列表扩展器可以不签发 MDN，而将 MDN 请求传播给列表的所有成员。后一种行为除对小型、联系紧密的列表外不推荐使用，因为它可能导致生成大量 MDN，并可能暴露列表的机密订阅者。邮件列表扩展器也可以将 MDN 指向自身、对其进行关联，并向消息的原始发送方生成一份报告。

本规范对用户代理或邮件列表接收到的 MDN 的处理不做任何限制。

6. 安全考虑

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

6.1. 伪造

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

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

在所指明的消息处置实际并未发生时，伪造的处置通知；以及
未经请求的 MDN。

类似地，伪造的垃圾邮件或钓鱼电子邮件消息可以包含 Disposition-Notification-To 信头字段，从而诱骗收件人发送 MDN。只有在电子邮件消息的真实性得到验证之后，才应调用 MDN 处理。

6.2. 隐私

安全的另一个维度是隐私。可能存在这样的情况：消息收件人不希望其收件消息的处置情况被知悉，或者担心发送 MDN 可能暴露其他敏感信息（例如，消息何时被阅读、使用了哪个电子邮件客户端、使用了哪个操作系统）。在此情形下，MUA 悄然忽略 MDN 请求是可以接受的。

如果在将消息分发给邮件列表订阅者时未经修改地传递 Disposition-Notification-To 信头字段，则列表订阅者可能通过生成 MDN 而被原始消息的发送方知悉。

在 multipart/report 第三部分中返回的原始消息信头，以及 message/disposition-notification 部分的内容，可能暴露防火墙内部主机名和/或网络拓扑的机密信息。

Disposition 模式（第 3.2.6.1 节）可能泄露收件人 MUA 配置的信息，特别是 MDN 是手动确认还是自动确认。如果这是一个关切，MUA 可以在生成的 MDN 中返回 "manual-action/MDN-sent-manually" disposition 模式。

一般而言，如果 Reporting MUA 站点或用户判定包含某字段会过度损害站点的机密性，则可以省略任何可选的 MDN 字段。此类机密性的需要与所省略信息在 MDN 中的效用之间必须加以权衡。

在某些情况下，能够访问消息流的人可能利用 MDN 请求机制来监视目标的邮件阅读习惯。如果已知目标会生成 MDN 报告，他们可以添加包含信封 from 地址的 Disposition-Notification-To 信头字段。不自动发送 MDN 可以将此风险降到最低。

6.2.1. 产品信息的披露

"Reporting-UA" 字段（第 3.2.1 节）、User-Agent 信头字段以及其他信头字段常常暴露关于相应发送方软件系统的信息。理论上，这可能使攻击者更容易利用已知安全漏洞；但实际上，攻击者往往会不论明显使用的软件版本如何，尝试所有可能的漏洞。还应注意，"Reporting-UA" 字段相比许多 MUA 使用的 "User-Agent" 和/或（未文档化的）"X-Mailer" 信头字段，并未提供任何新的信息。

6.2.2. MUA 指纹识别

"Reporting-UA" 字段（第 3.2.1 节）可能包含足够的信息来唯一标识特定设备，通常是在结合其他特征时，特别是当该用户代理发送关于用户系统或扩展的过量细节时。即使遵循第 3.2.1 节的指南以避免指纹识别，其他唯一信息来源（例如 Accept-Language 信头字段）仍可能呈现。

6.3. 不可抵赖性

MDN 不提供带有投递证明的不可抵赖性（non-repudiation）。在当今 Internet 邮件的框架内，本文档定义的 MDN 为邮件用户提供了有价值的信息；然而，MDN 不能被视为消息是否已被收件人看到的保证。即使 MDN 未被主动伪造，它们也可能在传输途中丢失。收件人可能以某种方式绕过了 MDN 签发机制。

针对此目的的一种可能解决方案见 RFC-SEC-SERVICES [RFC2634]。

6.4. 邮件轰炸

MDN 请求机制引入了一种对邮箱进行邮件轰炸的附加方式。MDN 请求通知提供了一个 MDN 应发送往的地址。攻击代理有可能向原本不知情的第三方收件人发送一大批消息，并带有虚假的 Disposition-Notification-To 地址。对此类请求的自动或简单化处理，将导致涌向攻击目标的大量 MDN 通知。此外，由于生成的 MDN 通知可能包含引发它们的消息的完整内容，从而可能比这些消息本身更大，它们可被用于带宽放大攻击。此类攻击可能超出目标邮箱和/或邮件传输系统的存储容量，从而拒绝服务。

因此，在 Disposition-Notification-To 地址不同于 SMTP "MAIL FROM" 地址（携带于 Return-Path 信头字段中）时，不应（SHOULD NOT）自动发送 MDN。进一步讨论见第 2.1 节。

7. 收集的 ABNF 文法

注意：以下词法记号定义于 RFC-MSGFMT [RFC5322]：CRLF、FWS、CFWS、field-name、mailbox-list、msg-id、text、comment 和 word。以下词法记号定义于 RFC-SMTP [RFC5321]：Atom。（注意，RFC-MSGFMT [RFC5322] 也定义了 "atom"，但来自 RFC-SMTP [RFC5321] 的版本限制更严，本文档使用这一限制更严的版本。）RFC-MIME-HEADER [RFC2047] 中定义的 "encoded-word" 构造允许出现在 RFC-MSGFMT [RFC5322] "comment" 被使用的任何地方，例如在 CFWS 中。

 OWS = [CFWS]
       ; Optional whitespace.
       ; MDN generators SHOULD use "*WSP"
       ; (Typically a single space or nothing.
       ; It SHOULD be nothing at the end of a field.),
       ; unless an RFC 5322 "comment" is required.
       ;
       ; MDN parsers MUST parse it as "[CFWS]".

Message header fields:
   mdn-request-header =
          "Disposition-Notification-To" ":" mailbox-list CRLF

   Disposition-Notification-Options =
          "Disposition-Notification-Options" ":" [FWS]
                    disposition-notification-parameter-list CRLF

   disposition-notification-parameter-list =
                    disposition-notification-parameter
                    *([FWS] ";" [FWS]
                    disposition-notification-parameter)

   disposition-notification-parameter = attribute [FWS] "=" [FWS]
                    importance [FWS] "," [FWS] value *([FWS] ","
                    [FWS] value)

   importance = "required" / "optional"

   attribute = Atom

   value = word

   original-recipient-header =
          "Original-Recipient" ":" OWS address-type OWS
          ";" OWS generic-address OWS CRLF

Report content:
   disposition-notification-content =
          [ reporting-ua-field CRLF ]
          [ mdn-gateway-field CRLF ]
          [ original-recipient-field CRLF ]
          final-recipient-field CRLF
          [ original-message-id-field CRLF ]
          disposition-field CRLF
          *( error-field CRLF )
          *( extension-field CRLF )

   address-type = Atom

   mta-name-type = Atom

   reporting-ua-field = "Reporting-UA" ":" OWS ua-name OWS [
                        ";" OWS ua-product OWS ]

   ua-name = *text-no-semi

   ua-product = *([FWS] text)

   text-no-semi = %d1-9 /        ; "text" characters excluding NUL, CR,
           %d11 / %d12 / %d14-58 / %d60-127      ; LF, or semi-colon

   mdn-gateway-field = "MDN-Gateway" ":" OWS mta-name-type OWS
                       ";" OWS mta-name

   mta-name = *text

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

   generic-address = *text

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

   original-message-id-field = "Original-Message-ID" ":" msg-id

   disposition-field =
          "Disposition" ":" OWS disposition-mode OWS ";"
          OWS disposition-type
          [ OWS "/" OWS disposition-modifier
          *( OWS "," OWS disposition-modifier ) ] OWS

   disposition-mode = action-mode OWS "/" OWS sending-mode

   action-mode = "manual-action" / "automatic-action"

   sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"

   disposition-type = "displayed" / "deleted" / "dispatched" /
           "processed"

   disposition-modifier = "error" / disposition-modifier-extension

   disposition-modifier-extension = Atom

   error-field = "Error" ":" *([FWS] text)

   extension-field = extension-field-name ":" *([FWS] text)

   extension-field-name = field-name

8. MDN 网关化指南

注意：本节为希望提供 Internet 与另一电子邮件系统之间半透明处置通知的邮件网关的构建，提供了非约束性的建议。特定的一对邮件系统的具体 MDN 网关要求，可由其他文档定义。

8.1. 从其他邮件系统网关到 MDN

邮件网关可以签发 MDN，以通过 Internet 邮件传达"外部"处置通知的内容。当存在从外部通知元素到 MDN 字段的适当映射时，该信息可在那些 MDN 字段中传输。额外信息（例如将外部通知通过 Internet 进行隧道传输可能需要的）可以在扩展 MDN 字段中定义。（此类字段应被赋予标识外部邮件协议的名称，例如用于 X.400 协议元素 [X.400] 的 X400-*。）

网关必须尝试为 Reporting-UA、Final-Recipient 和 Disposition 字段提供合理的值。这些通常通过将外部通知中的值翻译为其 Internet 风格的等价物来获得。然而，预计会有一定的信息损失。

发送方指定的收件人地址与原始 message-id（若存在于外部通知中）应保留在 Original-Recipient 和 Original-Message-ID 字段中。

网关还应尝试保留来自外部系统的最终收件人地址。只要可能，外部协议元素应编码为有意义的可打印 ASCII 字符串。

对于由外部处置通知产生的 MDN，网关的名称必须（MUST）出现在该 MDN 的 MDN-Gateway 字段中。

8.2. 从 MDN 网关到其他邮件系统

有可能将 Internet 的 MDN 网关到外部邮件系统。此类网关化的主要目的是以目的地系统可用的形式传达处置信息。次要目的是允许 MDN 通过外部邮件系统进行"隧道"传输，以防该 MDN 可能被网关回 Internet。

一般而言，MDN 的接收方（即原始消息的发送方）会希望对每个收件人：知道与原始收件人地址尽可能接近的近似，以及处置（已显示、已打印等）。

如果可能，网关应尝试在所产生的外部处置报告中保留 Original-Recipient 地址和 Original-Message-ID（若存在）。

如果可以通过目的地环境对 MDN 进行隧道传输，网关规范可以定义一种在该环境所使用的处置报告中保留 MDN 信息的方法。

8.3. 将 MDN 请求网关到其他邮件系统

通过使用独立的 Disposition-Notification-To 请求信头字段，本规范提供了比大多数（若非全部）其他电子邮件系统更丰富的功能。在大多数其他电子邮件系统中，通知收件人与 "from" 地址所指示的消息发送方相同。网关到此类系统时有两个有趣的案例：

如果 Disposition-Notification-To 信头字段中的地址与 SMTP "MAIL FROM" 中的地址相同，则即使 Disposition-Notification-To 信息丢失，也会得到预期的行为。系统应当传播 MDN 请求。
如果 Disposition-Notification-To 信头字段中的地址与 SMTP "MAIL FROM" 中的地址不同，则网关到没有独立通知地址的外部系统将导致非预期的行为。当消息经由邮件列表扩展软件到达时这一点尤其重要，该软件可能专门将 SMTP "MAIL FROM" 地址替换为备用地址。在此类情形下，不应网关化 MDN 请求，而应悄然丢弃。这与不支持 MDN 的其他形式一致。

9. 示例

注意：本示例仅供参考，不被视为 MDN 协议规范的一部分。如果示例与上述协议定义冲突，则是示例错了。

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

这是在消息已被显示给 Internet 邮件用户代理的用户之后签发的 MDN。

Date: Wed, 20 Sep 1995 00:19:00 (EDT) -0400
From: Joe Recipient <Joe_Recipient@example.com>
Message-Id: <199509200019.12345@example.com>
Subject: Disposition notification
To: Jane Sender <Jane_Sender@example.org>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=disposition-notification;
   boundary="RAA14128.773615765/example.com"

--RAA14128.773615765/example.com

The message sent on 1995 Sep 19 at 13:30:00 (EDT) -0400 to Joe
Recipient <Joe_Recipient@example.com> with subject "First draft of
report" has been displayed.
This is no guarantee that the message has been read or understood.

--RAA14128.773615765/example.com
Content-Type: message/disposition-notification

Reporting-UA: joes-pc.cs.example.com; Foomail 97.1
Original-Recipient: rfc822;Joe_Recipient@example.com
Final-Recipient: rfc822;Joe_Recipient@example.com
Original-Message-ID: <199509192301.23456@example.org>
Disposition: manual-action/MDN-sent-manually; displayed

--RAA14128.773615765/example.com
Content-Type: message/rfc822

[original message optionally goes here]

--RAA14128.773615765/example.com--

10. IANA 考虑

IANA 已完成以下动作：

IANA 已更新 message/disposition-notification 媒体类型的注册模板，以匹配本文档第 3.1 节中的内容，并将该媒体类型的引用更新为指向本文档（而非 RFC 3798）。
此处指定的注册表已经存在；本节更新了它们的文档。IANA 已将三个 Message Disposition Notification Parameters 注册表的引用文档改为指向本文档（而非 RFC 3798）。

本文档规定了三种必须使用 Internet Assigned Numbers Authority（IANA）注册的参数类型。它们全部使用 "Specification Required" 的 IANA 注册策略 [RFC5226]。

以下表单用于注册 Disposition-Notification-Options 信头字段的新 disposition-notification-parameter 名称、新的 disposition 修饰符名称，或新的 MDN 扩展字段。注册表单所需的每条信息，既可以通过在表单本身上提供该信息来满足，也可以通过包含引用了包含必要信息的已发布且公开可用的规范来满足。IANA可以（MAY）因注册表单不完整或规范不完整而拒绝注册。

要注册，请填写以下适用的表单，并通过电子邮件发送至 <IANA@IANA.ORG>。

10.1. Disposition-Notification-Options 信头字段的 disposition-notification-parameter 名称

Disposition-Notification-Options 信头字段的 disposition-notification-parameter 名称的注册必须（MUST）包含以下信息：

拟议的 disposition-notification-parameter 名称。
disposition-notification-parameter 值的语法，使用 BNF、ABNF、正则表达式或其他无歧义语言指定。
如果 disposition-notification-parameter 值并非完全由 US-ASCII 字符集中的可图示字符组成，则规定它们在 Disposition-Notification-Options 信头字段中如何编码为可图示的 US-ASCII 字符的规范。
对描述 disposition-notification-parameter 值语义的永久且易得的公开规范的引用。

10.2. Disposition 修饰符名称

disposition 修饰符名称（用于 message/disposition-notification 的 Disposition 字段中）的注册必须（MUST）包含以下信息：

拟议的 disposition 修饰符名称。
对描述该 disposition 修饰符语义的永久且易得的公开规范的引用。

10.3. MDN 扩展字段名称

MDN 扩展字段名称的注册必须（MUST）包含以下信息：

拟议的扩展字段名称。
扩展值的语法，使用 BNF、ABNF、正则表达式或其他无歧义语言指定。
如果扩展字段值并非完全由 US-ASCII 字符集中的可图示字符组成，则规定它们在 Disposition-Notification-Options 信头字段中如何编码为可图示的 US-ASCII 字符的规范。
对描述该扩展字段语义的永久且易得的公开规范的引用。

11. 参考文献

11.1. 规范性参考文献

[RFC5321] Klensin, J.（克林斯），《简单邮件传输协议（Simple Mail Transfer Protocol）》，RFC 5321，DOI 10.17487/RFC5321，2008 年 10 月，<http://www.rfc-editor.org/info/rfc5321>。
[RFC5322] Resnick, P.（雷斯尼克，编），《Internet 报文格式（Internet Message Format）》，RFC 5322，DOI 10.17487/RFC5322，2008 年 10 月，<http://www.rfc-editor.org/info/rfc5322>。
[RFC2045] Freed, N. 与 N. Borenstein（弗里德与博伦斯坦），《多用途 Internet 邮件扩展（MIME）第一部分：Internet 报文主体的格式》，RFC 2045，DOI 10.17487/RFC2045，1996 年 11 月，<http://www.rfc-editor.org/info/rfc2045>。
[RFC2046] Freed, N. 与 N. Borenstein（弗里德与博伦斯坦），《多用途 Internet 邮件扩展（MIME）第二部分：媒体类型》，RFC 2046，DOI 10.17487/RFC2046，1996 年 11 月，<http://www.rfc-editor.org/info/rfc2046>。
[RFC2047] Moore, K.（穆尔），《MIME（多用途 Internet 邮件扩展）第三部分：非 ASCII 文本的信头扩展》，RFC 2047，DOI 10.17487/RFC2047，1996 年 11 月，<http://www.rfc-editor.org/info/rfc2047>。
[RFC6522] Kucherawy, M.（库切拉维，编），《用于报告邮件系统管理消息的 Multipart/Report 媒体类型》，STD 73，RFC 6522，DOI 10.17487/RFC6522，2012 年 1 月，<http://www.rfc-editor.org/info/rfc6522>。
[RFC3461] Moore, K.（穆尔），《简单邮件传输协议（SMTP）用于投递状态通知（DSN）的服务扩展》，RFC 3461，DOI 10.17487/RFC3461，2003 年 1 月，<http://www.rfc-editor.org/info/rfc3461>。
[RFC3464] Moore, K. 与 G. Vaudreuil（穆尔与沃德勒伊），《用于投递状态通知的可扩展报文格式》，RFC 3464，DOI 10.17487/RFC3464，2003 年 1 月，<http://www.rfc-editor.org/info/rfc3464>。
[RFC2119] Bradner, S.（布拉德纳），《用于 RFC 中指示要求等级的关键词》，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997 年 3 月，<http://www.rfc-editor.org/info/rfc2119>。
[RFC3503] Melnikov, A.（梅尔尼科夫），《Internet 消息访问协议（IMAP）的邮件处置通知（MDN）配置文档》，RFC 3503，DOI 10.17487/RFC3503，2003 年 3 月，<http://www.rfc-editor.org/info/rfc3503>。

11.2. 资料性参考文献

[RFC2634] Hoffman, P.（霍夫曼，编），《S/MIME 增强安全服务（Enhanced Security Services for S/MIME）》，RFC 2634，DOI 10.17487/RFC2634，1999 年 6 月，<http://www.rfc-editor.org/info/rfc2634>。
[RFC3249] Cancio, V.、Moldovan, M.、Tamura, H. 与 D. Wing（坎西奥、莫尔多瓦努、田村与温），《使用 Internet 邮件的传真实现者指南》，RFC 3249，DOI 10.17487/RFC3249，2002 年 9 月，<http://www.rfc-editor.org/info/rfc3249>。
[RFC3501] Crispin, M.（克里斯平），《Internet 消息访问协议 - 第 4rev1 版（INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1）》，RFC 3501，DOI 10.17487/RFC3501，2003 年 3 月，<http://www.rfc-editor.org/info/rfc3501>。
[RFC3801] Vaudreuil, G. 与 G. Parsons（沃德勒伊与帕森斯），《Internet 邮件语音配置 - 第 2 版（VPIMv2）》，RFC 3801，DOI 10.17487/RFC3801，2004 年 6 月，<http://www.rfc-editor.org/info/rfc3801>。
[RFC5233] Murchison, K.（默奇森），《Sieve 电子邮件过滤：子地址扩展》，RFC 5233，DOI 10.17487/RFC5233，2008 年 1 月，<http://www.rfc-editor.org/info/rfc5233>。
[RFC5226] Narten, T. 与 H. Alvestrand（纳滕与阿尔韦斯特兰），《在 RFC 中编写 IANA 考虑章节的指南》，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008 年 5 月，<http://www.rfc-editor.org/info/rfc5226>。
[RFC5429] Stone, A.（斯通，编），《Sieve 电子邮件过滤：拒绝与扩展拒绝扩展》，RFC 5429，DOI 10.17487/RFC5429，2009 年 3 月，<http://www.rfc-editor.org/info/rfc5429>。
[RFC5598] Crocker, D.（克罗克），《Internet 邮件体系结构》，RFC 5598，DOI 10.17487/RFC5598，2009 年 7 月，<http://www.rfc-editor.org/info/rfc5598>。
[RFC6533] Hansen, T.（汉森，编）、Newman, C. 与 A. Melnikov（纽曼与梅尔尼科夫），《国际化的投递状态与处置通知》，RFC 6533，DOI 10.17487/RFC6533，2012 年 2 月，<http://www.rfc-editor.org/info/rfc6533>。
[X.400] International Telecommunications Union（国际电信联盟），《消息处理系统与服务概述》，ITU-T 建议 F.400/X.400，1999 年 6 月。

附录 A. 与 RFC 3798 的差异

将不同子注册表的 IANA 注册策略改为 "Specification Required"，以与 IANA 已使用的策略一致。
更新了 message/disposition-notification 的 IANA 注册模板。
"X-" 字段不再保留用于实验性用途，现在可以依据 RFC 6648 进行注册。
修正了 "MDN-Gateway" 中使用的默认 MTA-name-type，改为 "dns"。
加强了对取得用户同意以保护用户隐私的要求。
移除了关于在 MDN 中使用源路由（source route）的讨论，因为源路由是一项已废弃的电子邮件特性。
"dispatched" 和 "processed" 的取值在 "disposition-type" 的 ABNF 中丢失了。（勘误 #691）
因为 warning disposition 修饰符先前已被移除，warning-field 也随之移除。（勘误 #692）
因为 failed disposition 类型先前已被移除，failure-field 也随之移除。
ua-name 和 ua-product 的 ABNF 包含了分号，无法与产生式中的 *text 区分。ua-name 被限制为不包含分号。分号仍可以出现在 ua-product 中。
移除了在 "Reporting-UA" MDN 字段中包含 MUA DNS 主机名的建议。
ABNF 未指明所有允许空白的位置，特别是折叠空白（folding whitespace），尽管所有实现都像任何其他按 RFC-MSGFMT [RFC5322] 描述的格式化的信头字段一样允许空白和折叠。ABNF 中还有若干处不一致地在一个分支中允许注释和空白、在另一个分支中却不允许。ABNF 现在在若干本应由文法指定的地方指定了 FWS 和 CFWS。
Extension-field 在收集的文法中定义过，但未在主文中定义。
澄清了 Disposition-Notification-To 与 Return-Path 的 addr-spec 的比较。
术语 "parameter" 的文法产生式与 RFC 2045 [RFC2045] 的同名产生式以及其他同名用法相混淆。这些已得到澄清。
添加了对 MDN 的 7bit 性质的程度的澄清。
澄清了 "may" 和 "might" 用语的使用。
添加了对 message/disposition-notification 内容中字段顺序的澄清。

致谢（Acknowledgements）

衷心感谢 Bruce Lilly、Alfred Hoenes、Barry Leiba、Ben Campbell、Pete Resnick、Donald Eastlake 和 Alissa Cooper 对本修订版所作的贡献。

也衷心感谢 Roger Fajman 和 Greg Vaudreuil 对本文档早期草案版本所作的贡献。

作者地址（Authors' Addresses）

Tony Hansen（编辑）
AT&T Laboratories
200 Laurel Ave. South
Middletown, NJ 07748
United States of America

Email: tony@att.com

Alexey Melnikov（编辑）
Isode Ltd
14 Castle Mews
Hampton, Middlesex TW12 2NP
United Kingdom

Email: Alexey.Melnikov@isode.com