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.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com