rfc2852.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 732 行 · 第 1/2 页

Network Working Group                                           D. Newman
Request for Comments: 2852                               Sun Microsystems
Updates: 1894                                                   June 2000
Category: Standards Track


                   Deliver By SMTP Service Extension

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

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 beyond



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 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 in RFC 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 per Section 4.

        The syntax of the optional parameter is as follows, using the
        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*<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 in Section 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
   in Section 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, the





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 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 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 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, Sections 4.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 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'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 Sections 4.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 2000


4.1.4.  Relaying to another SMTP server

   Sections 4.1.4.1 and 4.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".