<ned+ietf-smtp(_at_)mrochek(_dot_)com> 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:<mrose(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us>
C: RCPT TO:<nsb(_at_)thumper(_dot_)bellcore(_dot_)com>
C: RCPT TO:<galvin(_at_)tis(_dot_)com>
C: DATA
S: 250 sender <mrose(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us> OK
S: 550 remote mail to <nsb(_at_)thumper(_dot_)bellore(_dot_)com> not allowed
S: 550 remote mail to <galvin(_at_)tis(_dot_)com> 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