On Dec 16, 2007, at 9:34 PM, Jim Fenton wrote:
Michael Thomas wrote:
My suggestion is to just to take the exception/violation reason.
For example, "all-exception", "strict-exception", "nxdomain-
exception" and the like. A single word even if it's value-neutral
gives the wrong impression that all exceptions/violations/suspicion
should be given the same weight. Just saying what it is that went
wrong doesn't do that.
+0.5
Agree that a name change is in order, and that we need more than a
binary 1/0 result.
But "exception" makes it sound like a kernel panic or something.
Hector had some alternative interpretations of "exception" too. My
suggestion: "non-compliant"/"compliant".
Mike's breakdown provides a finer granularity of states. Policy
exceptions happen all the time with things like SELINUX without it
being a panic or crash. The specification should not attempt to
combine various states "as-if" they were just one state. Experience
will dictate how each state is best handled. While a message might be
fully compliant, there can be many reasons a message might be found
"non-compliant". These reasons could be termed "*-exceptions".
+1 on Mike's suggestion, and +.5 on Jim's.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html