[Top] [All Lists]

Re: another per-recipient data reply proposal

2007-02-04 20:22:00

On 2/4/2007 8:07 PM, Claus Assmann wrote:
Here's another proposal based on my implementation experiences:

* Client initiates by sending MAIL with an extension.
* RCPT returns normal reply codes.
* DATA and the last BDAT return (in order):
  - one reply code per recipient which got a 2yz reply.
  - one end of mail reply code (as in the current ESMTP model,
    which is the same as the "final" reply code in

This is the approach the causes the least changes to existing code
(at least in the MTAs that I maintain) and does not introduce complex
error handling. Maybe others can take a look at exim, postfix,
qmail, etc?

This is basically the DEFERRALS model with two changes. One is that you've
dropped the 352 response to RCPT, which I'm not married to. The other
change is that you've dropped the 353 response code to signal the start of
deferred RCPT responses, which is a bit of a problem.

See the discussion on reliability timers earlier--a start code is going to
be important. Also see the last post by me in re global filters--this is
the right place to issue such a response. Frank's is also correct that
there is some efficiency and reliability if we can avoid enumerating long
lists of response codes. For all those reasons I'd like to ask you to try
using it and see if it's not too hard.

Eric A. Hall                              
Internet Core Protocols