Deliver By SMTP Service Extension
RFC 2852
Document | Type |
RFC - Proposed Standard
(June 2000; Errata)
Updates RFC 1894
Was draft-newman-deliver (individual)
|
|
---|---|---|---|
Author | Daniel Newman | ||
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 2852 (Proposed Standard) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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 )Show full document text