On 29 Jun 2004 at 17:22, John W. Baxter wrote about
"Re: [Exim] Server response to error":
| On 6/28/2004 20:52, "Fred Viles" <fv+exim@???> wrote:
|
| > On 28 Jun 2004 at 20:09, John W. Baxter wrote about
| > "Re: [Exim] Server response to error":
| >
| > |...
| > | Given the RFCs, I believe Exim has no choice but to say 503 in response to
| > | DATA if there were no valid recipients, pipelining or not.
| >
| > Which language led you to that conclusion?
| >
| > Based on a quick read of 2920 and 2821, ISTM that it's appropriate to
| > return 451 ("same sequence of commands may work later") to DATA when
| > you've returned 450 to some RCPTs. What did I miss?
|
| Oops...thanks for keeping me honest. I had looked this up and concluded
| "Exim is not wrong". And remembered that, without remembering that Exim
| would also not be wrong if it sent 554. And seemingly also wouldn't be
| wrong if it didn't send either of those (which would leave what? 354?
| 4xy?).
According to 4.3.2: 451, 554, 503 are valid error codes for DATA,
while 552, 554, 451, 452 are valid errors after <CRLF>.<CRLF>.
IMHO the RFC does not make it very clear how a client is expected to
react to 4xx for RCPT followed by 5xx for DATA. There's the general
words about the client being "discouraged" from trying "the
operation" again if it gets 5xx, and there's an explicit exception
for 5xx after the end of message data (the client MAY retry), but no
such exception mentioned for 5xx after DATA.
2920 just says the pipelining client should process all the responses
(IOW the DATA response must be processed even though all the RCPTs
were 4xx-ed).
AFAICT neither exim nor Groupwise can be shown to be "wrong"
according to RFC, but the result is certainly not what's wanted.
So while exim may not be wrong, I think a good argument can be made
that returning 451 for DATA would be "righter" just based on the
general error code semantics given in 4.2.1:
| 4yz Transient Negative Completion reply
| The command was not accepted, and the requested action did not
| occur. However, the error condition is temporary and the action may
| be requested again.
| ...
This is clearly the case here. The cause of the rejection of the
DATA command *is* transient: it's caused by a transient rejection of
RCPT. The same sequence of commands (including DATA) will be
accepted if they are retried.
| 5yz Permanent Negative Completion reply
| The command was not accepted and the requested action did not
| occur. The SMTP client is discouraged from repeating the exact
| request (in the same sequence).
|...
And we don't *want* to discourage the client from trying again in
this case.
| RFC2821/3.3 a few paragraphs down under DATA
|
| > - 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)
Which doesn't seem applicable, semantically, when pipelining is in
effect.
| > or "no valid recipients" (554) reply in response to the DATA
| > command.
This would be more logical, but ISTM 451 would be more robust as far
as interoperability goes. That may or may not make Groupwise retry,
but if it doesn't it becomes clearly a Groupwise problem.
- Fred
