7Network Working Group D. Newman
8Request for Comments: 2852 Sun Microsystems
10Category: Standards Track
13 Deliver By SMTP Service Extension
17 This document specifies an Internet standards track protocol for the
18 Internet community, and requests discussion and suggestions for
19 improvements. Please refer to the current edition of the "Internet
20 Official Protocol Standards" (STD 1) for the standardization state
21 and status of this protocol. Distribution of this memo is unlimited.
25 Copyright (C) The Internet Society (2000). All Rights Reserved.
29 This memo defines a mechanism whereby a SMTP client can request, when
30 transmitting a message to a SMTP server, that the server deliver the
31 message within a prescribed period of time. A client making such a
32 request also specifies the message handling which is to occur if the
33 message cannot be delivered within the specified time period: either
34 the message is to be returned as undeliverable with no further
35 processing, or a "delayed" delivery status notification (DSN) [6] is
38 This extension should not be viewed as a vehicle for requesting
39 "priority" processing. A receiving SMTP server may assign whatever
40 processing priority it wishes to a message transmitted with a Deliver
41 By request. A Deliver By request serves to express a message's
42 urgency and to provide an additional degree of determinancy in its
43 processing. An indication of an urgent message's status within a
44 given time period may be requested and will be honored. Moreover,
45 the message may be withdrawn if not delivered within that time
48 A typical usage of this mechanism is to prevent delivery of a message
49 beyond some future time of significance to the sender or recipient
50 but not known by the MTAs handling the message. For instance, the
51 sender may know that the message will be delivered as a page but does
52 not consider the message to be sufficiently important as to warrant
53 paging the recipient after business hours. In that case, the message
54 could be marked such that delivery attempts are not made beyond
58Newman Standards Track [Page 1]
60RFC 2852 Deliver By SMTP Service Extension June 2000
63 17:00. Another common usage arises when a sender wishes to be
64 alerted to delivery delays. In this case, the sender can mark a
65 message such that if it is not delivered within, say, 30 minutes, a
66 "delayed" DSN is generated but delivery attempts are nonetheless
67 continued. In this case the sender has been allowed to express a
68 preference for when they would like to learn of delivery problems.
72 Throughout this document, the term "deliver" is taken to mean the act
73 of transmitting a message to its "final" destination by a message
74 transport agent (MTA). Usually, but not always, this means storing
75 or otherwise handing off the message to the recipient's mailbox.
76 Thus, an MTA which accepts a message to be delivered within a
77 specified time period is agreeing to store or handoff the message to
78 the recipient's mailbox within the specified time period. Outside
79 the scope of the term "deliver" are any user-specified actions which
80 might take place after the MTA stores or hands off the message; e.g.,
81 user-programmed filters which, often unbeknownst to the MTA, resend
82 the message to some other location.
84 The key words "MUST", "MUST NOT", "SHOULD" and "SHOULD NOT" in this
85 document are to be interpreted as described in RFC 2119 [7].
872. Framework for the Deliver By SMTP service extension
89 The Deliver By SMTP service extension uses the SMTP service extension
90 mechanism described in [4]. The following SMTP service extension is
93 (1) The name of the SMTP service extension is "Deliver By".
95 (2) The EHLO keyword value associated with this service extension is
98 (3) One optional parameter is allowed with this EHLO keyword value.
99 The optional parameter, when supplied, is a comma separated list
100 of options. Only one option, a min-by-time, is specified in
101 this document. Future documents may extend this specification
102 by specifying additional options. The min-by-time is a fixed
103 integer indicating the fixed minimum by-time that the server
104 will accept when a by-mode of "R" is specified as per Section 4.
106 The syntax of the optional parameter is as follows, using the
107 augmented BNF notation of RFC 2234 [2]:
114Newman Standards Track [Page 2]
116RFC 2852 Deliver By SMTP Service Extension June 2000
119 deliverby-param = min-by-time *( ',' extension-token )
120 min-by-time = [1*9DIGIT]
121 extension-token = 1*<any CHAR excluding SP, COMMA and all control
122 characters (US ASCII 0-31 inclusive)>
123 SP = <the space character (ASCII decimal code 32)>
124 COMMA = <the comma character (ASCII decimal code 44)>
126 If the parameter is omitted, no information is conveyed about
127 the server's fixed minimum by-time.
129 (4) One optional parameter using the keyword "BY" is added to the
132 (5) The maximum length of a MAIL FROM command line is increased by
133 17 characters by the possible addition of the BY keyword and
136 (6) No additional SMTP verbs are defined by this extension.
1383. The Deliver By SMTP service extension
140 A SMTP client wishing to use the Deliver By SMTP service extension
141 may issue the EHLO command to start a SMTP session and to determine
142 if the SMTP server supports the service extension. If the server
143 responds with code 250 to the EHLO command, and the response includes
144 the EHLO keyword DELIVERBY, then the Deliver By SMTP service
145 extension is supported by the server.
147 If a numeric parameter follows the DELIVERBY keyword value of the
148 EHLO response then that parameter indicates the minimum value allowed
149 for the by-time when a by-mode of "R" is specified with the extended
150 MAIL FROM command as described in Section 4. Any attempt by a client
151 to specify a by-mode of "R" and a by-time strictly less than this
152 limit, min-by-time, will be rejected with a permanent failure (55z)
155 A SMTP server that supports the Deliver By SMTP service extension
156 will accept the extended version of the MAIL FROM command described
157 in Section 4. When supported by the server, a SMTP client may use
158 the extended MAIL FROM command (instead of the MAIL FROM command
159 described in [1]) to request that the message be delivered within the
160 specified time period. The server may then return an appropriate
161 error code if it determines that the request cannot be honored. Note
162 that this may not be apparent to the server until either presentation
163 of the recipient addresses with RCPT TO commands or completion of the
164 transfer of the message data with the dot (.) command. As such, the
170Newman Standards Track [Page 3]
172RFC 2852 Deliver By SMTP Service Extension June 2000
175 server may send to the client a success response to the MAIL FROM
176 command only to later return an error response to the RCPT TO, DATA,
1794. The extended MAIL FROM command
181 The extended MAIL FROM command is issued by a SMTP client when it
182 wishes to inform a SMTP server that a message is to be delivered
183 within a specified period of time and further what action to take
184 should the message prove undeliverable within that time period. The
185 extended MAIL FROM command is identical to the MAIL FROM command as
186 defined in RFC 821 [1], except that a BY parameter appears after the
189 The complete syntax of this extended command is defined in [4]. The
190 esmtp-keyword is "BY" and the syntax for the esmtp-value is given by
191 the syntax for by-value shown below. In the augmented BNF of RFC
192 2234 [2], the syntax for the BY esmtp-parameter is
194 by-parameter = "BY="by-value
195 by-value = by-time";"by-mode[by-trace]
196 by-time = ["-" / "+"]1*9digit ; a negative or zero value is not
197 ; allowed with a by-mode of "R"
198 by-mode = "N" / "R" ; "Notify" or "Return"
199 by-trace = "T" ; "Trace"
201 Note that the BY esmtp-keyword MUST have an associated esmtp-value.
202 The by-time is a decimal representation of the number of seconds
203 within which the message should be delivered and has the range
205 -999,999,999 seconds <= by-time <= +999,999,999 seconds
207 and is thus sufficient to represent a time anywhere from
208 approximately 31.6 years in the past to 31.6 years in the future.
210 As described in Section 4.1, the by-mode indicates the action the
211 SMTP server must take should it not be possible to transmit the
212 message within by-time seconds.
214 Note that by-time is a delta time: the number of seconds within which
215 to deliver the message. This delta time does not extend an MTA's
216 normal retention period for undeliverable messages nor is it a
217 "deliver after" time.
219 A delta time is used so as to prevent problems associated with
220 differences in system clocks between clients and servers. Servers in
221 receipt of a valid by-parameter are expected to convert the by-time
222 into a locale-specific absolute time called the deliver-by-time.
226Newman Standards Track [Page 4]
228RFC 2852 Deliver By SMTP Service Extension June 2000
231 This is done by adding the by-time upon receipt to the current
232 locale-specific time and thereby arriving at a locale-specific
233 absolute time which is by-time seconds in the future or past,
234 depending upon the arithmetic sign of by-time. The message is then
235 to be delivered by the deliver-by-time. The sending client and
236 receiving server should assume the transmission time of the MAIL FROM
237 command to be instantaneous. Clearly, it will not be and network
238 latency will introduce an error, the nature of which will be to
239 extend slightly the effective by-time. The more hops the message
240 takes, the more pronounced the effect will be owing to the cumulative
241 nature of this latency-induced error.
243 In the case of a by-mode of "N", it is possible that by-time may be
244 zero or negative. This is not an error and should not be rejected as
245 such. It indicates a message for which the deliver-by-time occurred
246 -(by-time) seconds in the past. [Here, "-(by-time)" represents the
247 arithmetic negation of the by-time value.] Zero and negative values
248 are allowed so as to preserve information about any requested
249 delivery time information -- information which the delivering MTA may
250 wish to include with the delivered message for the benefit of the
251 recipient or to show in a DSN or NDN (non delivery notification).
253 In the case of a by-mode of "R", a zero or negative by-time is a
254 syntax error. In such a case, the SMTP server SHOULD return a
255 permanent failure (501) SMTP reply code in response to the extended
256 MAIL FROM command. If the SMTP server also supports enhanced error
257 codes [8], then an enhanced error code of 5.5.4 SHOULD also be
260 If the by-time is a valid by-time specification but the SMTP server
261 cannot honor or accept it for a server-specific reason, then SMTP
262 server SHOULD respond with either a 455 SMTP response if the
263 condition is transient or a 555 SMTP response if the condition is
264 permanent. In addition, if the SMTP server also supports [8], a
265 suitable 4.X.X or 5.X.X enhanced error code SHOULD also be returned.
2674.1. Server behavior upon receipt of the extended MAIL FROM command
269 Upon receipt of an extended MAIL FROM command containing a valid BY
270 parameter, a SMTP server and associated MTA must handle the message
271 in accord with the following subsections, Sections 4.1.1-4.1.5.
272 Delivery status notifications generated in response to processing a
273 message with a Deliver By request should include both the optional
274 Arrival-Date DSN field as well as the new Deliver-By-Date DSN field
275 described in Section 5 of this memo.
282Newman Standards Track [Page 5]
284RFC 2852 Deliver By SMTP Service Extension June 2000
287 A by-time Note that a message's by-time does not extend the MTA's
288 normal message retention period: an MTA MAY return a message as
289 undeliverable before the deliver-by-time has been reached.
2914.1.1. Successful delivery
293 If the message is delivered before deliver-by-time, no special action
294 need be taken. If the SMTP server or MTA also supports the Delivery
295 Status Notification SMTP service extension [5] and a NOTIFY parameter
296 including "SUCCESS" was specified, a "delivered" DSN with appropriate
297 status must be returned as per [5].
2994.1.2. Unsuccessful delivery; deliver-by-time not yet reached
301 If deliver-by-time has not yet passed and the message has proved
302 undeliverable for temporary reasons, then the SMTP server or MTA
303 should continue delivery or relay attempts as per the site's message
304 handling policy. If the MTA's message retention period is less than
305 by-time, the MTA MAY return the message as undeliverable before
306 deliver-by-time has been reached. However, the message MUST still be
307 handled in accord with Sections 4.1.1-4.1.5.
309 If deliver-by-time has not yet passed and the message cannot be
310 delivered for permanent reasons, then the SMTP server or MTA MUST
311 return a "failed" DSN with an appropriate status for each recipient
312 address with either no NOTIFY parameter specified or for which the
313 NOTIFY parameter includes "FAILURE".
3154.1.3. Time has expired; deliver-by-time reached or passed
317 If the message is not delivered or relayed before deliver-by-time and
318 a by-mode of "R" was specified, no further delivery attempts may be
319 made for the message. The server or MTA MUST issue a "failed" DSN
320 with status 5.4.7, "delivery time expired", for each recipient
321 address with either no NOTIFY parameter specified or for which the
322 NOTIFY parameter includes "FAILURE".
324 If the message is not delivered or relayed before deliver-by-time and
325 a by-mode of "N" was specified, the server or MTA should continue
326 attempts to deliver or relay the message using the site's message
327 handling policy. In addition, the server or MTA MUST issue a
328 "delayed" DSN with status 4.4.7, "delivery time expired", for each
329 recipient address with either no NOTIFY parameter specified or for
330 which the NOTIFY parameter includes "DELAY".
338Newman Standards Track [Page 6]
340RFC 2852 Deliver By SMTP Service Extension June 2000
3434.1.4. Relaying to another SMTP server
345 Sections 4.1.4.1 and 4.1.4.2 below describe when a message with a
346 Deliver By request may be relayed to another SMTP server and what
347 additional actions, if any, should or must be taken. In addition to
348 that discussed in those sections, the following must also be observed
349 when relaying is permitted.
351 If the message is relayed to a SMTP server that supports the Deliver
352 By extension, a new BY parameter MUST be relayed specifying a by-time
353 value indicating the number of seconds remaining until deliver-by-
354 time. The new by-time value should be computed as close to the time
355 the MAIL FROM command is transmitted by the relaying SMTP client as
356 is reasonably possible. Note that if deliver-by-time has passed, the
357 relayed by-time will be a negative value indicating how may seconds
358 has elapsed since delivery-by-time. Such a case -- relay of a
359 message for which deliver-by-time has just arrived or passed -- may
360 only happen with a message that has a by-mode of "N".
362 When a message with a by-trace field with value "T" is relayed, a
363 "relayed" DSN SHOULD be generated by the relaying SMTP client for
364 each recipient which either did not specify a NOTIFY parameter or the
365 NOTIFY parameter does not have the value "NEVER".
367 Note that these "relayed" DSNs are generated regardless of whether
368 success notifications were explicitly requested with a NOTIFY=SUCCESS
369 parameter. Note further that the "relayed" DSNs discussed here are
370 not terminal notifications: downstream SMTP servers and MTAs may
371 still support [5] and as such additional notifications may still
3744.1.4.1. Relaying a message with a by-mode of "R"
376 A message for which a by-mode of "R" was specified MUST NOT be
377 relayed to a SMTP server which does not support the Deliver By SMTP
378 service extension. Moreover, the server to which it is relayed MUST
379 NOT have a fixed minimum by-time which is greater than the time
380 remaining in which the message is to be delivered. The fixed minimum
381 by-time is expressed by the optional deliverby-param discussed in
384 If the message requires relaying in order to be delivered yet cannot
385 be relayed, then the message is deemed to be undeliverable for
386 permanent reasons and Section 4.1.2 should be applied.
394Newman Standards Track [Page 7]
396RFC 2852 Deliver By SMTP Service Extension June 2000
3994.1.4.2. Relaying a message with a by-mode of "N"
401 A message with a by-mode of "N" may be relayed to another server
402 regardless of whether or not the SMTP server to which it is relayed
403 supports the Deliver By extension.
405 If the message is relayed before deliver-by-time to a SMTP server
406 that does not support the Deliver By extension, then the relaying
407 SMTP client MUST issue a "relayed" DSN for each recipient which
408 either did not specify a NOTIFY parameter or the NOTIFY parameter
409 does not have the value "NEVER". Further, if the SMTP server being
410 relayed to supports the Delivery Status Notification SMTP service
411 extension [5] then for each recipient: if no NOTIFY parameter was
412 supplied, "NOTIFY=FAILURE,DELAY" SHOULD be requested; if a NOTIFY
413 parameter was specified and does not have the value "NEVER", "DELAY"
414 SHOULD be added to the list of notify-list-element values if not
415 already present. Note that this explicitly overrides the "MUST NOT"
416 wording of Section 6.2.1(c) of [5].
4184.1.5. Relaying to a foreign mail system
420 If the foreign mail system supports semantics similar to the Deliver
421 By SMTP service extension described in this memo, then convey the
422 Deliver By request to that system. Otherwise, relay the message as
423 if relaying to a SMTP server which does not support the Deliver By
4265. Delivery status notifications and extension
428 The format of delivery status notifications (DSNs) is specified in
429 [6]. DSNs generated in response to a Deliver By request should
430 include an Arrival-Date DSN field. This memo also extends the per-
431 message-fields of [6] to include a new DSN field, Deliver-By-Date,
432 indicating the deliver-by-time as computed by the MTA or SMTP server
433 generating the DSN. In the augmented BNF of RFC 822 [2], per-
434 message-fields is therefore extended as follows:
437 [ original-envelope-id-field CRLF ]
438 reporting-mta-field CRLF
439 [ dsn-gateway-field CRLF ]
440 [ received-from-mta-field CRLF ]
441 [ arrival-date-field CRLF ]
442 [ deliver-by-date-field CRLF ]
443 *( extension-field CRLF )
444 deliver-by-date-field = "Deliver-by-date" ":" date-time
450Newman Standards Track [Page 8]
452RFC 2852 Deliver By SMTP Service Extension June 2000
455 where date-time is a RFC 822 [2] date-time field as ammended by RFC
460 In the following sample SMTP dialog, the SMTP client requests that a
461 message from <eljefe@bigbiz.com> be delivered to
462 <topbanana@other.com> within 2 minutes (120 seconds) and returned
463 otherwise. This request takes the form of a BY parameter on the MAIL
464 FROM line of "BY=120;R" as shown below:
466 S: 220 acme.net SMTP server here
470 C: MAIL FROM:<eljefe@bigbiz.com> BY=120;R
471 S: 250 <eljefe@bigbiz.com> sender ok
472 C: RCPT TO:<topbanana@other.com>
473 S: 250 <topbanana@wherever.com> recipient ok
475 Suppose now that the receiving SMTP server in the above example needs
476 to relay the message to another SMTP server, mail.other.com. Owing
477 to the original by-mode of "R", the message may only be relayed to
478 another SMTP server which supports the Deliver By extension (Section
479 4.1.4). Further, when relaying the message, the Deliver By request
480 must be relayed. With this in mind, consider the following SMTP
483 S: 220 mail.other.com ESMTP server at your service
485 S: 250-mail.other.com
489 In the above dialog, the relaying SMTP server, acme.net, connects to
490 mail.other.com and issues an EHLO command. It then learns that the
491 Deliver By extension is supported but that the minimum by-time for a
492 by-mode of "R" is 4 minutes (240 seconds). This value exceeds the
493 message's original by-time and therefore necessarily exceeds the
494 remaining by-time. The relaying SMTP server thus ends the SMTP
495 session after which it must either attempt to follow any other MX
496 records or, if there are no more MX records to follow, must return
497 the message as undeliverable. Similar behavior would result if the
498 EHLO command was met with an error or did not include the DELIVERBY
501 Consider instead, the relaying SMTP session:
506Newman Standards Track [Page 9]
508RFC 2852 Deliver By SMTP Service Extension June 2000
511 S: 220 mail.other.com ESMTP server at your service
513 S: 250-mail.other.com
515 C: MAIL FROM:<eljefe@bigbiz.com> BY=98;R
516 S: 250 <eljefe@bigbiz.com> Sender okay
517 C: RCPT TO:<topbanana@other.com>
518 S: 250 <topbanana@wherever.com> Recipient okay
520 In the above, the relaying SMTP client relays the BY parameter with
521 the by-mode preserved and the by-time computed to be the remaining
522 number of seconds at the approximate time that the MAIL FROM command
523 was transmitted from the relaying SMTP client (acme.net) to the
524 receiving SMTP server (mail.other.com). In this example, 22 seconds
525 have elapsed since acme.net received the MAIL FROM line from the
526 original sending client and relayed the Deliver By request to
5297. MX based relaying considerations
531 Sites which wish to use the Deliver By SMTP service extension and
532 which direct their mail via MX records [9] need to ensure that all of
533 their MX hosts -- hosts to which their mail is directed by MX records
534 -- support the Deliver By extension. SMTP clients which support
535 Deliver By SHOULD NOT attempt multiple MX hosts looking for one which
538 MX hosts should pay careful attention to the min-by-time value they
539 present in response to EHLO commands. It is not practical for an MX
540 host to present a value which either (1) is substantially different
541 from that which can be handled by the destination host to which it
542 relays, or (2) doesn't recognize normal delivery latencies introduced
543 when the MX host relays mail to the destination host.
5458. Security Considerations
547 Implemention of Deliver By allows tracing of a mail transport system.
548 The by-trace field "T" explicitly requests that a trace be generated.
549 Moreover, even when the by-trace field is not used, a crude trace may
550 be generated by entering a series of messages into the transport
551 system, each with successively increasing by-time values; e.g.,
552 "BY=0;R", "BY=1;R", "BY=2;R". Probing, and in some cases tracing, can
553 be accomplished through other means: querying the visible SMTP
554 servers, investigating Received: header lines in bounced messages,
555 and using utilities such as "traceroute".
562Newman Standards Track [Page 10]
564RFC 2852 Deliver By SMTP Service Extension June 2000
5679. Other Considerations
569 SMTP servers which support the Deliver By SMTP service extension as
570 well as their associated MTAs are not required to assign any special
571 processing priority to messages with Deliver By requests. Of course,
572 some SMTP servers and MTAs may do so if they desire. Moreover,
573 delivery status notifications generated in response to messages with
574 Deliver By requests are not required to receive any special
575 processing. Consequently, users of this service should not, in
576 general, expect expedited processing of their messages. Moreover,
577 just because a message is sent with a "BY=60;R" parameter does not
578 guarantee that the sender will learn of a delivery failure within any
579 specified time period as the DSN will not necessarily be expedited
584 The author wishes to thank Keith Moore for providing much of the
585 initial impetus for this document as well as the basic ideas embodied
586 within it. Further thanks are due to Ned Freed and Chris Newman for
587 their reviews of this document and suggestions for improvement.
618Newman Standards Track [Page 11]
620RFC 2852 Deliver By SMTP Service Extension June 2000
625 [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
628 [2] Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax
629 Specifications: ABNF", RFC 2234, November 1997.
631 [3] Braden, R., Editor, "Requirements for Internet Hosts --
632 Application and Support", STD 3, RFC 1123, October 1989.
634 [4] Rose, M., Stefferud, E., Crocker, D., Klensin, J. and N. Freed,
635 "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
637 [5] Moore, K., "SMTP Service Extension for Delivery Status
638 Notifications", RFC 1891, January 1996.
640 [6] Moore, K. and G. Vaudreuil, "An Extensible Message Format for
641 Delivery Status Notifications", RFC 1894, January 1996.
643 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
644 Levels", BCP 14, RFC 2119, March 1997.
646 [8] Freed, N., "SMTP Service Extension for Returning Enhanced Error
647 Codes", RFC 2034, October 1996.
649 [9] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
655 Sun Microsystems, Inc.
656 1050 Lakes Drive, Suite 250
657 West Covina, CA 91790
660 Phone: +1 626 919 3600
662 EMail: dan.newman@sun.com
674Newman Standards Track [Page 12]
676RFC 2852 Deliver By SMTP Service Extension June 2000
67913. Full Copyright Statement
681 Copyright (C) The Internet Society (2000). All Rights Reserved.
683 This document and translations of it may be copied and furnished to
684 others, and derivative works that comment on or otherwise explain it
685 or assist in its implementation may be prepared, copied, published
686 and distributed, in whole or in part, without restriction of any
687 kind, provided that the above copyright notice and this paragraph are
688 included on all such copies and derivative works. However, this
689 document itself may not be modified in any way, such as by removing
690 the copyright notice or references to the Internet Society or other
691 Internet organizations, except as needed for the purpose of
692 developing Internet standards in which case the procedures for
693 copyrights defined in the Internet Standards process must be
694 followed, or as required to translate it into languages other than
697 The limited permissions granted above are perpetual and will not be
698 revoked by the Internet Society or its successors or assigns.
700 This document and the information contained herein is provided on an
701 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
702 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
703 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
704 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
705 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
709 Funding for the RFC Editor function is currently provided by the
730Newman Standards Track [Page 13]