Network Working Group E. Allman
Request for Comments: 3886 Sendmail, Inc.
Updates: 3463 September 2004
Category: Standards Track
Network Working Group E. Allman
Request for Comments: 3886 Sendmail, Inc.
Updates: 3463 September 2004
Category: Standards Track
An Extensible Message Format for Message Tracking Responses
用于消息跟踪响应的可扩展消息格式
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
Message Tracking is expected to be used to determine the status of undelivered e-mail upon request. Tracking is used in conjunction with Delivery Status Notifications (DSN) and Message Disposition Notifications (MDN); generally, a message tracking request will be issued only when a DSN or MDN has not been received within a reasonable timeout period.
邮件跟踪预计用于根据请求确定未送达电子邮件的状态。跟踪与传递状态通知（DSN）和消息处置通知（MDN）一起使用；通常，只有在合理的超时时间内未收到DSN或MDN时，才会发出消息跟踪请求。
This memo defines a MIME content-type for message tracking status in the same spirit as RFC 3464, "An Extensible Message Format for Delivery Status Notifications". It is to be issued upon a request as described in "Message Tracking Query Protocol". This memo defines only the format of the status information. An extension to SMTP to label messages for further tracking and request tracking status is defined in a separate memo.
此备忘录定义了邮件跟踪状态的MIME内容类型，其精神与RFC 3464“传递状态通知的可扩展邮件格式”相同。它将根据“消息跟踪查询协议”中所述的请求发出。此备忘录仅定义状态信息的格式。SMTP的扩展，用于标记邮件以便进一步跟踪和请求跟踪状态，在单独的备忘录中定义。
Message Tracking is expected to be used to determine the status of undelivered e-mail upon request. Tracking is used in conjunction with Delivery Status Notifications (DSN) [RFC-DSN-SMTP] and Message Disposition Notifications (MDN) [RFC-MDN]; generally, a message tracking request will be issued only when a DSN or MDN has not been received within a reasonable timeout period.
邮件跟踪预计用于根据请求确定未送达电子邮件的状态。跟踪与传递状态通知（DSN）[RFC-DSN-SMTP]和邮件处置通知（MDN）[RFC-MDN]一起使用；通常，只有在合理的超时时间内未收到DSN或MDN时，才会发出消息跟踪请求。
This memo defines a MIME [RFC-MIME] content-type for message tracking status in the same spirit as RFC 3464, "An Extensible Message Format for Delivery Status Notifications" [RFC-DSN-STAT]. It is to be issued upon a request as described in "Message Tracking Query Protocol" [RFC-MTRK-MTQP]. This memo defines only the format of the status information. An extension to SMTP [RFC-ESMTP] to label messages for further tracking and request tracking status is defined in a separate memo [RFC-MTRK-SMTPEXT].
此备忘录定义了邮件跟踪状态的MIME[RFC-MIME]内容类型，其精神与RFC 3464“传递状态通知的可扩展邮件格式”[RFC-DSN-STAT]相同。它将根据“消息跟踪查询协议”[RFC-MTRK-MTQP]中所述的请求发布。此备忘录仅定义状态信息的格式。SMTP[RFC-ESMTP]的扩展，用于标记邮件以便进一步跟踪和请求跟踪状态，在单独的备忘录[RFC-MTRK-SMTPEXT]中定义。
The model used for Message Tracking is described in [RFC-MTRK-MODEL].
[RFC-MTRK-model]中描述了用于消息跟踪的模型。
Message tracking is intended for use as a "last resort" mechanism. Normally, Delivery Status Notifications (DSNs) [RFC-DSN-SMTP] and Message Disposition Notifications (MDNs) [RFC-MDN] would provide the primary delivery status. Only if no response is received from either of these mechanisms would Message Tracking be used.
消息跟踪旨在用作“最后手段”机制。通常，传递状态通知（DSN）[RFC-DSN-SMTP]和邮件处置通知（MDN）[RFC-MDN]将提供主传递状态。只有当没有从这些机制中的任何一个收到响应时，才会使用消息跟踪。
This document is based on [RFC-DSN-STAT]. Sections 1.3 (Terminology), 2.1.1 (General conventions for DSN fields), 2.1.2 ("*-type" subfields), and 2.1.3 (Lexical tokens imported from RFC 822) of [RFC-DSN-STAT] are included into this document by reference. Other sections are further incorporated as described herein.
本文件基于[RFC-DSN-STAT]。[RFC-DSN-STAT]的第1.3节（术语）、第2.1.1节（DSN字段的一般约定）、第2.1.2节（“*-类型”子字段）和第2.1.3节（从RFC 822导入的词汇标记）通过引用包含在本文件中。如本文所述，进一步并入其它部分。
Syntax notation in this document conforms to [RFC-ABNF].
本文件中的语法符号符合[RFC-ABNF]。
The following lexical tokens, defined in [RFC-MSGFMT], are used in the ABNF grammar for MTSNs: atom, CHAR, comment, CR, CRLF, DIGIT, LF, linear-white-space, SPACE, text. The date-time lexical token is defined in [RFC-HOSTREQ].
[RFC-MSGFMT]中定义的以下词汇标记用于MTSN的ABNF语法：原子、字符、注释、CR、CRLF、数字、LF、线性空白、空格、文本。日期-时间词汇标记在[RFC-HOSTREQ]中定义。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC-KEYWORDS].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC-关键词]中的描述进行解释。
A Message Tracking Status Notification (MTSN) is intended to be returned as the body of a Message Tracking request [RFC-MTRK-MTQP]. The actual body MUST be a multipart/related [RFC-RELATED] with type parameter of "message/tracking-status"; each subpart MUST be of type "message/tracking-status" as described herein. The multipart/related body can include multiple message/tracking-status parts if an MTQP server chains requests to the next server; see [RFC-MTRK-MODEL] and [RFC-MTRK-MTQP] for more information about chaining.
消息跟踪状态通知（MTSN）将作为消息跟踪请求[RFC-MTRK-MTQP]的主体返回。实际主体必须是类型参数为“消息/跟踪状态”的多部分/相关[RFC-related]；每个子部分必须为本文所述的“消息/跟踪状态”类型。如果MTQP服务器将请求链接到下一个服务器，则多部分/相关主体可以包括多个消息/跟踪状态部分；有关链接的更多信息，请参见[RFC-MTRK-MODEL]和[RFC-MTRK-MTQP]。
The message/tracking-status content-type is defined as follows:
消息/跟踪状态内容类型定义如下：
MIME type name: message MIME subtype name: tracking-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类型名称：消息MIME子类型名称：跟踪状态可选参数：无编码注意事项：“7bit”编码已足够，必须用于在非MIME邮件阅读器查看时保持可读性。安全注意事项：在本备忘录第4节中讨论。
The body of a message/tracking-status is modeled after [RFC-DSN-STAT]. That body consists of one or more "fields" formatted to according to the ABNF of RFC 2822 header "fields" (see [RFC-MSGFMT]). The per-message fields appear first, followed by a blank line. Following the per-message fields are one or more groups of per-recipient fields. Each group of per-recipient fields is preceded by a blank line. Note that there will be a blank line between the final per-recipient field and the MIME boundary, since one CRLF is necessary to terminate the field, and a second is necessary to introduce the MIME boundary. Formally, the syntax of the message/tracking-status content is as follows:
消息/跟踪状态的主体按照[RFC-DSN-STAT]建模。该正文由一个或多个“字段”组成，根据RFC 2822标题“字段”的ABNF进行格式化（参见[RFC-MSGFMT]）。每条消息字段首先显示，然后是一个空行。每封邮件字段后面是一组或多组每收件人字段。每组每个收件人字段前面都有一个空行。请注意，最终的每个收件人字段和MIME边界之间将有一个空行，因为需要一个CRLF来终止该字段，需要第二个CRLF来引入MIME边界。形式上，消息/跟踪状态内容的语法如下：
tracking-status-content = per-message-fields 1*( CRLF per-recipient-fields )
跟踪状态内容=每个邮件字段1*（每个收件人字段的CRLF）
The per-message fields are described in section 3.2. The per-recipient fields are described in section 3.3.
第3.2节描述了每条消息的字段。第3.3节介绍了每个收件人字段。
Section 2.1.1 (General conventions for DSN fields) of [RFC-DSN-STAT] is included herein by reference. Notably, the definition of xtext is identical to that of that document.
[RFC-DSN-STAT]的第2.1.1节（DSN字段的一般约定）通过引用包含在本文中。值得注意的是，xtext的定义与该文档的定义相同。
Section 2.1.2 (*-type subfields) of [RFC-DSN-STAT] is included herein by reference. Notably, the definitions of address-type, diagnostic-type, and MTA-name type are identical to that of RFC 3464.
[RFC-DSN-STAT]的第2.1.2节（*-类型子字段）通过引用包含在本文中。值得注意的是，地址类型、诊断类型和MTA名称类型的定义与RFC 3464的定义相同。
Some fields of an MTSN apply to all of the addresses in a single envelope. These fields may appear at most once in any MTSN. These fields are used to correlate the MTSN with the original message transaction and to provide additional information which may be useful to gateways.
MTSN的某些字段适用于单个信封中的所有地址。这些字段在任何MTSN中最多出现一次。这些字段用于将MTSN与原始消息事务关联，并提供可能对网关有用的附加信息。
per-message-fields = original-envelope-id-field CRLF reporting-mta-field CRLF arrival-date-field CRLF *( extension-field CRLF )
每封邮件字段=原始信封id字段CRLF报告mta字段CRLF到达日期字段CRLF*（扩展字段CRLF）
The Original-Envelope-Id field is defined as in section 2.2.1 of [RFC-DSN-STAT]. This field is REQUIRED.
原始信封Id字段的定义见[RFC-DSN-STAT]第2.2.1节。此字段必填。
The Reporting-MTA field is defined as in section 2.2.2 of [RFC-DSN-STAT]. This field is REQUIRED.
报告MTA字段的定义见[RFC-DSN-STAT]第2.2.2节。此字段必填。
The Arrival-Date field is defined as in section 2.2.5 of [RFC-DSN-STAT]. This field is REQUIRED.
到达日期字段的定义见[RFC-DSN-STAT]第2.2.5节。此字段必填。
An MTSN contains information about attempts to deliver a message to one or more recipients. The delivery information for any particular recipient is contained in a group of contiguous per-recipient fields. Each group of per-recipient fields is preceded by a blank line.
MTSN包含有关尝试将邮件传递给一个或多个收件人的信息。任何特定收件人的传递信息都包含在一组连续的每个收件人字段中。每组每个收件人字段前面都有一个空行。
The syntax for the group of per-recipient fields is as follows:
每个收件人字段组的语法如下所示：
per-recipient-fields =
original-recipient-field CRLF
final-recipient-field CRLF
action-field CRLF
status-field CRLF
[ remote-mta-field CRLF ]
[ last-attempt-date-field CRLF ]
[ will-retry-until-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 ]
[ last-attempt-date-field CRLF ]
[ will-retry-until-field CRLF ]
*( extension-field CRLF )
The Original-Recipient field is defined as in section 2.3.1 of [RFC-DSN-STAT]. This field is REQUIRED.
原始收件人字段的定义见[RFC-DSN-STAT]第2.3.1节。此字段必填。
The required Final-Recipient field is defined as in section 2.3.2 of [RFC-DSN-STAT]. This field is REQUIRED.
所需的最终收件人字段定义见[RFC-DSN-STAT]第2.3.2节。此字段必填。
The required Action field indicates the action performed by the Reporting-MTA as a result of its attempt to deliver the message to this recipient address. This field MUST be present for each recipient named in the MTSN. The syntax is as defined in RFC 3464. This field is REQUIRED.
required Action（必需操作）字段表示报告MTA尝试将邮件传递到此收件人地址时执行的操作。对于MTSN中指定的每个收件人，此字段必须存在。语法如RFC 3464中所定义。此字段必填。
Valid actions are:
有效措施包括：
failed The message could not be delivered. If DSNs have been enabled, a "failed" DSN should already have been returned.
失败消息无法传递。如果已启用DSN，则应已返回“失败”DSN。
delayed The message is currently waiting in the MTA queue for future delivery. Essentially, this action means "the message is located, and it is here."
延迟邮件当前正在MTA队列中等待将来的传递。本质上，此操作意味着“消息已定位，且在此处”
delivered The message has been successfully delivered to the final recipient. This includes "delivery" to a mailing list exploder. It does not indicate that the message has been read. No further information is available; in particular, the tracking agent SHOULD NOT attempt further "downstream" tracking requests.
已传递消息已成功传递给最终收件人。这包括“传递”到邮件列表爆炸器。它并不表示消息已被读取。没有进一步的资料；特别是，跟踪代理不应尝试进一步的“下游”跟踪请求。
expanded The message has been successfully delivered to the recipient address as specified by the sender, and forwarded by the Reporting-MTA beyond that destination to multiple additional recipient addresses. However, these additional addresses are not trackable, and the tracking agent SHOULD NOT attempt further "downstream" tracking requests.
扩展邮件已成功传递到发件人指定的收件人地址，并由报告MTA转发到该目标以外的多个其他收件人地址。但是，这些附加地址不可跟踪，并且跟踪代理不应尝试进一步的“下游”跟踪请求。
relayed The message has been delivered into an environment that does not support message tracking. No further information is available; in particular, the tracking agent SHOULD NOT attempt further "downstream" tracking requests.
中继消息已传递到不支持消息跟踪的环境中。没有进一步的资料；特别是，跟踪代理不应尝试进一步的“下游”跟踪请求。
transferred The message has been transferred to another MTRK-compliant MTA. The tracking agent SHOULD attempt further "downstream" tracking requests unless that information is already given in a chaining response.
已传输消息已传输到另一个符合MTRK的MTA。跟踪代理应该尝试进一步的“下游”跟踪请求，除非链接响应中已经给出了该信息。
opaque The message may or may not have been seen by this system. No further information is available or forthcoming.
不透明此系统可能已看到或未看到此消息。没有进一步的信息可用或即将提供。
There may be some confusion between when to use "expanded" versus "delivered". Whenever possible, "expanded" should be used when the MTA knows that the message will be sent to multiple addresses. However, in some cases the delivery occurs to a program which, unknown to the MTA, causes mailing list expansion; in the extreme case, the delivery may be to a real mailbox that has the side effect of list expansion. If the MTA cannot ensure that this delivery will cause list expansion, it should set the action to "delivered".
在何时使用“扩展”与“交付”之间可能存在一些混淆。当MTA知道邮件将发送到多个地址时，应尽可能使用“扩展”。但是，在某些情况下，传递发生在MTA未知的程序上，导致邮件列表扩展；在极端情况下，传递可能是到具有列表扩展副作用的真实邮箱。如果MTA无法确保此传递将导致列表扩展，则应将操作设置为“已传递”。
The Status field is defined as in RFC 3464. A new code is added to RFC 3463 [RFC-EMSSC], "Enhanced Mail System Status Codes",
状态字段的定义如RFC 3464所示。RFC 3463[RFC-EMSSC]中添加了一个新代码，“增强邮件系统状态代码”，
X.1.9 Message relayed to non-compliant mailer"
X.1.9 转发到不符合要求的邮件发送程序的邮件”
The mailbox address specified was valid, but the message has been relayed to a system that does not speak this protocol; no further information can be provided.
指定的邮箱地址有效，但邮件已中继到不使用此协议的系统；无法提供进一步信息。
A 2.1.9 Status field MUST be used exclusively with a "relayed" Action field. This field is REQUIRED.
2.1.9状态字段必须专用于“中继”动作字段。此字段必填。
The Remote-MTA field is defined as in section Reference 2.3.5 of [RFC-DSN-STAT]. This field MUST NOT be included if no delivery attempts have been made or if the Action field has value "opaque". If delivery to some agent other than an MTA (for example, a Local Delivery Agent) then this field MAY be included, giving the name of the host on which that agent was contacted.
远程MTA字段的定义见[RFC-DSN-STAT]的参考2.3.5节。如果未进行任何传递尝试，或者如果操作字段的值为“不透明”，则不得包含此字段。如果传递到MTA以外的某个代理（例如，本地传递代理），则可能会包含此字段，并提供与该代理联系的主机的名称。
The Last-Attempt-Date field is defined as in section Reference 2.3.7 of [RFC-DSN-STAT]. This field is REQUIRED if any delivery attempt has been made and the Action field does not have value "opaque", in which case it will specify when it last attempted to deliver this message to another MTA or other Delivery Agent. This field MUST NOT be included if no delivery attempts have been made.
最后一次尝试日期字段的定义见[RFC-DSN-STAT]第2.3.7节。如果已进行任何传递尝试，且“操作”字段没有值“不透明”，则此字段是必需的，在这种情况下，它将指定上次尝试将此邮件传递给其他MTA或其他传递代理的时间。如果未尝试传递，则不得包含此字段。
The Will-Retry-Until field is defined as in section Reference 2.3.9 of [RFC-DSN-STAT]. If the message is not in the local queue or the Action field has the value "opaque" the Will-Retry-Until field MUST NOT be included; otherwise, this field SHOULD be included.
该字段将重试，直到定义为[RFC-DSN-STAT]第2.3.9节中的字段。如果消息不在本地队列中或操作字段的值为“不透明”，则将重试，直到字段不能包括在内；否则，应包括此字段。
Future extension fields may be defined as defined in section 2.4 of [RFC-DSN-STAT].
未来扩展字段的定义见[RFC-DSN-STAT]第2.4节。
A message that has been delivered to a Local Delivery Agent (LDA) that understands message tracking (in particular, an LDA speaking LMTP [RFC-LMTP] that supports the MTRK extension) SHOULD pass the tracking request to the LDA. In this case, the Action field for the MTA->LDA exchange will look the same as a transfer to a compliant MTA; that is, a "transferred" tracking status will be issued.
已交付给理解消息跟踪的本地传递代理（LDA）（尤其是支持MTRK扩展的讲LDA的LMTP[RFC-LMTP]）的消息应将跟踪请求传递给LDA。在这种情况下，MTA->LDA exchange的操作字段看起来与传输到兼容MTA的操作字段相同；也就是说，将发布“已转移”跟踪状态。
Malicious servers may attempt to subvert message tracking and return false information. This could result in misdirection or misinterpretation of results.
恶意服务器可能试图破坏邮件跟踪并返回错误信息。这可能导致对结果的误导或误解。
Another dimension of security is confidentiality. There may be cases in which a message recipient is autoforwarding messages but does not wish to divulge the address to which the messages are autoforwarded. The desire for such confidentiality will probably be heightened as "wireless mailboxes", such as pagers, become more widely used as autoforward addresses.
安全的另一个方面是保密性。可能存在这样的情况：邮件收件人正在自动转发邮件，但不希望泄露邮件自动转发到的地址。随着寻呼机等“无线邮箱”越来越广泛地用作自动转发地址，对此类保密性的要求可能会提高。
MTA authors are encouraged to provide a mechanism which enables the end user to preserve the confidentiality of a forwarding address. Depending on the degree of confidentiality required, and the nature of the environment to which a message were being forwarded, this might be accomplished by one or more of:
鼓励MTA作者提供一种机制，使最终用户能够保护转发地址的机密性。根据所需的保密程度以及消息转发到的环境的性质，这可以通过以下一种或多种方式实现：
(a) respond with a "relayed" tracking status when a message is forwarded to a confidential forwarding address, and disabling further message tracking requests.
(a) 当邮件转发到机密转发地址时，以“中继”跟踪状态响应，并禁用进一步的邮件跟踪请求。
(b) declaring the message to be delivered, issuing a "delivered" tracking status, re-sending the message to the confidential forwarding address, and disabling further message tracking requests.
(b) 声明要传递的邮件，发出“已传递”跟踪状态，将邮件重新发送到机密转发地址，并禁用进一步的邮件跟踪请求。
The tracking algorithms MUST NOT allow tracking through list expansions. When a message is delivered to a list, a tracking request MUST respond with an "expanded" tracking status and MUST NOT display the contents of the list.
跟踪算法不得允许通过列表扩展进行跟踪。将消息传递到列表时，跟踪请求必须以“扩展”跟踪状态响应，并且不得显示列表的内容。
IANA has registered the SMTP extension defined in section 3.
IANA已注册第3节中定义的SMTP扩展名。
Several individuals have commented on and enhanced this document, including Tony Hansen, Philip Hazel, Alexey Melnikov, Lyndon Nerenberg, Chris Newman, Gregory Neil Shapiro, and Dan Wing.
几个人对本文件进行了评论和改进，包括Tony Hansen、Philip Hazel、Alexey Melnikov、Lyndon Nerenberg、Chris Newman、Gregory Neil Shapiro和Dan Wing。
[RFC-MTRK-MODEL] Hansen, T., "Message Tracking Model and Requirements", RFC 3888, September 2004.
[RFC-MTRK-MODEL]Hansen，T，“消息跟踪模型和需求”，RFC 3888，2004年9月。
[RFC-MTRK-MTQP] Hansen, T., "Message Tracking Query Protocol", RFC 3887, September 2004.
[RFC-MTRK-MTQP]Hansen，T，“消息跟踪查询协议”，RFC 3887，2004年9月。
[RFC-MTRK-SMTPEXT] Allman, E., "SMTP Service Extension for Message Tracking", RFC 3885, September 2004.
[RFC-MTRK-SMTPEXT]Allman，E.“用于邮件跟踪的SMTP服务扩展”，RFC 38852004年9月。
[RFC-ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC-ABNF]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[RFC-EMSSC] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[RFC-EMSSC]Vaudreuil，G.“增强邮件系统状态代码”，RFC 3463，2003年1月。
[RFC-HOSTREQ] Braden, R., Ed., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[RFC-HOSTREQ]Braden，R.，编辑，“互联网主机的要求——应用和支持”，STD 3，RFC 1123，1989年10月。
[RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC-MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC-MIME]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC-MSGFMT] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[RFC-MSGFMT]Resnick，P.，Ed.“互联网信息格式”，RFC 2822，2001年4月。
[RFC-RELATED] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
[RFC-相关]Levinson，E.“MIME多部分/相关内容类型”，RFC 2387，1998年8月。
[RFC-DSN-SMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[RFC-DSN-SMTP]Moore，K.，“用于传递状态通知（DSN）的简单邮件传输协议（SMTP）服务扩展”，RFC 34612003年1月。
[RFC-DSN-STAT] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[RFC-DSN-STAT]Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 3464，2003年1月。
[RFC-ESMTP] Rose, M., Stefferud, E., Crocker, D., Klensin, J., and N. Freed, "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
[RFC-ESMTP]Rose，M.，Stefferud，E.，Crocker，D.，Klensin，J.，和N.Freed，“SMTP服务扩展”，STD 10，RFC 18691995年11月。
[RFC-LMTP] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996.
[RFC-LMTP]迈尔斯，J.，“本地邮件传输协议”，RFC 2033，1996年10月。
[RFC-MDN] Hansen, T. and G. Vaudreuil, Eds., "Message Disposition Notifications", RFC 3798, May 2004.
[RFC-MDN]Hansen，T.和G.Vaudreuil，编辑，“消息处置通知”，RFC 3798，2004年5月。
Eric Allman Sendmail, Inc. 6425 Christie Ave, 4th Floor Emeryville, CA 94608 U.S.A.
Eric Allman Sendmail，Inc.美国加利福尼亚州埃默里维尔克里斯蒂大道6425号4楼，邮编94608。
Phone: +1 510 594 5501
Fax: +1 510 594 5429
EMail: eric@Sendmail.COM
Phone: +1 510 594 5501
Fax: +1 510 594 5429
EMail: eric@Sendmail.COM
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、其代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。