> <[EMAIL PROTECTED]> wrote:
> > IMO his chart is incorrect: The RCPT 45X/DATA 55X case
> > should be "MAY RETRY".
> > I also don't understand why the chart lists the second
> > digits of responses.
> ACK, I ignored the second digit detail.
> >> SM's proposal is different: The second cell in the third
> >> column could be "MAY RETRY" if there was another recipient
> >> causing the DATA 5xx ...and if I understood it correctly.
> > No. It doesn't matter if there's another recipient or not.
> Above you wrote it should be MAY RETRY, so far we agree on
> what SM said. But you say I miss the point of the MAY RETRY,
> it doesn't depend on another recipient.
Correct, it doesn't.
> Now if there is only one 4xx recipient, or actually only one
> set of recipents (one or more) all getting 4xx, then I don't
> see how the sender reached the DATA state (for the DATA 5xx).
As I illustrated in my previous response this happens all the time when
pipelining is used. But even if pipelining isn't invoked, there's no rule that
says a client can't send a DATA command even when there are no valid
recipients.
> > Once a 4yx goes back to a recpiient as a RCPT response that
> > recipient is no longer under consideration by the server
> > and no subsequent responses refers to them at all.
> Okay. But if there are no recipients under consideration at
> all the DATA would be rejected with a 503, or wouldn't it ?
There's no rule that says it has to be. Indeed, RFC 2920 has this example:
S: <wait for open connection>
C: <open connection to server>
S: 220 innosoft.com SMTP service ready
C: EHLO dbc.mtview.ca.us
S: 250-innosoft.com
S: 250 PIPELINING
C: MAIL FROM:<[EMAIL PROTECTED]>
C: RCPT TO:<[EMAIL PROTECTED]>
C: RCPT TO:<[EMAIL PROTECTED]>
C: DATA
S: 250 sender <[EMAIL PROTECTED]> OK
S: 550 remote mail to <[EMAIL PROTECTED]> not allowed
S: 550 remote mail to <[EMAIL PROTECTED]> not allowed
S: 354 enter mail, end with line containing only "."
C: .
C: QUIT
S: 554 no valid recipients
S: 221 goodbye
This clearly shows a server accepting the data but rejecting the . because
there are no valid recipients.
> | If there was no MAIL, or no RCPT, command, or all such commands were
> | rejected, the server MAY return a "command out of sequence" (503) or
> | "no valid recipients" (554) reply in response to the DATA command.
> JohnL's strawman is about a case where the DATA got a 354,
> and the final dot after data got a 5xx. That's also what
> I'm talking about.
No, you're asserting that SM's argument only applies in the multi-recipient
case and that all sorts of added complexity is needed to handle the single
recipient case. I disagree.
> *If* Hector or SM talk about "got not 354 after DATA" it
> would be different...
Quite the contrary, a 5yz in response to a DATA is, in this context at least,
the same as getting one in response to the trailing dot.
> But there is no 4xx directly after
> DATA, therefore I think they meant "DATA 354 message. 5xx".
> > The single recipient example that best illustrates this
> > is one involving pipelining:
> > C: MAIL FROM:<a>
> > C: RCPT TO:<b>
> > C: DATA
> > S: 250 Sender OK
> > S: 452 Recipient over quota
> > S: 550 No valid recipients
> ACK, here you have 5xx instead of 354, not 5xx after 354.
> That is a different story,
Nope, it's the same story. This happens fairly regularly in practice:
C: MAIL FROM:<a>
C: RCPT TO:<b>
C: DATA
S: 250 sender OK
S: 452 over quota
S: 354 enter mail, end with line containing only "."
C: .
S: 554 no valid recipients
And you're in effect arguing that the message should bounce in this case. And
that's clearly wrong.
> and a clear MAY RETRY. Just
> in case, 2821bis apparently wants 554 here, not 550.
> >> SM's idea needs more rows to reflect eight scenarios
> >> of "mixed" RCPT outcomes.
> > Nope, it doesn't.
> From my POV it does: For an "all RCPT got 4xx" scenario
> I would never arrive at a "DATA 354 message. 5xx" outcome.
Sorry, tHat's just not reality with present-day SMTP servers.
> IOW I fear Hector's table was an over-simplification, and
> important cases like your pipelining and JohnL's strawman
> aren't covered.
They don't need to be. Again, you're seeing complexity where none
need exist.
Ned
