Network Working Group D. Newman
Request for Comments: 2852 Sun Microsystems
Updates: 1894 June 2000
Category: Standards Track
Network Working Group D. Newman
Request for Comments: 2852 Sun Microsystems
Updates: 1894 June 2000
Category: Standards Track
Deliver By SMTP Service Extension
通过SMTP服务扩展传递
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This memo defines a mechanism whereby a SMTP client can request, when transmitting a message to a SMTP server, that the server deliver the message within a prescribed period of time. A client making such a request also specifies the message handling which is to occur if the message cannot be delivered within the specified time period: either the message is to be returned as undeliverable with no further processing, or a "delayed" delivery status notification (DSN) [6] is to be issued.
此备忘录定义了一种机制，SMTP客户端可以在向SMTP服务器传输邮件时请求服务器在指定的时间段内传递邮件。发出此类请求的客户端还指定了在指定时间段内无法传递消息时将发生的消息处理：要么将消息返回为无法传递，而无需进一步处理，要么将发出“延迟”传递状态通知（DSN）[6]。
This extension should not be viewed as a vehicle for requesting "priority" processing. A receiving SMTP server may assign whatever processing priority it wishes to a message transmitted with a Deliver By request. A Deliver By request serves to express a message's urgency and to provide an additional degree of determinancy in its processing. An indication of an urgent message's status within a given time period may be requested and will be honored. Moreover, the message may be withdrawn if not delivered within that time period.
此扩展不应被视为请求“优先级”处理的工具。接收SMTP服务器可以将其希望的任何处理优先级分配给通过“传递方式”请求传输的邮件。“按请求传递”用于表示消息的紧急性，并在处理过程中提供额外的确定性。在给定的时间段内，可能会请求指示紧急消息的状态，并将予以遵守。此外，如果未在该时间段内递送，则可撤回该消息。
A typical usage of this mechanism is to prevent delivery of a message beyond some future time of significance to the sender or recipient but not known by the MTAs handling the message. For instance, the sender may know that the message will be delivered as a page but does not consider the message to be sufficiently important as to warrant paging the recipient after business hours. In that case, the message could be marked such that delivery attempts are not made beyond
此机制的一个典型用法是防止邮件的传递超过对发件人或收件人具有重要意义但处理邮件的MTA不知道的未来时间。例如，发送者可能知道消息将作为页面传递，但不认为消息足够重要，以保证在营业时间后对接收者进行寻呼。在这种情况下，可以对消息进行标记，以便在超出范围后不会进行传递尝试
17:00. Another common usage arises when a sender wishes to be alerted to delivery delays. In this case, the sender can mark a message such that if it is not delivered within, say, 30 minutes, a "delayed" DSN is generated but delivery attempts are nonetheless continued. In this case the sender has been allowed to express a preference for when they would like to learn of delivery problems.
17:00. 另一种常见用法是，当发送者希望收到发送延迟的警报时。在这种情况下，发送方可以标记消息，这样，如果消息未在（比如）30分钟内送达，则会生成“延迟”DSN，但仍会继续进行送达尝试。在这种情况下，发送者被允许在他们希望了解交货问题的时间表达偏好。
Throughout this document, the term "deliver" is taken to mean the act of transmitting a message to its "final" destination by a message transport agent (MTA). Usually, but not always, this means storing or otherwise handing off the message to the recipient's mailbox. Thus, an MTA which accepts a message to be delivered within a specified time period is agreeing to store or handoff the message to the recipient's mailbox within the specified time period. Outside the scope of the term "deliver" are any user-specified actions which might take place after the MTA stores or hands off the message; e.g., user-programmed filters which, often unbeknownst to the MTA, resend the message to some other location.
在本文档中，“传递”一词指的是通过邮件传输代理（MTA）将邮件传输到其“最终”目的地的行为。通常，但并非总是，这意味着存储或以其他方式将邮件传递到收件人的邮箱。因此，如果MTA接受在指定时间段内传递的邮件，则表示MTA同意在指定时间段内将邮件存储或切换到收件人的邮箱。在术语“传递”的范围之外的是MTA存储或传递邮件后可能发生的任何用户指定的操作；e、 例如，用户编程的过滤器，MTA通常不知道，将邮件重新发送到其他位置。
The key words "MUST", "MUST NOT", "SHOULD" and "SHOULD NOT" in this document are to be interpreted as described in RFC 2119 [7].
本文件中的关键词“必须”、“不得”、“应该”和“不应该”应按照RFC 2119[7]中的说明进行解释。
The Deliver By SMTP service extension uses the SMTP service extension mechanism described in [4]. The following SMTP service extension is therefore defined:
“通过SMTP传递”服务扩展使用[4]中描述的SMTP服务扩展机制。因此定义了以下SMTP服务扩展：
(1) The name of the SMTP service extension is "Deliver By".
(1) SMTP服务扩展名为“传送者”。
(2) The EHLO keyword value associated with this service extension is "DELIVERBY".
(2) 与此服务扩展关联的EHLO关键字值为“DELIVERBY”。
(3) One optional parameter is allowed with this EHLO keyword value. The optional parameter, when supplied, is a comma separated list of options. Only one option, a min-by-time, is specified in this document. Future documents may extend this specification by specifying additional options. The min-by-time is a fixed integer indicating the fixed minimum by-time that the server will accept when a by-mode of "R" is specified as per Section 4.
(3) 此EHLO关键字值允许使用一个可选参数。提供的可选参数是以逗号分隔的选项列表。本文档中只指定了一个选项，即时间最小值。将来的文档可能会通过指定其他选项来扩展本规范。min by time是一个固定整数，表示当根据第4节指定by模式为“R”时，服务器将接受的固定最小by time。
The syntax of the optional parameter is as follows, using the augmented BNF notation of RFC 2234 [2]:
使用RFC 2234[2]的增广BNF表示法，可选参数的语法如下所示：
deliverby-param = min-by-time *( ',' extension-token )
min-by-time = [1*9DIGIT]
extension-token = 1*<any CHAR excluding SP, COMMA and all control
characters (US ASCII 0-31 inclusive)>
SP = <the space character (ASCII decimal code 32)>
COMMA = <the comma character (ASCII decimal code 44)>
deliverby-param = min-by-time *( ',' extension-token )
min-by-time = [1*9DIGIT]
extension-token = 1*<any CHAR excluding SP, COMMA and all control
characters (US ASCII 0-31 inclusive)>
SP = <the space character (ASCII decimal code 32)>
COMMA = <the comma character (ASCII decimal code 44)>
If the parameter is omitted, no information is conveyed about the server's fixed minimum by-time.
如果省略该参数，则不会传递有关服务器的固定时间最小值的信息。
(4) One optional parameter using the keyword "BY" is added to the MAIL FROM command.
(4) 将使用关键字“BY”的一个可选参数添加到MAIL-FROM命令中。
(5) The maximum length of a MAIL FROM command line is increased by 17 characters by the possible addition of the BY keyword and value.
(5) 通过可能添加by关键字和值，来自命令行的邮件的最大长度增加了17个字符。
(6) No additional SMTP verbs are defined by this extension.
(6) 此扩展未定义其他SMTP谓词。
A SMTP client wishing to use the Deliver By SMTP service extension may issue the EHLO command to start a SMTP session and to determine if the SMTP server supports the service extension. If the server responds with code 250 to the EHLO command, and the response includes the EHLO keyword DELIVERBY, then the Deliver By SMTP service extension is supported by the server.
希望使用“通过SMTP传递”服务扩展的SMTP客户端可以发出EHLO命令来启动SMTP会话，并确定SMTP服务器是否支持该服务扩展。如果服务器以代码250响应EHLO命令，并且响应包含EHLO关键字DELIVERBY，则服务器支持通过SMTP传递服务扩展。
If a numeric parameter follows the DELIVERBY keyword value of the EHLO response then that parameter indicates the minimum value allowed for the by-time when a by-mode of "R" is specified with the extended MAIL FROM command as described in Section 4. Any attempt by a client to specify a by-mode of "R" and a by-time strictly less than this limit, min-by-time, will be rejected with a permanent failure (55z) reply code.
如果在EHLO响应的DELIVERBY关键字值之后有一个数字参数，则该参数表示当使用第4节中所述的扩展邮件发件人命令指定by模式“R”时，by允许的最小值。客户机试图将by模式指定为“R”，并将by时间指定为严格小于此限制的最小时间，将被拒绝，并显示永久性故障（55z）回复代码。
A SMTP server that supports the Deliver By SMTP service extension will accept the extended version of the MAIL FROM command described in Section 4. When supported by the server, a SMTP client may use the extended MAIL FROM command (instead of the MAIL FROM command described in [1]) to request that the message be delivered within the specified time period. The server may then return an appropriate error code if it determines that the request cannot be honored. Note that this may not be apparent to the server until either presentation of the recipient addresses with RCPT TO commands or completion of the transfer of the message data with the dot (.) command. As such, the
支持“通过SMTP传递”服务扩展的SMTP服务器将接受第4节中描述的“来自邮件”命令的扩展版本。当服务器支持时，SMTP客户端可以使用extended MAIL FROM命令（而不是[1]中描述的MAIL FROM命令）请求在指定的时间段内传递邮件。然后，如果服务器确定无法满足请求，则可能会返回相应的错误代码。请注意，在使用RCPT to命令显示收件人地址或使用dot（.）命令完成消息数据传输之前，服务器可能不清楚这一点。因此
server may send to the client a success response to the MAIL FROM command only to later return an error response to the RCPT TO, DATA, or dot command.
服务器可能只向客户机发送对MAIL FROM命令的成功响应，然后向RCPT to、DATA或dot命令返回错误响应。
The extended MAIL FROM command is issued by a SMTP client when it wishes to inform a SMTP server that a message is to be delivered within a specified period of time and further what action to take should the message prove undeliverable within that time period. The extended MAIL FROM command is identical to the MAIL FROM command as defined in RFC 821 [1], except that a BY parameter appears after the address.
当SMTP客户端希望通知SMTP服务器邮件将在指定的时间段内送达，并进一步通知如果邮件在该时间段内无法送达，应采取什么措施时，SMTP客户端将发出“扩展邮件发件人”命令。“扩展邮件发件人”命令与RFC 821[1]中定义的“邮件发件人”命令相同，只是在地址后显示了一个BY参数。
The complete syntax of this extended command is defined in [4]. The esmtp-keyword is "BY" and the syntax for the esmtp-value is given by the syntax for by-value shown below. In the augmented BNF of RFC 2234 [2], the syntax for the BY esmtp-parameter is
[4]中定义了此扩展命令的完整语法。esmtp关键字为“BY”，esmtp值的语法由下面显示的BY值的语法给出。在RFC 2234[2]的扩充BNF中，BY esmtp参数的语法为
by-parameter = "BY="by-value
by-value = by-time";"by-mode[by-trace]
by-time = ["-" / "+"]1*9digit ; a negative or zero value is not
; allowed with a by-mode of "R"
by-mode = "N" / "R" ; "Notify" or "Return"
by-trace = "T" ; "Trace"
by-parameter = "BY="by-value
by-value = by-time";"by-mode[by-trace]
by-time = ["-" / "+"]1*9digit ; a negative or zero value is not
; allowed with a by-mode of "R"
by-mode = "N" / "R" ; "Notify" or "Return"
by-trace = "T" ; "Trace"
Note that the BY esmtp-keyword MUST have an associated esmtp-value. The by-time is a decimal representation of the number of seconds within which the message should be delivered and has the range
请注意，BY esmtp关键字必须具有关联的esmtp值。by time（按时间）是一种十进制表示形式，表示应在几秒钟内传递消息，并且具有范围
-999,999,999 seconds <= by-time <= +999,999,999 seconds
-999,999,999 seconds <= by-time <= +999,999,999 seconds
and is thus sufficient to represent a time anywhere from approximately 31.6 years in the past to 31.6 years in the future.
因此，足以代表从过去约31.6年到未来31.6年的任何时间。
As described in Section 4.1, the by-mode indicates the action the SMTP server must take should it not be possible to transmit the message within by-time seconds.
如第4.1节所述，by模式表示如果无法在by时间秒内传输邮件，SMTP服务器必须采取的操作。
Note that by-time is a delta time: the number of seconds within which to deliver the message. This delta time does not extend an MTA's normal retention period for undeliverable messages nor is it a "deliver after" time.
请注意，by time是delta time：传递消息的秒数。此增量时间不会延长MTA对无法送达邮件的正常保留期，也不会延长“以后送达”时间。
A delta time is used so as to prevent problems associated with differences in system clocks between clients and servers. Servers in receipt of a valid by-parameter are expected to convert the by-time into a locale-specific absolute time called the deliver-by-time.
使用增量时间是为了防止与客户端和服务器之间的系统时钟差异相关的问题。接收到有效by参数的服务器需要将by time转换为特定于语言环境的绝对时间，称为delivery by time。
This is done by adding the by-time upon receipt to the current locale-specific time and thereby arriving at a locale-specific absolute time which is by-time seconds in the future or past, depending upon the arithmetic sign of by-time. The message is then to be delivered by the deliver-by-time. The sending client and receiving server should assume the transmission time of the MAIL FROM command to be instantaneous. Clearly, it will not be and network latency will introduce an error, the nature of which will be to extend slightly the effective by-time. The more hops the message takes, the more pronounced the effect will be owing to the cumulative nature of this latency-induced error.
这是通过将收到时的by time（按时间）添加到当前特定于区域设置的时间，从而得出特定于区域设置的绝对时间，即未来或过去的by time（按时间秒），具体取决于by time（按时间）的算术符号。然后，消息将由“按时间传递”传递。发送客户端和接收服务器应假定来自命令的邮件的传输时间是瞬时的。显然，这不会发生，网络延迟将引入错误，其性质是随着时间稍微延长有效时间。消息的跳数越大，由于这种由延迟引起的错误的累积性质，效果就越明显。
In the case of a by-mode of "N", it is possible that by-time may be zero or negative. This is not an error and should not be rejected as such. It indicates a message for which the deliver-by-time occurred -(by-time) seconds in the past. [Here, "-(by-time)" represents the arithmetic negation of the by-time value.] Zero and negative values are allowed so as to preserve information about any requested delivery time information -- information which the delivering MTA may wish to include with the delivered message for the benefit of the recipient or to show in a DSN or NDN (non delivery notification).
在by模式为“N”的情况下，by时间可能为零或负。这不是错误，因此不应拒绝。它表示一条消息，该消息的“按时间传递”发生在过去的-（按时间）秒。[此处，“-（按时间）”表示按时间值的算术求反。]允许使用零值和负值，以保留有关任何请求的传递时间信息的信息--传递MTA可能希望为了收件人的利益将这些信息包括在传递的邮件中，或在DSN或NDN中显示（未送达通知）。
In the case of a by-mode of "R", a zero or negative by-time is a syntax error. In such a case, the SMTP server SHOULD return a permanent failure (501) SMTP reply code in response to the extended MAIL FROM command. If the SMTP server also supports enhanced error codes [8], then an enhanced error code of 5.5.4 SHOULD also be returned.
在by模式为“R”的情况下，时间为零或负是语法错误。在这种情况下，SMTP服务器应返回一个永久故障（501）SMTP回复代码，以响应“扩展邮件发件人”命令。如果SMTP服务器还支持增强的错误代码[8]，则还应返回增强的错误代码5.5.4。
If the by-time is a valid by-time specification but the SMTP server cannot honor or accept it for a server-specific reason, then SMTP server SHOULD respond with either a 455 SMTP response if the condition is transient or a 555 SMTP response if the condition is permanent. In addition, if the SMTP server also supports [8], a suitable 4.X.X or 5.X.X enhanced error code SHOULD also be returned.
如果by time是有效的by time规范，但SMTP服务器由于特定于服务器的原因无法接受或接受该规范，则SMTP服务器应在条件为暂时时响应455 SMTP响应，或在条件为永久时响应555 SMTP响应。此外，如果SMTP服务器也支持[8]，则还应返回适当的4.X.X或5.X.X增强型错误代码。
Upon receipt of an extended MAIL FROM command containing a valid BY parameter, a SMTP server and associated MTA must handle the message in accord with the following subsections, Sections 4.1.1-4.1.5. Delivery status notifications generated in response to processing a message with a Deliver By request should include both the optional Arrival-Date DSN field as well as the new Deliver-By-Date DSN field described in Section 5 of this memo.
收到包含有效BY参数的扩展邮件FROM命令后，SMTP服务器和相关MTA必须按照以下小节第4.1.1-4.1.5节处理邮件。在处理带有“按送达请求”的邮件时生成的送达状态通知应包括可选的“到达日期DSN”字段以及本备忘录第5节中描述的新的“按送达日期DSN”字段。
A by-time Note that a message's by-time does not extend the MTA's normal message retention period: an MTA MAY return a message as undeliverable before the deliver-by-time has been reached.
按时间提示，邮件的“按时间”不会延长MTA的正常邮件保留期：MTA可能会在到达“按时间送达”之前返回无法送达的邮件。
If the message is delivered before deliver-by-time, no special action need be taken. If the SMTP server or MTA also supports the Delivery Status Notification SMTP service extension [5] and a NOTIFY parameter including "SUCCESS" was specified, a "delivered" DSN with appropriate status must be returned as per [5].
如果邮件在按时送达之前送达，则无需采取特殊措施。如果SMTP服务器或MTA还支持传递状态通知SMTP服务扩展[5]，并且指定了包含“成功”的通知参数，则必须按照[5]返回具有适当状态的“已传递”DSN。
If deliver-by-time has not yet passed and the message has proved undeliverable for temporary reasons, then the SMTP server or MTA should continue delivery or relay attempts as per the site's message handling policy. If the MTA's message retention period is less than by-time, the MTA MAY return the message as undeliverable before deliver-by-time has been reached. However, the message MUST still be handled in accord with Sections 4.1.1-4.1.5.
如果“按时间传递”尚未过去，并且由于临时原因无法传递邮件，则SMTP服务器或MTA应根据站点的邮件处理策略继续传递或中继尝试。如果MTA的邮件保留期小于“按时间”，MTA可能会在到达“按时间送达”之前将邮件返回为“无法送达”。但是，仍然必须按照第4.1.1-4.1.5节处理该消息。
If deliver-by-time has not yet passed and the message cannot be delivered for permanent reasons, then the SMTP server or MTA MUST return a "failed" DSN with an appropriate status for each recipient address with either no NOTIFY parameter specified or for which the NOTIFY parameter includes "FAILURE".
如果“按时间传递”尚未过去，并且由于永久原因无法传递邮件，则SMTP服务器或MTA必须为每个收件人地址返回一个“失败”DSN，该DSN具有适当的状态，并且未指定NOTIFY参数，或者NOTIFY参数包含“失败”。
If the message is not delivered or relayed before deliver-by-time and a by-mode of "R" was specified, no further delivery attempts may be made for the message. The server or MTA MUST issue a "failed" DSN with status 5.4.7, "delivery time expired", for each recipient address with either no NOTIFY parameter specified or for which the NOTIFY parameter includes "FAILURE".
如果在按时间交付之前未交付或中继消息，并且指定了“R”的按模式，则不能对消息进行进一步的交付尝试。对于未指定NOTIFY参数或NOTIFY参数包含“FAILURE”的每个收件人地址，服务器或MTA必须发出状态为5.4.7“delivery time expired”的“failed”DSN。
If the message is not delivered or relayed before deliver-by-time and a by-mode of "N" was specified, the server or MTA should continue attempts to deliver or relay the message using the site's message handling policy. In addition, the server or MTA MUST issue a "delayed" DSN with status 4.4.7, "delivery time expired", for each recipient address with either no NOTIFY parameter specified or for which the NOTIFY parameter includes "DELAY".
如果在按时间传递之前未传递或中继邮件，并且指定了“N”的按模式，则服务器或MTA应继续尝试使用站点的邮件处理策略传递或中继邮件。此外，对于未指定NOTIFY参数或NOTIFY参数包含“DELAY”的每个收件人地址，服务器或MTA必须发出状态为4.4.7的“delayed”DSN，“delivery time expired”。
Sections 4.1.4.1 and 4.1.4.2 below describe when a message with a Deliver By request may be relayed to another SMTP server and what additional actions, if any, should or must be taken. In addition to that discussed in those sections, the following must also be observed when relaying is permitted.
下面的第4.1.4.1和4.1.4.2节描述了带有“按请求传递”的邮件何时可以中继到另一个SMTP服务器，以及应该或必须采取哪些其他操作（如有）。除了这些章节中讨论的内容外，当允许继电保护时，还必须遵守以下内容。
If the message is relayed to a SMTP server that supports the Deliver By extension, a new BY parameter MUST be relayed specifying a by-time value indicating the number of seconds remaining until deliver-by-time. The new by-time value should be computed as close to the time the MAIL FROM command is transmitted by the relaying SMTP client as is reasonably possible. Note that if deliver-by-time has passed, the relayed by-time will be a negative value indicating how may seconds has elapsed since delivery-by-time. Such a case -- relay of a message for which deliver-by-time has just arrived or passed -- may only happen with a message that has a by-mode of "N".
如果将邮件中继到支持“按时间传递”扩展名的SMTP服务器，则必须中继一个新的“按时间传递”参数，该参数指定一个“按时间传递”值，该值指示在“按时间传递”之前剩余的秒数。新的“按时间”值的计算应尽可能接近中继SMTP客户端发送“邮件发件人”命令的时间。请注意，如果已通过“按时间传递”，则“按时间传递”将是一个负值，指示自“按时间传递”以来可能已经过的秒数。这种情况——Delivery by time刚刚到达或通过的消息的中继——可能只发生在by模式为“N”的消息中。
When a message with a by-trace field with value "T" is relayed, a "relayed" DSN SHOULD be generated by the relaying SMTP client for each recipient which either did not specify a NOTIFY parameter or the NOTIFY parameter does not have the value "NEVER".
中继具有值为“T”的by trace字段的邮件时，中继SMTP客户端应为未指定NOTIFY参数或NOTIFY参数没有值“NEVER”的每个收件人生成“中继”DSN。
Note that these "relayed" DSNs are generated regardless of whether success notifications were explicitly requested with a NOTIFY=SUCCESS parameter. Note further that the "relayed" DSNs discussed here are not terminal notifications: downstream SMTP servers and MTAs may still support [5] and as such additional notifications may still result.
请注意，无论是否使用NOTIFY=success参数明确请求成功通知，都会生成这些“中继”DSN。进一步注意，此处讨论的“中继”DSN不是终端通知：下游SMTP服务器和MTA可能仍然支持[5]，因此可能仍然会产生其他通知。
A message for which a by-mode of "R" was specified MUST NOT be relayed to a SMTP server which does not support the Deliver By SMTP service extension. Moreover, the server to which it is relayed MUST NOT have a fixed minimum by-time which is greater than the time remaining in which the message is to be delivered. The fixed minimum by-time is expressed by the optional deliverby-param discussed in Section 2.
为其指定了“R”的by模式的邮件不得中继到不支持“通过SMTP传递”服务扩展的SMTP服务器。此外，转发到的服务器不得具有固定的最小时间，该时间不得大于消息将在其中传递的剩余时间。时间固定最小值由第2节中讨论的可选deliverby参数表示。
If the message requires relaying in order to be delivered yet cannot be relayed, then the message is deemed to be undeliverable for permanent reasons and Section 4.1.2 should be applied.
如果信息需要中继才能交付，但无法中继，则该信息因永久原因被视为无法交付，应适用第4.1.2节。
A message with a by-mode of "N" may be relayed to another server regardless of whether or not the SMTP server to which it is relayed supports the Deliver By extension.
无论中继到的SMTP服务器是否支持“按扩展传递”，by模式为“N”的邮件都可以中继到另一台服务器。
If the message is relayed before deliver-by-time to a SMTP server that does not support the Deliver By extension, then the relaying SMTP client MUST issue a "relayed" DSN for each recipient which either did not specify a NOTIFY parameter or the NOTIFY parameter does not have the value "NEVER". Further, if the SMTP server being relayed to supports the Delivery Status Notification SMTP service extension [5] then for each recipient: if no NOTIFY parameter was supplied, "NOTIFY=FAILURE,DELAY" SHOULD be requested; if a NOTIFY parameter was specified and does not have the value "NEVER", "DELAY" SHOULD be added to the list of notify-list-element values if not already present. Note that this explicitly overrides the "MUST NOT" wording of Section 6.2.1(c) of [5].
如果在“按时间传递”之前将邮件中继到不支持“按扩展传递”的SMTP服务器，则中继SMTP客户端必须为未指定NOTIFY参数或NOTIFY参数没有值“从不”的每个收件人发出“中继”DSN。此外，如果中继到的SMTP服务器支持传递状态通知SMTP服务扩展[5]，则对于每个收件人：如果未提供NOTIFY参数，则应请求“NOTIFY=FAILURE，DELAY”；如果指定了NOTIFY参数且该参数没有值“NEVER”，“DELAY”应添加到NOTIFY list元素值列表中（如果尚未存在）。请注意，这明确覆盖了[5]第6.2.1（c）节中的“不得”措辞。
If the foreign mail system supports semantics similar to the Deliver By SMTP service extension described in this memo, then convey the Deliver By request to that system. Otherwise, relay the message as if relaying to a SMTP server which does not support the Deliver By extension.
如果外文邮件系统支持类似于本备忘录中描述的“通过SMTP传递”服务扩展的语义，则将“通过请求传递”传递给该系统。否则，将邮件中继到不支持“按扩展传递”的SMTP服务器。
The format of delivery status notifications (DSNs) is specified in [6]. DSNs generated in response to a Deliver By request should include an Arrival-Date DSN field. This memo also extends the per-message-fields of [6] to include a new DSN field, Deliver-By-Date, indicating the deliver-by-time as computed by the MTA or SMTP server generating the DSN. In the augmented BNF of RFC 822 [2], per-message-fields is therefore extended as follows:
[6]中规定了交付状态通知（DSN）的格式。响应交付请求生成的DSN应包括到达日期DSN字段。此备忘录还扩展了[6]中的每封邮件字段，以包括一个新的DSN字段“按日期交付”，指示生成DSN的MTA或SMTP服务器计算的按时间交付。因此，在RFC 822[2]的扩充BNF中，每消息字段扩展如下：
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 ]
[ deliver-by-date-field CRLF ]
*( extension-field CRLF )
deliver-by-date-field = "Deliver-by-date" ":" date-time
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 ]
[ deliver-by-date-field CRLF ]
*( extension-field CRLF )
deliver-by-date-field = "Deliver-by-date" ":" date-time
where date-time is a RFC 822 [2] date-time field as ammended by RFC 1123 [3].
其中，日期时间是RFC 822[2]日期时间字段，由RFC 1123[3]编辑。
In the following sample SMTP dialog, the SMTP client requests that a message from <eljefe@bigbiz.com> be delivered to <topbanana@other.com> within 2 minutes (120 seconds) and returned otherwise. This request takes the form of a BY parameter on the MAIL FROM line of "BY=120;R" as shown below:
在以下示例SMTP对话框中，SMTP客户端请求从<eljefe@bigbiz.com>交付<topbanana@other.com>在2分钟（120秒）内返回，否则返回。此请求采用邮件发件人行“BY=120；R”上的BY参数形式，如下所示：
S: 220 acme.net SMTP server here
C: EHLO bigbiz.com
S: 250-acme.net
S: 250 DELIVERBY
C: MAIL FROM:<eljefe@bigbiz.com> BY=120;R
S: 250 <eljefe@bigbiz.com> sender ok
C: RCPT TO:<topbanana@other.com>
S: 250 <topbanana@wherever.com> recipient ok
S: 220 acme.net SMTP server here
C: EHLO bigbiz.com
S: 250-acme.net
S: 250 DELIVERBY
C: MAIL FROM:<eljefe@bigbiz.com> BY=120;R
S: 250 <eljefe@bigbiz.com> sender ok
C: RCPT TO:<topbanana@other.com>
S: 250 <topbanana@wherever.com> recipient ok
Suppose now that the receiving SMTP server in the above example needs to relay the message to another SMTP server, mail.other.com. Owing to the original by-mode of "R", the message may only be relayed to another SMTP server which supports the Deliver By extension (Section 4.1.4). Further, when relaying the message, the Deliver By request must be relayed. With this in mind, consider the following SMTP dialog:
现在假设上述示例中的接收SMTP服务器需要将消息中继到另一个SMTP服务器mail.other.com。由于“R”的原始方式，邮件只能中继到另一个支持“按扩展传递”的SMTP服务器（第4.1.4节）。此外，在中继消息时，必须中继按请求传递。考虑到这一点，考虑下面的SMTP对话框：
S: 220 mail.other.com ESMTP server at your service
C: EHLO acme.net
S: 250-mail.other.com
S: 250 DELIVERBY 240
C: QUIT
S: 220 mail.other.com ESMTP server at your service
C: EHLO acme.net
S: 250-mail.other.com
S: 250 DELIVERBY 240
C: QUIT
In the above dialog, the relaying SMTP server, acme.net, connects to mail.other.com and issues an EHLO command. It then learns that the Deliver By extension is supported but that the minimum by-time for a by-mode of "R" is 4 minutes (240 seconds). This value exceeds the message's original by-time and therefore necessarily exceeds the remaining by-time. The relaying SMTP server thus ends the SMTP session after which it must either attempt to follow any other MX records or, if there are no more MX records to follow, must return the message as undeliverable. Similar behavior would result if the EHLO command was met with an error or did not include the DELIVERBY keyword.
在上面的对话框中，中继SMTP服务器acme.net连接到mail.other.com并发出EHLO命令。然后，它了解到支持按扩展交付，但按模式“R”的最小按时间为4分钟（240秒）。此值超过消息的原始时间，因此必然超过剩余时间。因此，中继SMTP服务器将结束SMTP会话，在此会话之后，它必须尝试跟踪任何其他MX记录，或者，如果没有更多MX记录跟踪，则必须将邮件返回为无法传递。如果EHLO命令遇到错误或未包含DELIVERBY关键字，将导致类似的行为。
Consider instead, the relaying SMTP session:
换言之，考虑中继SMTP会话：
S: 220 mail.other.com ESMTP server at your service
C: EHLO acme.net
S: 250-mail.other.com
S: 250 DELIVERBY 30
C: MAIL FROM:<eljefe@bigbiz.com> BY=98;R
S: 250 <eljefe@bigbiz.com> Sender okay
C: RCPT TO:<topbanana@other.com>
S: 250 <topbanana@wherever.com> Recipient okay
S: 220 mail.other.com ESMTP server at your service
C: EHLO acme.net
S: 250-mail.other.com
S: 250 DELIVERBY 30
C: MAIL FROM:<eljefe@bigbiz.com> BY=98;R
S: 250 <eljefe@bigbiz.com> Sender okay
C: RCPT TO:<topbanana@other.com>
S: 250 <topbanana@wherever.com> Recipient okay
In the above, the relaying SMTP client relays the BY parameter with the by-mode preserved and the by-time computed to be the remaining number of seconds at the approximate time that the MAIL FROM command was transmitted from the relaying SMTP client (acme.net) to the receiving SMTP server (mail.other.com). In this example, 22 seconds have elapsed since acme.net received the MAIL FROM line from the original sending client and relayed the Deliver By request to mail.other.com.
在上面的示例中，中继SMTP客户端中继BY参数，保留BY模式，并且计算的BY时间为从中继SMTP客户端（acme.net）向接收SMTP服务器（MAIL.other.com）传输邮件发件人命令的大致时间的剩余秒数。在本例中，自acme.net从原始发送客户端的line接收邮件并将Deliver By请求转发到MAIL.other.com以来，已经过了22秒。
Sites which wish to use the Deliver By SMTP service extension and which direct their mail via MX records [9] need to ensure that all of their MX hosts -- hosts to which their mail is directed by MX records -- support the Deliver By extension. SMTP clients which support Deliver By SHOULD NOT attempt multiple MX hosts looking for one which supports Deliver By.
希望使用“通过SMTP传递”服务扩展以及通过MX记录[9]发送邮件的站点需要确保其所有MX主机（通过MX记录发送邮件的主机）都支持“通过SMTP传递”扩展。支持传递方式的SMTP客户端不应尝试多个MX主机查找支持传递方式的主机。
MX hosts should pay careful attention to the min-by-time value they present in response to EHLO commands. It is not practical for an MX host to present a value which either (1) is substantially different from that which can be handled by the destination host to which it relays, or (2) doesn't recognize normal delivery latencies introduced when the MX host relays mail to the destination host.
MX主机应注意它们在响应EHLO命令时显示的最小时间值。MX主机提供的值（1）与它中继到的目标主机可以处理的值有很大不同，或者（2）不识别MX主机中继邮件到目标主机时引入的正常传递延迟，这是不实际的。
Implemention of Deliver By allows tracing of a mail transport system. The by-trace field "T" explicitly requests that a trace be generated. Moreover, even when the by-trace field is not used, a crude trace may be generated by entering a series of messages into the transport system, each with successively increasing by-time values; e.g., "BY=0;R", "BY=1;R", "BY=2;R". Probing, and in some cases tracing, can be accomplished through other means: querying the visible SMTP servers, investigating Received: header lines in bounced messages, and using utilities such as "traceroute".
Delivery By的实现允许跟踪邮件传输系统。“按跟踪”字段“T”显式请求生成跟踪。此外，即使不使用by trace字段，也可以通过向传输系统输入一系列消息来生成粗略的跟踪，每个消息的时间值依次递增；e、 例如，“BY=0；R”，“BY=1；R”，“BY=2；R”。探测，以及在某些情况下的跟踪，可以通过其他方式完成：查询可见的SMTP服务器，调查已跳转邮件中的已接收：头行，以及使用诸如“traceroute”之类的实用程序。
SMTP servers which support the Deliver By SMTP service extension as well as their associated MTAs are not required to assign any special processing priority to messages with Deliver By requests. Of course, some SMTP servers and MTAs may do so if they desire. Moreover, delivery status notifications generated in response to messages with Deliver By requests are not required to receive any special processing. Consequently, users of this service should not, in general, expect expedited processing of their messages. Moreover, just because a message is sent with a "BY=60;R" parameter does not guarantee that the sender will learn of a delivery failure within any specified time period as the DSN will not necessarily be expedited back to sender.
支持“通过SMTP传递”服务扩展的SMTP服务器及其关联的MTA无需为具有“通过请求传递”的邮件分配任何特殊处理优先级。当然，一些SMTP服务器和MTA可以根据需要这样做。此外，响应具有Deliver By请求的消息而生成的传递状态通知不需要接收任何特殊处理。因此，此服务的用户一般不应期望其消息得到快速处理。此外，仅仅因为使用“BY=60；R”参数发送消息并不保证发送方将在任何指定的时间段内获悉传递失败，因为DSN不一定会被加速返回发送方。
The author wishes to thank Keith Moore for providing much of the initial impetus for this document as well as the basic ideas embodied within it. Further thanks are due to Ned Freed and Chris Newman for their reviews of this document and suggestions for improvement.
作者希望感谢Keith Moore为本文件提供了许多初始动力以及其中包含的基本思想。进一步感谢Ned Freed和Chris Newman对本文件的审查和改进建议。
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[1] Postel，J.，“简单邮件传输协议”，STD 10，RFC 821，1982年8月。
[2] Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[2] Crocker，D.，编辑和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[3] Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[3] Braden，R.，编辑，“互联网主机的要求——应用和支持”，STD 3，RFC 1123，1989年10月。
[4] Rose, M., Stefferud, E., Crocker, D., Klensin, J. and N. Freed, "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
[4] Rose，M.，Stefferud，E.，Crocker，D.，Klensin，J.和N.Freed，“SMTP服务扩展”，STD 10，RFC 18691995年11月。
[5] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996.
[5] Moore，K.，“传递状态通知的SMTP服务扩展”，RFC 18911996年1月。
[6] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996.
[6] Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 1894，1996年1月。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[8] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[8] 弗里德，N.，“用于返回增强错误代码的SMTP服务扩展”，RFC 2034，1996年10月。
[9] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC 974, January 1986.
[9] 帕特里奇，C.，“邮件路由和域系统”，STD 14，RFC 974，1986年1月。
Dan Newman Sun Microsystems, Inc. 1050 Lakes Drive, Suite 250 West Covina, CA 91790 USA
Dan Newman Sun Microsystems，Inc.美国加利福尼亚州西科维纳湖路1050号250室，邮编：91790
Phone: +1 626 919 3600
Fax: +1 626 919 3614
EMail: dan.newman@sun.com
Phone: +1 626 919 3600
Fax: +1 626 919 3614
EMail: dan.newman@sun.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。