[Top] [All Lists]

Fixing Greylist - Its usage of 451 vs 450

2007-11-17 23:00:41

Hi SM,

All I am stating is, if 451 is presumed incorrect (wrt to GL) for literal reasons, then so would be the others as well for literal reasons.

However, I believe you are saying the exception to the literal reason rule would be the "catch all" 450 response code when the reject reasons does not fit 451 or 452 because those two codes are deemed sacred for those two "finer" specific server rejection literal reasons only.

If so, then, you're right. :-)

But I can see why maybe the GL author probably chose 451:

 - The RFC prohibits creating new reply codes,

 - Not all systems support extended codes, making it harder to
   justify using 450,

 - 450 and 452 have more specific reasons one can relate to,

 - 451 has an "open ended" non-specific interpretation,

 - 451 seems to be reserved for the server admission that
   it just experienced a backend server problem but it is
   deemed to be temporary, i.e, its not the sender's fault,
   therefore it should try again,

 - Maybe 451 "Error In Processing" is what he wanted to
   tell the bad guy what is going on, because the good guy
   system is going to try again, so no problem.

But who knows? :-)


SM wrote:
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.



Hector Santos, CTO