Movatterモバイル変換

Network Working Group                                           D. NewmanRequest for Comments: 2852                               Sun MicrosystemsUpdates:1894                                                   June 2000Category: Standards TrackDeliver By SMTP Service ExtensionStatus of this Memo   This document specifies an Internet standards track protocol for the   Internet community, and requests discussion and suggestions for   improvements.  Please refer to the current edition of the "Internet   Official Protocol Standards" (STD 1) for the standardization state   and status of this protocol.  Distribution of this memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (2000).  All Rights Reserved.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 request.  A Deliver By request serves to express a message's   urgency and to provide an additional degree of determinancy in its   processing.  An indication of an urgent message's status within a   given time period may be requested and will be honored.  Moreover,   the message may be withdrawn if not delivered within that time   period.   A typical usage of this mechanism is to prevent delivery of a message   beyond some future time of significance to the sender or recipient   but not known by the MTAs handling the message.  For instance, the   sender may know that the message will be delivered as a page but does   not consider the message to be sufficiently important as to warrant   paging the recipient after business hours. In that case, the message   could be marked such that delivery attempts are not made beyondNewman                      Standards Track                     [Page 1]

RFC 2852           Deliver By SMTP Service Extension           June 2000   17:00.  Another common usage arises when a sender wishes to be   alerted to delivery delays.  In this case, the sender can mark a   message such that if it is not delivered within, say, 30 minutes, a   "delayed" DSN is generated but delivery attempts are nonetheless   continued.  In this case the sender has been allowed to express a   preference for when they would like to learn of delivery problems.1.  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", "MUST NOT", "SHOULD" and "SHOULD NOT" in this   document are to be interpreted as described inRFC 2119 [7].2.  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.        The optional parameter, when supplied, is a comma separated list        of options.  Only one option, a min-by-time, is specified in        this document.  Future documents may extend this specification        by specifying additional options.  The min-by-time is a fixed        integer indicating the fixed minimum by-time that the server        will accept when a by-mode of "R" is specified as perSection 4.        The syntax of the optional parameter is as follows, using the        augmented BNF notation ofRFC 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*<any CHAR excluding SP, COMMA and all control                           characters (US ASCII 0-31 inclusive)>      SP               = <the space character (ASCII decimal code 32)>      COMMA            = <the comma character (ASCII decimal code 44)>        If the parameter is omitted, no information is conveyed about        the server's fixed minimum by-time.   (4)  One optional parameter using the keyword "BY" is added to the        MAIL FROM command.   (5)  The maximum length of a MAIL FROM command line is increased by        17 characters by the possible addition of the BY keyword and        value.   (6)  No additional SMTP verbs are defined by this extension.3.  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 inSection 4.  Any attempt by a client   to specify a by-mode of "R" and a by-time strictly less than this   limit, min-by-time, will be rejected with a permanent failure (55z)   reply code.   A SMTP server that supports the Deliver By SMTP service extension   will accept the extended version of the MAIL FROM command described   inSection 4.  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, theNewman                      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 FROM   command only to later return an error response to the RCPT TO, DATA,   or dot command.4.  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 inRFC 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 ofRFC2234 [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 inSection 4.1, the by-mode indicates the action the   SMTP server must take should it not be possible to transmit the   message within by-time seconds.   Note that by-time is a delta time: the number of seconds within which   to deliver the message.  This delta time does not extend an MTA's   normal retention period for undeliverable messages nor is it a   "deliver after" time.   A delta time is used so as to prevent problems associated with   differences in system clocks between clients and servers.  Servers in   receipt of a valid by-parameter are expected to convert the by-time   into a locale-specific absolute time called the deliver-by-time.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 current   locale-specific time and thereby arriving at a locale-specific   absolute time which is by-time seconds in the future or past,   depending upon the arithmetic sign of by-time.  The message is then   to be delivered by the deliver-by-time.  The sending client and   receiving server should assume the transmission time of the MAIL FROM   command to be instantaneous.  Clearly, it will not be and network   latency will introduce an error, the nature of which will be to   extend slightly the effective by-time. The more hops the message   takes, the more pronounced the effect will be owing to the cumulative   nature of this latency-induced error.   In the case of a by-mode of "N", it is possible that by-time may be   zero or negative.  This is not an error and should not be rejected as   such.  It indicates a message for which the deliver-by-time occurred   -(by-time) seconds in the past.  [Here, "-(by-time)" represents the   arithmetic negation of the by-time value.]  Zero and negative values   are allowed so as to preserve information about any requested   delivery time information -- information which the delivering MTA may   wish to include with the delivered message for the benefit of the   recipient or to show in a DSN or NDN (non delivery notification).   In the case of a by-mode of "R", a zero or negative by-time is a   syntax error. In such a case, the SMTP server SHOULD return a   permanent failure (501) SMTP reply code in response to the extended   MAIL FROM command.  If the SMTP server also supports enhanced error   codes [8], then an enhanced error code of 5.5.4 SHOULD also be   returned.   If the by-time is a valid by-time specification but the SMTP server   cannot honor or accept it for a server-specific reason, then SMTP   server SHOULD respond with either a 455 SMTP response if the   condition is transient or a 555 SMTP response if the condition is   permanent. In addition, if the SMTP server also supports [8], a   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 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, Sections4.1.1-4.1.5.   Delivery status notifications generated in response to processing a   message with a Deliver By request should include both the optional   Arrival-Date DSN field as well as the new Deliver-By-Date DSN field   described inSection 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's   normal message retention period: an MTA MAY return a message as   undeliverable before the deliver-by-time has been reached.4.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].4.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.  If the MTA's message retention period is less than   by-time, the MTA MAY return the message as undeliverable before   deliver-by-time has been reached.  However, the message MUST still be   handled in accord with Sections4.1.1-4.1.5.   If deliver-by-time has not yet passed and the message cannot be   delivered for permanent reasons, then the SMTP server or MTA MUST   return a "failed" DSN with an appropriate status for each recipient   address with either no NOTIFY parameter specified or for which the   NOTIFY parameter includes "FAILURE".4.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".Newman                      Standards Track                     [Page 6]

RFC 2852           Deliver By SMTP Service Extension           June 20004.1.4.  Relaying to another SMTP server   Sections4.1.4.1 and4.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".   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.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 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 inSection 2.   If the message requires relaying in order to be delivered yet cannot   be relayed, then the message is deemed to be undeliverable for   permanent reasons andSection 4.1.2 should be applied.Newman                      Standards Track                     [Page 7]

RFC 2852           Deliver By SMTP Service Extension           June 20004.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 ofSection 6.2.1(c) of [5].4.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.5.  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 ofRFC 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-timeNewman                      Standards Track                     [Page 8]

RFC 2852           Deliver By SMTP Service Extension           June 2000   where date-time is aRFC 822 [2] date-time field as ammended byRFC1123 [3].6.  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     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 (Section4.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:Newman                      Standards Track                     [Page 9]

RFC 2852           Deliver By SMTP Service Extension           June 2000     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 client and relayed the Deliver By request to   mail.other.com.7.  MX based relaying considerations   Sites which wish to use the Deliver By SMTP service extension and   which direct their mail via MX records [9] need to ensure that all of   their MX hosts -- hosts to which their mail is directed by MX records   -- support the Deliver By extension. SMTP clients which support   Deliver By SHOULD NOT attempt multiple MX hosts looking for one which   supports Deliver By.   MX hosts should pay careful attention to the min-by-time value they   present in response to EHLO commands.  It is not practical for an MX   host to present a value which either (1) is substantially different   from that which can be handled by the destination host to which it   relays, or (2) doesn't recognize normal delivery latencies introduced   when the MX host relays mail to the destination host.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".Newman                      Standards Track                    [Page 10]

RFC 2852           Deliver By SMTP Service Extension           June 20009.  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.Newman                      Standards Track                    [Page 11]

RFC 2852           Deliver By SMTP Service Extension           June 200011.  References   [1]  Postel, J., "Simple Mail Transfer Protocol", STD 10,RFC 821,        August 1982.   [2]  Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax        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 Status        Notifications",RFC 1891, January 1996.   [6]  Moore, K. and G. Vaudreuil, "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",BCP 14,RFC 2119, March 1997.   [8]  Freed, N., "SMTP Service Extension for Returning Enhanced Error        Codes",RFC 2034, October 1996.   [9]  Partridge, C., "Mail Routing and the Domain System", STD 14,RFC974, January 1986.12.  Author's Address   Dan Newman   Sun Microsystems, Inc.   1050 Lakes Drive, Suite 250   West Covina, CA  91790   USA   Phone: +1 626 919 3600   Fax:   +1 626 919 3614   EMail:  dan.newman@sun.comNewman                      Standards Track                    [Page 12]

RFC 2852           Deliver By SMTP Service Extension           June 200013.  Full Copyright Statement   Copyright (C) The Internet Society (2000).  All Rights Reserved.   This document and translations of it may be copied and furnished to   others, and derivative works that comment on or otherwise explain it   or assist in its implementation may be prepared, copied, published   and distributed, in whole or in part, without restriction of any   kind, provided that the above copyright notice and this paragraph are   included on all such copies and derivative works.  However, this   document itself may not be modified in any way, such as by removing   the copyright notice or references to the Internet Society or other   Internet organizations, except as needed for the purpose of   developing Internet standards in which case the procedures for   copyrights defined in the Internet Standards process must be   followed, or as required to translate it into languages other than   English.   The limited permissions granted above are perpetual and will not be   revoked by the Internet Society or its successors or assigns.   This document and the information contained herein is provided on an   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Acknowledgement   Funding for the RFC Editor function is currently provided by the   Internet Society.Newman                      Standards Track                    [Page 13]