John Leslie wrote:
Hector Santos <hsantos(_at_)santronics(_dot_)com> wrote:
In no way I am advocating the following for John to add to 2821bis,
but based on happen here, this is what needs to be added to 4.2.5:
4.2.5. Reply Codes After DATA and the Subsequent <CRLF>.<CRLF>
...
When an SMTP server returns a permanent error status (5yz) code
after the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT
make any subsequent attempt to deliver the message. As with
temporary error status codes, the SMTP client retains responsibility
for the message, but SHOULD not again attempt delivery to the same
server without user review of the message and response and
appropriate intervention.
+ However, there is one exception to this recommendation: If
+ any of the RCPT TO reply codes in a multiple recipients
+ session are 4yz, the client SHOULD again attempt to deliver
+ the message to the same server without requiring user review.
+ See Section 4.5.4.1 for retry strategies.
Finally! I understand Hector's point.
Read carefully:
"
" the SMTP client retains responsibility for the message, but SHOULD
" not again attempt delivery to the same server without user review
" of the message and response and appropriate intervention.
This text _is_ unnecessarily confusing.
It doesn't say _what_ the client shouldn't retry.
And it only deprecates retry to the "same server".
Clearly, most of us have "assumed" what the client shouldn't retry
is the same triplet from-to-data; and assumed we shouldn't retry that
to any other MX server either.
But that is not what the text says. :^(
We _could_ treat this as a typo -- that we always meant to the
same "triplet", not the same "server"; but I'd have to agree with
John Klensin if he says that would exceed the AUTH48 bounds.
(If anyone asks, I cannot support Hector's proposed text...)
Note:
Not even Hector doesn't support Hector's proposed text. :-)
But if the battle was being lost with this, then at very least, make
the specs consistent with what "people" are saying how things work.
For the record, I don't agree, not one bit with the idea
Allow Retry logic for 4yz/5yz set of RCPT/DATA reply codes
IMTO, its wrong, it earth shattering and until people can show me
otherwise (via software code, not subjective talk, not operator
options), I doubt clients will actually honor it. i.e. Most will
follow the 5yz specs and not retry.
My major concern because of this interpretation for 5yz is to begin
seeing server "thinking" they can issue a 5yz with the intent to drive
clients to perform a retry on any of their temporary rejected RCPT
commands. I really hope not because the specs already provide for all
this. The proper signal is 4yz or if the server is going to accept at
least 1 RCPT, then use 250. In both cases, the specs allow the client
to retry the temp rejected RCPT.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com