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