[Top] [All Lists]

Re: 2821bis consideration - New 2nd attempt Retry Strategy recommendation

2007-11-17 05:56:06

SM wrote:

It's technically incorrect. It's not an incompatibility problem. A sender should to be able to differentiate between a temporary rejection due to an error and one due to the receiver's policy decision.

Hi SM,

But who says the z=1 in 45z is "error in processing."?

There is nothing in the specs that officially states z=1 (3rd digit)
technically means is a error in processing.  If we do that, then it has
to equally apply to all the other response codes and their various ways
they are uses.  For example:

      551 User not local; please try <forward-path>
      421 <domain> Service not available, closing transmission channel
      251 User not local; will forward to <forward-path>
      551 User not local; please try <forward-path>

All these commonly used z=1 responses are not use for "error in
processing" ideas.

The only thing that is important are the first two digits.

If you are doing log analysis, you can categorize the different conditions by reply code and take whatever action may be necessary.

I once came across a site in the Far East that was temporary rejecting a message. As I didn't understand the text (language), I had to rely on the reply code to deduce whether they were explicitly rejecting messages from the sending host.

Sm, I can honestly say this is little way over my head. :-)

To me, a sender, which I presume to mean a "SMTP client software",
doesn't read Japanese, Chinese, Spanish, Spanglish, and even English.
It reads SMTP and in terms of the state machine, the first two digit is what matters.

So I am having a difficult time seeing how it can be "technically incorrect" if the design requirement for correct state machine automation is the 45x reading. Nothing more, no extended codes, no literals. That extra stuff is for humans. No?

IMO, log analyzers can not 100% depend on any 3rd digit to mean anything specific.

Also, to me, if we wanted to take it literally, error in processing should be a permanent rejection idea. Why? We had this discussion in length in regards when 55x or 45x is appropriate and I think we establish if the data is not going to change, providing the same input on new tries is not going change the state. So one can argue that the literal example for 451 is erroneous. It should be for some realistic "temporary reason" other then error in processing. Error in processing what? Your data? If so, it should not ask again to retry.

If we speaking in term of "Sender" the human, I guess I can could see how one might say it is functionally incorrect based on the literal interpretation, but not technical.

If we did take it literally, consider we would have only 9 possible unique temporary events for it. Are they only 9 functional reasons for a 45z response?

If we follow the literal, we can't use 450 because the literal is not
true in the same vain the 451 error in processing is not true. Neither is the literal for 452, insufficient system storage, although one could reason that "we don't have storage for spammers at this moment, so try again while we clear some space for you." for the 452 code. But that isn't true either. <g>

Anyway, to me what is more important is SMTP reliability and 45x is all
that is important.  In my opinion, the author of GL, really had no
choice but to use 451, probably because it is least use one.


Hector Santos, CTO