At 05:38 AM 8/9/2008, Hector Santos wrote:
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.
You are ignoring the creativity some people resort to for SMTP.
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.
That is at odds with what you said about about the 55x being
applicable to the recipient list.
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 meaning of the reply code is not changing.
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 |
+----------------------------------------------+
You are using a "MAY RETRY". It is more of a MUST here. I do not
think the third column of the second line is correct. I am not
inferring any relation between RCPT and DATA which is why I would
argue against using the above chart.
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.
You have your views, I have mine. :-) If you want to ensure reliable
delivery, then not retrying in the case I mentioned may affect delivery.
Thats not to say we can have NEW ideas but that is not what we have here.
I'm not pushing any new idea.
Regards,
-sm