Network Working Group Dan Newman, Innosoft INTERNET DRAFT August 1998 Updates: RFC 1894 Category: Standards Track Deliver By SMTP Service Extension <draft-newman-deliver-00.txt> 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." This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 1. Abstract This memo defines an experimental 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. This extension should not be viewed as a vehicle for requesting 'priority' processing. The receiving SMTP server may assign whatever processing priority it wishes to a message transmitted with a Deliver By request. 2. Definitions 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 RFC nnnn Deliver By SMTP Service Extension August 1998 which, often unbeknownst to the MTA, resend the message to some other location. 3. Framework for the Deliver By SMTP service extension The Deliver By SMTP service extension uses the SMTP service extension mechanism described in [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, a decimal integer indicating the fixed minimum by-time that the server will accept when a by-mode of "M" is specified as per Section 5. The syntax of the parameter is as follows, using the augmented BNF notation of RFC 822 [2]: deliverby-param ::= [1*9DIGIT] 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 16 characters by the possible addition of the BY keyword and value. (6) No additional SMTP verbs are defined by this extension. 4. The Deliver By SMTP service extension A SMTP client wishing to indicate that a message be delivered within a specified period of time may issue the EHLO command to start a SMTP session and to determine if the SMTP server supports the Deliver By 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. [Page 2]
RFC nnnn Deliver By SMTP Service Extension August 1998 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 "M" is specified with the extended MAIL FROM command as described in Section 5. Any attempt by a client to specify a by-mode of "M" and a by-time strictly less than this limit 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 5. 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 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. 5. The extended MAIL FROM command 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. 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 822 [2], the syntax for the BY esmtp-parameter is by-parameter ::= "BY="by-value by-value ::= by-time";"by-mode by-time ::= ["-" / "+"]1*9digit ; a negative or zero value is not ; allowed with a by-mode of "M" by-mode ::= "O" / "M" / "T" 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 [Page 3]
RFC nnnn Deliver By SMTP Service Extension August 1998 -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 5.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. 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. In the case of a by-mode of "O" or "T", 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. In the case of a by-mode of "M", a zero or negative by-time is a syntax error. In such a case, the SMTP server should return a permanent failure (501) reply code in response to the extended MAIL FROM command. 5.1. Server behavior upon receipt of the extended MAIL FROM command 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 5.1.1-5.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 6 of this memo. [Page 4]
RFC nnnn Deliver By SMTP Service Extension August 1998 5.1.1. Successful delivery If the message is delivered before deliver-by-time, no special action need be taken. If the SMTP server also supports the Delivery Status Notification SMTP service extension [5] and a NOTIFY parameter including "SUCCESS" was specified, a "delivered" DSN with appropriate status should be returned. 5.1.2. Unsuccessful delivery; deliver-by-time not yet reached If deliver-by-time has not yet passed and the message has proved undeliverable for temporary reasons, then the MTA or SMTP server should continue delivery or relay attempts as per the site's message handling policy. However, the message MUST still be handled in accord with Sections 5.1.1-5.1.5. If deliver-by-time has not yet passed and the message cannot be delivered for permanent reasons, then the MTA or SMTP server MUST return a "failed" DSN with an appropriate status if either no NOTIFY parameter was specified or the NOTIFY parameter includes "FAILURE". 5.1.3. Time has expired; deliver-by-time reached or passed If the message is not delivered or relayed before deliver-by-time and a mode-value of "M" was specified, no further delivery attempts may be made for the message. If a NOTIFY parameter was either not specified or includes "FAILURE" then the server MUST issue a "failed" DSN with status 5.4.7, "delivery time expired". If the message is not delivered or relayed before deliver-by-time and a by-mode of "O" or "T" was specified, the MTA or SMTP server should continue attempts to deliver or relay the message using the site's message handling policy. In addition, if a NOTIFY parameter was either not specified or includes "DELAY", and either of the two conditions below are met, (1) by-mode is "O" and by-time is greater than or equal to zero, or (2) by-mode is "T", then the MTA or server MUST issue a "delayed" DSN with status 4.4.7, "delivery time expired". [Page 5]
RFC nnnn Deliver By SMTP Service Extension August 1998 Discussion: A by-mode of "T" allows an originator to trace the path of a mail message by entering the message into the transport system with a by-parameter of "BY=0;T". To some this may seem undesireable. However, realize that nearly the same effect can be had by sending a series of messages, each with successively increasing by-time values; e.g., "BY=0;O", "BY=1;O", "BY=2;O", "BY=3;O", etc. 5.1.4. Relaying to another SMTP server A message for which a by-mode of "M" was specified MUST not be relayed to a SMTP server which does not support the Deliver By SMTP service extension. Moreover, when relaying a message with a by-mode of "M", the server to which it is relayed must not have a fixed minimum by-time which is strictly larger 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 3. A message with a by-mode of "O" or "T" may be relayed to another server regardless of whether or not the server to which it is relayed supports the Deliver By extension. If the message is relayed before deliver-by-time to a SMTP server that does not support the Deliver By extension, and the message either did not specify a NOTIFY parameter or the NOTIFY parameter does not have the value "NEVER", then the relaying server or MTA MUST issue a "relayed" DSN. 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. Note further that 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 "O" or "T". [Page 6]
RFC nnnn Deliver By SMTP Service Extension August 1998 5.1.5. Relaying to a foreign mail system If the foreign mail system supports semantics similar the 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. 6. Delivery status notifications and extension 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: 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]. 7. Examples 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;M" as shown below: 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;M [Page 7]
RFC nnnn Deliver By SMTP Service Extension August 1998 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 "M", the message may only be relayed to another SMTP server which supports the Deliver By extension (Section 5.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 "M" is 4 minutes (240 seconds). This value exceeds the message's original by-time and hence must exceed the remaining by-time. The relaying SMTP server therefore 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:<eljefe@bigbiz.com> BY=98;M 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 has elapsed since acme.net received the MAIL FROM line from the original sending [Page 8]
RFC nnnn Deliver By SMTP Service Extension August 1998 client and relayed the Deliver By request to mail.other.com. 8. Security considerations Implemention of either the "O" or "T" by-mode allows tracing of a mail transport system as per the discussion of Section 5.1.3. 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". 9. Other considerations 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 dRequirements for Internet Hosts -- Application and Supporto 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;M" 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. 10. Acknowledgments 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. 11. References [Page 9]
RFC nnnn Deliver By SMTP Service Extension August 1998 [1] Postel, Jonathan B., "Simple Mail Transfer Protocol", RFC 821, August 1982. [2] Crocker, David H., "Standard for the Format of ARPA Internet Text Messages", RFC 822, August 1982. [3] Braden, R. (editor), "Requirements for Internet Hosts -- Application and Support", RFC 1123, October 1989. [4] Rose, M., Stefferud, E., Crocker, D., Klensin, J. (chair), & Freed, N. (editor), "SMTP Service Extensions", RFC 1869, November 1995. [5] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996. [6] Moore, K. & Vaudreuil, G., "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996. 12. Author's Address Dan Newman <dan.newman@innosoft.com> Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA Telephone: +1 626 919 3600 Fax: +1 626 919 3614 [Page 10]