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.
[...] 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
S: 354 go ahead
C: <sends data>
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
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 http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
--- 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 https://www1.ietf.org/mailman/listinfo/I-D-announce
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
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:
NOTE: The mail server at ietf.org 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 ---