Network Working Group D. Newman Request for Comments: 2852 Sun Microsystems Updates: 1894 June 2000 Category: Standards Track Deliver By SMTP Service Extension 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved.
AbstractThis 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)  is to be issued. 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. 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
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. RFC 2119 . 4]. The following SMTP service extension is therefore defined: (1) The name of the SMTP service extension is "Deliver By". (2) The EHLO keyword value associated with this service extension is "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. The syntax of the optional parameter is as follows, using the augmented BNF notation of RFC 2234 :
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. (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. (6) No additional SMTP verbs are defined by this extension. 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. 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 ) 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
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. RFC 821 , except that a BY parameter appears after the address. The complete syntax of this extended command is defined in . 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 , the syntax for the BY esmtp-parameter is 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 -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. 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. 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. 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.
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. 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). 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 , then an enhanced error code of 5.5.4 SHOULD also be returned. 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 , a suitable 4.X.X or 5.X.X enhanced error code SHOULD also be returned. 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.
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. 5] and a NOTIFY parameter including "SUCCESS" was specified, a "delivered" DSN with appropriate status must be returned as per . Sections 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".
Sections 220.127.116.11 and 18.104.22.168 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. 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". 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". 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  and as such additional notifications may still result. Section 2. 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.
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 . 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  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 , per- message-fields is therefore extended as follows: 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  date-time field as ammended by RFC 1123 . 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: 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. Consider instead, the relaying SMTP session:
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:<firstname.lastname@example.org> BY=98;R S: 250 <email@example.com> Sender okay C: RCPT TO:<firstname.lastname@example.org> S: 250 <email@example.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. 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. 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.
 Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.  Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.  Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.  Rose, M., Stefferud, E., Crocker, D., Klensin, J. and N. Freed, "SMTP Service Extensions", STD 10, RFC 1869, November 1995.  Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996.  Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.  Partridge, C., "Mail Routing and the Domain System", STD 14, RFC 974, January 1986.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.