I'll try to provide an overview of various proposals I am aware of which
allow a server to return different reply codes for different recipients
after receiving the data. They are in roughly chronological order.
LMTP (RFC 2033, <URL:http://tools.ietf.org/html/rfc2033>):
* Client initiates by sending LHLO.
* RCPT returns normal reply codes.
* DATA and the last BDAT return one reply code per recipient which
got a 2xx reply.
* Message is accepted for a recipient when server sends the data
reply for that recipient.
draft-varshavchik-data-smtpext
<URL:http://www.courier-mta.org/draft-varshavchik-exdata-smtpext.txt>:
* Client initiates by sending MAIL FROM with an extension.
* RCPT returns normal reply codes.
* DATA returns a single 558 multiline reply which contains nested
SMTP replies.
* It isn't clear when the message is accepted by the server: When it
sends the nested submessage or when it sends the final line of the
message.
datafirst (David Nicol on the ASRG mailing list,
<URL:http://www1.ietf.org/mail-archive/web/asrg/current/msg12808.html>:
* Client initiates by sending MAIL FROM with an extension.
* DATA is sent after MAIL FROM but before the first RCPT TO.
* RCPT returns normal reply codes.
* Presumably, each reply to a RCPT command accepts the mail for this
recipient.
* This has the advantage of only returning one reply code for each
recipient (unlike all other proposals, which return 2), but at the
cost of transferring the data even if there are no valid
recipients.
recheck Tony Finch on the ASRG mailing list:
<URL:http://www1.ietf.org/mail-archive/web/asrg/current/msg12839.html>:
* Client initiates by sending MAIL FROM with an extension.
* RCPT can return 350 in addition to normal reply codes.
* DATA returns a normal reply, but if there were any 350 replies,
the transaction isn't finished yet.
* Client sends a RECHECK command for each recipient which got a 350
reply. RECHECK commands may be issued in any order.
* The message is accepted for a particular recipient when the server
sends the reply to the RECHECK command.
* The transaction must be finished with RSET.
* Sort of the opposite of datafirst: This one doubles the number of
commands as well as the number of replies. But it keeps the "one
reply per command" model of SMTP.
draft-hall-deferrals:
* Client initiates by sending MAIL FROM with an extension.
* RCPT can return 352 in addition to normal reply codes.
* DATA and the last BDAT return one reply code per recipient which
got a 352 reply. Additionally, they return a 353 reply code to
signal that multiple reply codes follow before the individual
reply codes and a final (2xx/4xx/5xx) reply code to signal whether
the message has been accepted.
* The message is accepted for all recipients for which a 2xx reply
has been sent if the final reply code is also 2xx. Otherwise it
has been accepted for none.
David Nicol also suggested off-list an interesting variant where DATA is
sent by the client after it receives the first 2xx reply to a RCPT
command. The client can then continue to send additional RCPT commands.
That's it. Have I forgotten anything?
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp(_at_)hjp(_dot_)at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
signature.asc
Description: Digital signature