> RFC 3463 describes x.7.x as "Security or Policy". It seems only 5.7.1
> and 5.7.2 are policy based while the remainder are security related. In
> draft-hansen-4468upd-mailesc-registry-02.txt adds x.7.13 as another policy
> related status code.
> 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 cases.
> x.8.4 to many connections
> x.8.5 to many bad recipients
> x.8.6 images not allowed here
> x.8.7 content contains SPAM URL
> etc
> basically the x.8.x codes would try to break out all the different
> meanings that 5.7.1 has been used to indicate many different types of
> policy.
> By separating policy and security, one could simplify coding logic to a
> level where any x.8.x code is policy related (plus x.7.1 and x.7.2).
> I'd like to author a RFC that is specific to just policy codes. Any
> feedback is greatly appreciated.
Having additional clearly defined codes is always a good thing IMO so I fully
support the creation of such a document, regardless of whether it elaborates
new 7.x codes or creates splits out policy codes into a new group.
Ned
