ietf-smtp
[Top] [All Lists]

Overview of per-recipient data reply proposals (was: Fwd: I-D ACTION:draft-hall-deferrals-00.txt)

2007-02-04 10:44:47
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"

Attachment: signature.asc
Description: Digital signature

<Prev in Thread] Current Thread [Next in Thread>