Deliver By SMTP Service Extension (RFC2852)
Original Publication Date: 2000-Jun-01
Included in the Prior Art Database: 2019-Feb-13
Internet Society Requests For Comment (RFCs)
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. [STANDARDS-TRACK]
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 (C) The Internet Society (2000). All Rights Reserved.
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)  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.
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...