[Top] [All Lists]

[Fwd: I-D ACTION:draft-hall-inline-dsn-00.txt]

2004-04-05 09:13:06

The I-D announcement is attached. The model defined is very similar to
LMTP, but differs in a couple of ways that make it more conservative.

Some highlights:

     [...] it has become common practice for different recipients to
     have their own content filters, and a single response code is not
     sufficiently granular to accurately reflect these differences. For
     example, some users may suffer under policy rules which require
     them to refuse email messages that contain certain words, while
     other users may be required to accept all messages regardless of
     content. But since the current SMTP model only allows a single
     response code for any given message, the only legitimate way to
     accommodate these differences is for all messages to be accepted
     so that they can be examined off-line, with one or more failure
     notification messages eventually being returned to the original
     sender whenever a message is rejected. This process introduces a
     significant burden on the recipient server, which must create,
     queue, and transfer each of the notification messages. Simply put,
     it would be much more efficient for the recipient system to be
     able to refuse email messages on a per-recipient basis while the
     transfer session was still active, thus moving the failure
     processing tasks to the sending system.


     The 352 response code is used by a server to indicate that the
     mailbox address specified in the associated RCPT TO command
     appears to be valid, but its validity will not be confirmed until
     after the message data has been transferred.


     The 353 response code is used by a server to indicate that the
     message data (as transferred with the DATA or BDAT commands, among
     other possibilities) appears to be valid, but that one or more of
     the recipients may refuse the message. When this response code is
     returned, absolute response codes for each of the recipients which
     were earlier acknowledged with a 352 response code during the
     envelope exchange MUST be provided, and must be provided in the
     order in which they were originally accepted. Once all of the
     recipient-specific response codes have been returned, the end of
     the sequence MUST be indicated with a 250 response code. Each of
     these response codes MUST be returned as independent responses
     (one per line, or one per multi-line response, as necessary).


     If the entire message was accepted or refused by every recipient,
     the 353 response code and the subordinate responses MAY be
     substituted with a single response code which reflects the global
     outcome. For example, if all of the recipients accepted the email
     message, then a single 250 response code MAY be returned in lieu
     of generating a 353 response code, the per-recipient response
     codes and the final 250 response code.


     The following dialog illustrates a transfer that incorporates
     historical response codes as well as the 352 response code (note
     that this example only shows the envelope and data exchange):

        C: MAIL FROM:<sender(_at_)example(_dot_)com> INLINE-DSN
        S: 250 okay
        C: RCPT TO:<postmaster(_at_)example(_dot_)net>
        S: 250 this recipient accepts all messages
        C: RCPT TO:<fighter(_at_)example(_dot_)net>
        S: 352 recipient looks okay but wait for confirmation
        C: RCPT TO:<lover(_at_)example(_dot_)net>
        S: 352 recipient looks okay but wait for confirmation
        C: RCPT TO:<old-user(_at_)example(_dot_)net>
        S: 550 this recipient no longer exists

        C: DATA
        S: 354 go ahead
        C: <sends data>
        C: <crlf>.<crlf>
        S: 353 data looks okay but wait for confirmation
        S: 550 5.6.0 <fighter(_at_)example(_dot_)net> refuses the content
        S: 250 2.1.5 <lover(_at_)example(_dot_)net> accepts the content
        S: 250 data accepted by some users

     Note that the postmaster and old-user mailboxes were not itemized
     in the deferred responses, since they were not deferred during the
     envelope exchange.

As per earlier discussion, there are several different ways to represent
post-data per-recipient acceptance, and the mechanisms used in the draft
seems to be the most conservative while causing the least interruption of
the existing state machine model and without obfuscating any of the
existing response code syntaxes.

Eric A. Hall                              
Internet Core Protocols

--- Begin Message ---
A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : SMTP Service Extension for Inline DSNs
        Author(s)       : E. Hall
        Filename        : draft-hall-inline-dsn-00.txt
        Pages           : 9
        Date            : 2004-4-2
This memo describes a mechanism for the negotiation and transfer 
     of per-recipient notification responses in SMTP.

A URL for this Internet-Draft is:

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request(_at_)ietf(_dot_)org with the word unsubscribe in the body 
of the message.  
You can also visit 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-hall-inline-dsn-00.txt".

A list of Internet-Drafts directories can be found in 

Internet-Drafts can also be obtained by e-mail.

Send a message to:
In the body type:
        "FILE /internet-drafts/draft-hall-inline-dsn-00.txt".
NOTE:   The mail server at can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the

--- End Message ---
<Prev in Thread] Current Thread [Next in Thread>
  • [Fwd: I-D ACTION:draft-hall-inline-dsn-00.txt], Eric A. Hall <=