A new Request for Comments is now available in online RFC libraries.


        RFC 2852

        Title:      Deliver By SMTP Service Extension
        Author(s):  D. Newman
        Status:     Standards Track
        Date:       June 2000
        Mailbox:    dan.newman@innosoft.com
        Pages:      13
        Characters: 29285
        Updates:    1849 

        I-D Tag:    draft-newman-deliver-03.txt

        URL:        ftp://ftp.isi.edu/in-notes/rfc2852.txt


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 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.

This is now a Proposed Standard Protocol.

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.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.