As per Relevance of the word delivery, we have this rfc below:
Network Working Group D.
Request for Comments: 2852 Sun
Updates: 1894 June 2000
Category: Standards
Deliver By SMTP Service
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This memo defines a mechanism whereby a SMTP client can request,
transmitting a message to a SMTP server, that the server deliver
message within a prescribed period of time. A client making such
request also specifies the message handling which is to occur if
message cannot be delivered within the specified time period:
the message is to be returned as undeliverable with no
processing, or a "delayed" delivery status notification (DSN) [6]
to be issued
This extension should not be viewed as a vehicle for
"priority" processing. A receiving SMTP server may assign
processing priority it wishes to a message transmitted with a
By request. A Deliver By request serves to express a message'
urgency and to provide an additional degree of determinancy in
processing. An indication of an urgent message's status within
given time period may be requested and will be honored. Moreover
the message may be withdrawn if not delivered within that
period
A typical usage of this mechanism is to prevent delivery of a
beyond some future time of significance to the sender or
but not known by the MTAs handling the message. For instance,
sender may know that the message will be delivered as a page but
not consider the message to be sufficiently important as to
paging the recipient after business hours. In that case, the
could be marked such that delivery attempts are not made
Newman Standards Track [Page 1]
RFC 2852 Deliver By SMTP Service Extension June 2000
17:00. Another common usage arises when a sender wishes to
alerted to delivery delays. In this case, the sender can mark
message such that if it is not delivered within, say, 30 minutes,
"delayed" DSN is generated but delivery attempts are
continued. In this case the sender has been allowed to express
preference for when they would like to learn of delivery problems
1.
Throughout this document, the term "deliver" is taken to mean the
of transmitting a message to its "final" destination by a
transport agent (MTA). Usually, but not always, this means
or otherwise handing off the message to the recipient's mailbox
Thus, an MTA which accepts a message to be delivered within
specified time period is agreeing to store or handoff the message
the recipient's mailbox within the specified time period.
the scope of the term "deliver" are any user-specified actions
might take place after the MTA stores or hands off the message; e.g.,
user-programmed filters which, often unbeknownst to the MTA,
the message to some other location
The key words "MUST", "MUST NOT", "SHOULD" and "SHOULD NOT" in
document are to be interpreted as described in RFC 2119 [7].
2. Framework for the Deliver By SMTP service
The Deliver By SMTP service extension uses the SMTP service
mechanism described in [4]. The following SMTP service extension
therefore defined
(1) The name of the SMTP service extension is "Deliver By".
(2) The EHLO keyword value associated with this service extension
"DELIVERBY".
(3) One optional parameter is allowed with this EHLO keyword value
The optional parameter, when supplied, is a comma separated
of options. Only one option, a min-by-time, is specified
this document. Future documents may extend this
by specifying additional options. The min-by-time is a
integer indicating the fixed minimum by-time that the
will accept when a by-mode of "R" is specified as per Section 4.
The syntax of the optional parameter is as follows, using
augmented BNF notation of RFC 2234 [2]:
Newman Standards Track [Page 2]
RFC 2852 Deliver By SMTP Service Extension June 2000
deliverby-param = min-by-time *( ',' extension-token )
min-by-time = [1*9DIGIT
extension-token = 1*
characters (US ASCII 0-31 inclusive)>
SP = character (ASCII decimal code 32)>
COMMA = character (ASCII decimal code 44)>
If the parameter is omitted, no information is conveyed
the server's fixed minimum by-time
(4) One optional parameter using the keyword "BY" is added to
MAIL FROM command
(5) The maximum length of a MAIL FROM command line is increased
17 characters by the possible addition of the BY keyword
value
(6) No additional SMTP verbs are defined by this extension
3. The Deliver By SMTP service
A SMTP client wishing to use the Deliver By SMTP service
may issue the EHLO command to start a SMTP session and to
if the SMTP server supports the service extension. If the
responds with code 250 to the EHLO command, and the response
the EHLO keyword DELIVERBY, then the Deliver By SMTP
extension is supported by the server
If a numeric parameter follows the DELIVERBY keyword value of
EHLO response then that parameter indicates the minimum value
for the by-time when a by-mode of "R" is specified with the
MAIL FROM command as described in Section 4. Any attempt by a
to specify a by-mode of "R" and a by-time strictly less than
limit, min-by-time, will be rejected with a permanent failure (55z
reply code
A SMTP server that supports the Deliver By SMTP service
will accept the extended version of the MAIL FROM command
in Section 4. When supported by the server, a SMTP client may
the extended MAIL FROM command (instead of the MAIL FROM
described in [1]) to request that the message be delivered within
specified time period. The server may then return an
error code if it determines that the request cannot be honored.
that this may not be apparent to the server until either
of the recipient addresses with RCPT TO commands or completion of
transfer of the message data with the dot (.) command. As such,
Newman Standards Track [Page 3]
RFC 2852 Deliver By SMTP Service Extension June 2000
server may send to the client a success response to the MAIL
command only to later return an error response to the RCPT TO, DATA
or dot command
4. The extended MAIL FROM
The extended MAIL FROM command is issued by a SMTP client when
wishes to inform a SMTP server that a message is to be
within a specified period of time and further what action to
should the message prove undeliverable within that time period.
extended MAIL FROM command is identical to the MAIL FROM command
defined in RFC 821 [1], except that a BY parameter appears after
address
The complete syntax of this extended command is defined in [4].
esmtp-keyword is "BY" and the syntax for the esmtp-value is given
the syntax for by-value shown below. In the augmented BNF of
2234 [2], the syntax for the BY esmtp-parameter
by-parameter = "BY="by-
by-value = by-time";"by-mode[by-trace
by-time = ["-" / "+"]1*9digit ; a negative or zero value is
; 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
within which the message should be delivered and has the
-999,999,999 seconds <= by-time <= +999,999,999
and is thus sufficient to represent a time anywhere
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
SMTP server must take should it not be possible to transmit
message within by-time seconds
Note that by-time is a delta time: the number of seconds within
to deliver the message. This delta time does not extend an MTA'
normal retention period for undeliverable messages nor is it
"deliver after" time
A delta time is used so as to prevent problems associated
differences in system clocks between clients and servers. Servers
receipt of a valid by-parameter are expected to convert the by-
into a locale-specific absolute time called the deliver-by-time
Newman Standards Track [Page 4]
RFC 2852 Deliver By SMTP Service Extension June 2000
This is done by adding the by-time upon receipt to the
locale-specific time and thereby arriving at a locale-
absolute time which is by-time seconds in the future or past
depending upon the arithmetic sign of by-time. The message is
to be delivered by the deliver-by-time. The sending client
receiving server should assume the transmission time of the MAIL
command to be instantaneous. Clearly, it will not be and
latency will introduce an error, the nature of which will be
extend slightly the effective by-time. The more hops the
takes, the more pronounced the effect will be owing to the
nature of this latency-induced error
In the case of a by-mode of "N", it is possible that by-time may
zero or negative. This is not an error and should not be rejected
such. It indicates a message for which the deliver-by-time
-(by-time) seconds in the past. [Here, "-(by-time)" represents
arithmetic negation of the by-time value.] Zero and negative
are allowed so as to preserve information about any
delivery time information -- information which the delivering MTA
wish to include with the delivered message for the benefit of
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
syntax error. In such a case, the SMTP server SHOULD return
permanent failure (501) SMTP reply code in response to the
MAIL FROM command. If the SMTP server also supports enhanced
codes [8], then an enhanced error code of 5.5.4 SHOULD also
returned
If the by-time is a valid by-time specification but the SMTP
cannot honor or accept it for a server-specific reason, then
server SHOULD respond with either a 455 SMTP response if
condition is transient or a 555 SMTP response if the condition
permanent. In addition, if the SMTP server also supports [8],
suitable 4.X.X or 5.X.X enhanced error code SHOULD also be returned
4.1. Server behavior upon receipt of the extended MAIL FROM
Upon receipt of an extended MAIL FROM command containing a valid
parameter, a SMTP server and associated MTA must handle the
in accord with the following subsections, Sections 4.1.1-4.1.5.
Delivery status notifications generated in response to processing
message with a Deliver By request should include both the
Arrival-Date DSN field as well as the new Deliver-By-Date DSN
described in Section 5 of this memo
Newman Standards Track [Page 5]
RFC 2852 Deliver By SMTP Service Extension June 2000
A by-time Note that a message's by-time does not extend the MTA'
normal message retention period: an MTA MAY return a message
undeliverable before the deliver-by-time has been reached
4.1.1. Successful
If the message is delivered before deliver-by-time, no special
need be taken. If the SMTP server or MTA also supports the
Status Notification SMTP service extension [5] and a NOTIFY
including "SUCCESS" was specified, a "delivered" DSN with
status must be returned as per [5].
4.1.2. Unsuccessful delivery; deliver-by-time not yet
If deliver-by-time has not yet passed and the message has
undeliverable for temporary reasons, then the SMTP server or
should continue delivery or relay attempts as per the site's
handling policy. If the MTA's message retention period is less
by-time, the MTA MAY return the message as undeliverable
deliver-by-time has been reached. However, the message MUST still
handled in accord with Sections 4.1.1-4.1.5.
If deliver-by-time has not yet passed and the message cannot
delivered for permanent reasons, then the SMTP server or MTA
return a "failed" DSN with an appropriate status for each
address with either no NOTIFY parameter specified or for which
NOTIFY parameter includes "FAILURE".
4.1.3. Time has expired; deliver-by-time reached or
If the message is not delivered or relayed before deliver-by-time
a by-mode of "R" was specified, no further delivery attempts may
made for the message. The server or MTA MUST issue a "failed"
with status 5.4.7, "delivery time expired", for each
address with either no NOTIFY parameter specified or for which
NOTIFY parameter includes "FAILURE".
If the message is not delivered or relayed before deliver-by-time
a by-mode of "N" was specified, the server or MTA should
attempts to deliver or relay the message using the site's
handling policy. In addition, the server or MTA MUST issue
"delayed" DSN with status 4.4.7, "delivery time expired", for
recipient address with either no NOTIFY parameter specified or
which the NOTIFY parameter includes "DELAY".
Newman Standards Track [Page 6]
RFC 2852 Deliver By SMTP Service Extension June 2000
4.1.4. Relaying to another SMTP
Sections 4.1.4.1 and 4.1.4.2 below describe when a message with
Deliver By request may be relayed to another SMTP server and
additional actions, if any, should or must be taken. In addition
that discussed in those sections, the following must also be
when relaying is permitted
If the message is relayed to a SMTP server that supports the
By extension, a new BY parameter MUST be relayed specifying a by-
value indicating the number of seconds remaining until deliver-by
time. The new by-time value should be computed as close to the
the MAIL FROM command is transmitted by the relaying SMTP client
is reasonably possible. Note that if deliver-by-time has passed,
relayed by-time will be a negative value indicating how may
has elapsed since delivery-by-time. Such a case -- relay of
message for which deliver-by-time has just arrived or passed --
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,
"relayed" DSN SHOULD be generated by the relaying SMTP client
each recipient which either did not specify a NOTIFY parameter or
NOTIFY parameter does not have the value "NEVER".
Note that these "relayed" DSNs are generated regardless of
success notifications were explicitly requested with a NOTIFY=
parameter. Note further that the "relayed" DSNs discussed here
not terminal notifications: downstream SMTP servers and MTAs
still support [5] and as such additional notifications may
result
4.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
relayed to a SMTP server which does not support the Deliver By
service extension. Moreover, the server to which it is relayed
NOT have a fixed minimum by-time which is greater than the
remaining in which the message is to be delivered. The fixed
by-time is expressed by the optional deliverby-param discussed
Section 2.
If the message requires relaying in order to be delivered yet
be relayed, then the message is deemed to be undeliverable
permanent reasons and Section 4.1.2 should be applied
Newman Standards Track [Page 7]
RFC 2852 Deliver By SMTP Service Extension June 2000
4.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
regardless of whether or not the SMTP server to which it is
supports the Deliver By extension
If the message is relayed before deliver-by-time to a SMTP
that does not support the Deliver By extension, then the
SMTP client MUST issue a "relayed" DSN for each recipient
either did not specify a NOTIFY parameter or the NOTIFY
does not have the value "NEVER". Further, if the SMTP server
relayed to supports the Delivery Status Notification SMTP
extension [5] then for each recipient: if no NOTIFY parameter
supplied, "NOTIFY=FAILURE,DELAY" SHOULD be requested; if a
parameter was specified and does not have the value "NEVER", "DELAY
SHOULD be added to the list of notify-list-element values if
already present. Note that this explicitly overrides the "MUST NOT
wording of Section 6.2.1(c) of [5].
4.1.5. Relaying to a foreign mail
If the foreign mail system supports semantics similar to the
By SMTP service extension described in this memo, then convey
Deliver By request to that system. Otherwise, relay the message
if relaying to a SMTP server which does not support the Deliver
extension
5. Delivery status notifications and
The format of delivery status notifications (DSNs) is specified
[6]. DSNs generated in response to a Deliver By request
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
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
[ 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-
Newman Standards Track [Page 8]
RFC 2852 Deliver By SMTP Service Extension June 2000
where date-time is a RFC 822 [2] date-time field as ammended by
1123 [3].
6.
In the following sample SMTP dialog, the SMTP client requests that
message from be delivered
within 2 minutes (120 seconds) and
otherwise. This request takes the form of a BY parameter on the
FROM line of "BY=120;R" as shown below
S: 220 acme.net SMTP server
C: EHLO bigbiz.
S: 250-acme.
S: 250
C: MAIL FROM: BY=120;
S: 250 sender
C: RCPT TO:
S: 250 recipient
Suppose now that the receiving SMTP server in the above example
to relay the message to another SMTP server, mail.other.com.
to the original by-mode of "R", the message may only be relayed
another SMTP server which supports the Deliver By extension (
4.1.4). Further, when relaying the message, the Deliver By
must be relayed. With this in mind, consider the following
dialog
S: 220 mail.other.com ESMTP server at your
C: EHLO acme.
S: 250-mail.other.
S: 250 DELIVERBY 240
C:
In the above dialog, the relaying SMTP server, acme.net, connects
mail.other.com and issues an EHLO command. It then learns that
Deliver By extension is supported but that the minimum by-time for
by-mode of "R" is 4 minutes (240 seconds). This value exceeds
message's original by-time and therefore necessarily exceeds
remaining by-time. The relaying SMTP server thus ends the
session after which it must either attempt to follow any other
records or, if there are no more MX records to follow, must
the message as undeliverable. Similar behavior would result if
EHLO command was met with an error or did not include the
keyword
Consider instead, the relaying SMTP session
Newman Standards Track [Page 9]
RFC 2852 Deliver By SMTP Service Extension June 2000
S: 220 mail.other.com ESMTP server at your
C: EHLO acme.
S: 250-mail.other.
S: 250 DELIVERBY 30
C: MAIL FROM: BY=98;
S: 250 Sender
C: RCPT TO:
S: 250 Recipient
In the above, the relaying SMTP client relays the BY parameter
the by-mode preserved and the by-time computed to be the
number of seconds at the approximate time that the MAIL FROM
was transmitted from the relaying SMTP client (acme.net) to
receiving SMTP server (mail.other.com). In this example, 22
have elapsed since acme.net received the MAIL FROM line from
original sending client and relayed the Deliver By request
mail.other.com
7. MX based relaying
Sites which wish to use the Deliver By SMTP service extension
which direct their mail via MX records [9] need to ensure that all
their MX hosts -- hosts to which their mail is directed by MX
-- support the Deliver By extension. SMTP clients which
Deliver By SHOULD NOT attempt multiple MX hosts looking for one
supports Deliver By
MX hosts should pay careful attention to the min-by-time value
present in response to EHLO commands. It is not practical for an
host to present a value which either (1) is substantially
from that which can be handled by the destination host to which
relays, or (2) doesn't recognize normal delivery latencies
when the MX host relays mail to the destination host
8. Security
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
be generated by entering a series of messages into the
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,
be accomplished through other means: querying the visible
servers, investigating Received: header lines in bounced messages
and using utilities such as "traceroute".
Newman Standards Track [Page 10]
RFC 2852 Deliver By SMTP Service Extension June 2000
9. Other
SMTP servers which support the Deliver By SMTP service extension
well as their associated MTAs are not required to assign any
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
Deliver By requests are not required to receive any
processing. Consequently, users of this service should not,
general, expect expedited processing of their messages. Moreover
just because a message is sent with a "BY=60;R" parameter does
guarantee that the sender will learn of a delivery failure within
specified time period as the DSN will not necessarily be
back to sender
10.
The author wishes to thank Keith Moore for providing much of
initial impetus for this document as well as the basic ideas
within it. Further thanks are due to Ned Freed and Chris Newman
their reviews of this document and suggestions for improvement
Newman Standards Track [Page 11]
RFC 2852 Deliver By SMTP Service Extension June 2000
11.
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
August 1982.
[2] Crocker, D., Editor, and P. Overell, "Augmented BNF for
Specifications: ABNF", RFC 2234, November 1997.
[3] Braden, R., Editor, "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, October 1989.
[4] Rose, M., Stefferud, E., Crocker, D., Klensin, J. and N. Freed
"SMTP Service Extensions", STD 10, RFC 1869, November 1995.
[5] Moore, K., "SMTP Service Extension for Delivery
Notifications", RFC 1891, January 1996.
[6] Moore, K. and G. Vaudreuil, "An Extensible Message Format
Delivery Status Notifications", RFC 1894, January 1996.
[7] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
[8] Freed, N., "SMTP Service Extension for Returning Enhanced
Codes", RFC 2034, October 1996.
[9] Partridge, C., "Mail Routing and the Domain System", STD 14,
974, January 1986.
12. Author's
Dan
Sun Microsystems, Inc
1050 Lakes Drive, Suite 250
West Covina, CA 91790
Phone: +1 626 919 3600
Fax: +1 626 919 3614
EMail: dan.newman@sun.
Newman Standards Track [Page 12]
RFC 2852 Deliver By SMTP Service Extension June 2000
13. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Newman Standards Track [Page 13]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
