On Tue, Feb 06, 2007, Eric A. Hall wrote:
Does your pseudo code look correct to you?
I didn't run it through lint, sorry
Lint wouldn't have helped :-)
However, this little bug demonstrated my point about the complexity.
Section 6.2 says the following:
| If the message is accepted or refused by every recipient, the 353
| response code and the subsequent responses MAY be substituted with
| a single response code which reflects the global outcome.
although that could probably be clarified. I think the particulars would
be up to the implementation. Here are some scenarios:
Keep it simple unless there is a good reason for complexity. If
we want to keep this optimization, then MAY should be changed to
SHOULD (not MUST as the timeout is too short to always make a
decision).
I thought we had eliminated deferred RCPT so that only the 25x recipients
were processed. If an implementation wants to manage some of those
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
this:
* 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
draft-hall-deferrals).
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.
(the other alternative:
(III) use 353 without the optimization 1.a.
doesn't look very useful to me).