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? :-)
--
HLS
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.
Yes.
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.
Regards,
-sm
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com