SM wrote:
If you interpret c as invalid because of the 554 reply code, then you
end up turning the 450 reply code in the RCPT TO into a 550 reply code.
-1.
All it (DATA 55x) means that <c>, nor anyone else, isn't going to get
any mail and the client SHOULD not retry that particular payload again
for <c> nor anyone else. Its really that simple.
Prior to the DATA state, the <c> RCPT reply code (450) doesn't means
its not invalid but it does mean it is not acceptable for the specific
SMTP session regardless of the payload and the payload isn't going
change that fact. The reply at RCPT is not a function of the DATA
because DATA doesn't exist.
I'm sorry, there is no such idea of sending a reply code whose meaning
changes at a later state. I've seen nothing in the specification since
821, 1113, to 2821 and 2821bis, nor all our years in implementation
and interoperability that contradicts this fundamental understanding.
The only ambiguity I see is what T. Finch brought up. The one Levine
brought up, does not apply.
IOW, if a DATA 55x, 45x is issued, there is no expectation of delivery
for anyone. But you can retry <c> if the DATA was 45x - thats a
client retry decision. The server can only hope it doesn't try to
repeat <b> (a DUPE) or bother with permanently rejected <d>.
You would have to retry b and c if the reply code for the "end of
message" was a 4yz.
Sure, but not for DATA 55x which is what I believed was stated. See
chart below.
Here is a chart guideline that can used as a baseline for retry
decisions for mixed RCPT reply codes:
DATA
+----------------------------------------------+
| | 250 | 45x | 55x |
|--------+-----------+------------+------------|
| 250 | DELIVER | MAY RETRY | NO RETRY |
RCPT |--------+-----------+------------+------------|
| 45x | MAY RETRY | MAY RETRY | NO RETRY |
|--------+-----------+------------+------------|
| 55x | NO RETRY | NO RETRY | NO RETRY |
+----------------------------------------------+
I don't mean to sound so adamant about this but I've have a long
ethical strong principle here of acceptance and rejection where retry
state logic is extremely important to assure reliable delivery. The
principle is not just molded from internet email but was a common
concept across other networks as well. It can not be fundamentally
broken otherwise we will have chaos.
Thats not to say we can have NEW ideas but that is not what we have here.
I hope we can keep our eye on the ball here which is Tony Finch
original note on how to handle mixed 250 + 450 RCPT reply codes for
DATA 250 responses. Anything else we are changing the specs and state
machine.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com