ietf-smtp
[Top] [All Lists]

Re: Question related to draft-hansen-4468upd-mailesc-registry-02.txt and RFC3463

2007-08-04 12:47:10

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