Skip to main content

Deliver By SMTP Service Extension
draft-newman-deliver-02

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 2852.
Author Dr. Daniel Newman
Last updated 2013-03-02 (Latest revision 1999-01-06)
RFC stream Legacy stream
Intended RFC status Proposed Standard
Formats
Stream Legacy state (None)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Became RFC 2852 (Proposed Standard)
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-newman-deliver-02
Network Working Group                               Dan Newman, Innosoft
INTERNET DRAFT                                              January 1999
Updates: RFC 1894
Category: Standards Track

                   Deliver By SMTP Service Extension
                     <draft-newman-deliver-02.txt>

Status of this Memo

     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 (Europe), munnari.oz.au (Pacific
     Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US
     West Coast).

1.  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.

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




Internet Draft     Deliver By SMTP Service Extension        January 1999

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.

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
which, often unbeknownst to the MTA, resend the message to some other
location.

The key words "MUST" and "SHOULD" in this document are to be interpreted
as described in RFC 2119 [7].

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 "R" 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

                                                                [Page 2]



Internet Draft     Deliver By SMTP Service Extension        January 1999

     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.

4.  The Deliver By SMTP service extension

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.

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 5.  Any attempt by a client to specify a
by-mode of "R" 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

                                                                [Page 3]



Internet Draft     Deliver By SMTP Service Extension        January 1999

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 2234 [2],
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 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.  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-

                                                                [Page 4]



Internet Draft     Deliver By SMTP Service Extension        January 1999

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) 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.

5.1.1.  Successful delivery

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].

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 SMTP server or MTA 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.

                                                                [Page 5]



Internet Draft     Deliver By SMTP Service Extension        January 1999

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".

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
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".

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".

5.1.4.  Relaying to another SMTP server

Sections 5.1.4.1 and 5.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.

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".

                                                                [Page 6]



Internet Draft     Deliver By SMTP Service Extension        January 1999

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 [5] and as such additional notifications may still result.

5.1.4.1.  Relaying a message with a by-mode of "R"

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 3.

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 5.1.2 should be applied.

5.1.4.2.  Relaying a message with a by-mode of "N"

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.

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].

                                                                [Page 7]



Internet Draft     Deliver By SMTP Service Extension        January 1999

5.1.5.  Relaying to a foreign mail system

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.

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;R" 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;R

                                                                [Page 8]



Internet Draft     Deliver By SMTP Service Extension        January 1999

     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 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 "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:<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

                                                                [Page 9]



Internet Draft     Deliver By SMTP Service Extension        January 1999

client and relayed the Deliver By request to mail.other.com.

8.  Security considerations

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".

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 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.

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 10]



Internet Draft     Deliver By SMTP Service Extension        January 1999

[1]  Postel, Jonathan B., "Simple Mail Transfer Protocol", RFC 821,
     August 1982.

[2]  Crocker, D. (editor), Overell, P., "Augmented BNF for Syntax
     Specifications: ABNF", RFC 2234, November 1997.

[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.

[7]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
     Levels", RFC 2119, March 1997.

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 11]