Deliver By SMTP Service Extension
RFC 2852

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

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 )