[Top] [All Lists]

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

2007-11-17 16:14:51

Hi Hector,
At 04:37 17-11-2007, Hector Santos wrote:
But who says the z=1 in 45z is "error in processing."?

Quoting RFC 2821:

  "The third digit gives a finer gradation of meaning in each category
   specified by the second digit.  The list of replies illustrates this.
   Each reply text is recommended rather than mandatory, and may even
   change according to the command with which it is associated.  On the
   other hand, the reply codes must strictly follow the specifications
   in this section.  Receiver implementations should not invent new
   codes for slightly different situations from the ones described here,
   but rather adapt codes already defined."

There is nothing in the specs that officially states z=1 (3rd digit)

See the above text about "finer graduation".

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.

I'm not saying that z=1 means "error in processing". There's a subtile difference between the theory of reply codes and practice.

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


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.

There's also SMTP operations. The SMTP client software only deals with machine state, the text is for us to decipher.

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?

The extra stuff is for humans.

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.

There are temporary and permanent error conditions. If there is an error in processing (451), it doesn't mean that the message won't be processed successful on the next retry. A permanent rejection causes a breakdown in the communication channel.