--On Saturday, 04 August, 2007 12:26 -0700
It seems to me that Security and Policy could be separate.
Since the majority of the x.7.x codes are security related,
it seems logical to dedicate x.7.x to just security. For
policy codes, I suggest using a new subject code of 8.
Therefore all policy codes would be x.8.x. It would be
initially populated with x.7.1, x.7.2 and x.7.13 as x.8.1,
x.8.2 and x.8.3 respectively. The current x.7.1 and x.7.2
would be kept for legacy reasons. x.7.13 seems newly defined,
so I don't believe there would be a legacy issue there.
Additional values that seem relevant to policy could be:
I see no problem doing this, but OTOH I'm not seeing a lot of
clear benefit to doing it either. The closest I can come is
that it might be nice to be able to tell the different between
an unknown policy and unknown security error, that is, making
a distinction between 5.7.0 and 5.8.0 might be useful in some
The difficulty, IMO, is that since many of the "policy"
decisions have been made in practice to provide better security,
the distinction may not be clear and splitting things into
multiple codes may do as much to obscure what is going on as to
clarify it. As the obvious example, if I reject a message
because I've concluded that the apparent sender is often a
source of malware, but without having examined the message
sufficiently to make a solid determination of whether malware is
present in it, is that "security" or "policy"? Conversely, if I
detect malware as being present and identify it and then reject
the message, is that "security" or a "policy" of blocking known
malware at the MTA rather than letting user anti-virus software
sort it out?
I don't have a major objection to the proposed change, and
better documentation is always A Good Thing, but, especially
since there would be no way to tell whether a legacy system
emitting at 5.7.z code had been upgraded or not, I'm not
convinced that the benefits of this are worth the effort.