[Top] [All Lists]

Re: another per-recipient data reply proposal

2007-02-06 11:49:43

On 2/6/2007 1:00 PM, Claus Assmann wrote:

Ok, then we are now at the point where we "only" argue about the
"first reply after data"? That is, your current proposal looks like

* Client initiates by sending MAIL with an extension.
* RCPT returns normal reply codes (no 3yz)
* DATA and the last BDAT return (in order):
  1. 353 to indicate the start of server responses
    1.a. possible optimization: a single {2,4,5}yz reply code
         to indicate the overall transaction status.
  2. one reply code per recipient which got a 2yz reply.
  3. one end of mail reply code (as in the current ESMTP model,
    which is the same as the "final" reply code in


So we still have to decide between:

(I) get rid of step 1.: 353 (and increase the timeout to the
    first deferred RCPT response),
(II) or use 353 with the optimization 1.a.

and keep it as MAY. If we agree on that then the two issues that seem to
still be open:

1) the hard time limits

2) duplicate avoidance technology does not seem to have been resolved to
everyone's satisfaction yet

Eric A. Hall                              
Internet Core Protocols