On Mon May 9 2005 14:27, Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
The point was that 4.7.1 does a much better job
It can't because (as you noted) it doesn't exist [*].
of explaining what's
going on - so it isn't a case where "the problem cannot be well expressed".
..."with any of the other provided detail codes". There is no 4.7.1.
In fact, 4.7.1 expresses perfectly the situation,
In the scenario posited (initial attempt, previous "greylisting" attempt
history not available), 4.7.5 is valid and seems appropriate:
X.7.5 Cryptographic failure
A transport system otherwise authorized to validate or decrypt
a message in transport was unable to do so because necessary
information such as key was not available or such information
was invalid.
Validation is denied on the first attempt because a record of a previous
attempt is not available, or the timestamp on such an available record
is invalid (insufficient interval since first attempt). x.7.1:
X.7.1 Delivery not authorized, message refused
The sender is not authorized to send to the destination. This
can be the result of per-host or per-recipient filtering. This
memo does not discuss the merits of any such filtering, but
provides a mechanism to report such. This is useful only as a
permanent error.
addresses sender/destination combinations based on per-host or per-
recipient filtering. Not wall clock issues.
except that 3463 didn't
seem to foresee that 4.7.X would be useful for many things....
No:
o there is no 4.7.1, only a 5.7.1.
o x.7.0 is unrestricted; 2.7.0, 4.7.0 and 5.7.0 are valid. However, x.7.0
refers to a message being returned, so it's unclear how that would apply
for 2.7.0 ("success" class). Moreover, the subject sub-code 7 is defined
to "report failures involving policies such as per-recipient or per-host
filtering and cryptographic operations", and "success" and "failures"
are incompatible. However, as we're discussing 4 (persistent transient
failure) and 5 (permanent failure) class sub-codes, that problem doesn't
enter into our discussion [Greg, please note, though]. One could argue
that 3464 is too generous in allowing combinations of sub-codes.
o x.7.2, x.7.3, x.7.4 are in the same boat as x.7.1; x = 5 (only).
o x.7.5 and x.7.6 are unrestricted, like x.7.0. However, they're defined
as failure indications, so 2.7.[56] makes no sense, as with x.7.0.
o x.7.7 explicitly allows any use, including success, though it's unclear
how "success" can apply to "Message integrity failure". Same as x.7.[056].
So in "4.7.x", you can choose an appropriate x from 0, 5, 6, 7; those are
the valid choices, and they are in fact "useful for many things". In your
specific case either 5 or 0 seem suitable.
* One of the problems with un-extended status codes is that some
implementations used undefined codes. Please don't encourage the same
for extended codes; that will require extended-extended codes to escape
from that interoperability problem. Note that there is already at least
one case of an incompatibility in the use of extended status codes (
http://www1.ietf.org/mail-archive/web/ietf/current/msg34254.html
) (to be fixed, I believe).