ietf-smtp
[Top] [All Lists]

Re: retry question

2008-08-09 16:55:09

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
<Prev in Thread] Current Thread [Next in Thread>