ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Issue 1530 - replace use of term "suspicious"

2007-12-18 10:30:45
Damon wrote:
Take your pick:
http://thesaurus.reference.com/browse/exception

I don't have a problem with "exception" in this case. I believe that
it describes what is happening accurately.

I think that will all depends on who is reading it.

To me, an exception is not an ordinary event that one expected. Since I believe SSP is just validating the expected signing behavior as described by the domain, it is either a TRUE or FALSE condition - no exception.

Checking for NXDOMAIN is a safe result to check for. Checking to see if its a given POLICY matches what is actually shown in the message, is a safe result to check for. I don't see those as exceptions.

Now, if one can't make heads or tails of a SSP check, then maybe that can be viewed as an exception - because something happen you didn't expect.

Here's the thing: The fact you and others had to look it up, means a lot here. Most people are not going to be wanting to have their dictionary or thesaurus around when they read these RFCs. The fact there are a "take your pick" untold semantics for exception tells ya it will probably cause one to scratch their head than now.

I say being "Specific is Terrific!"

As Frank suggested, PASS or FAIL is just as good. Most people don't need a dictionary for that.

I suggested SSP Complete, maybe good if you understand 5016.

I also suggested negative/positive classification, and this has a industry wide understanding and it is already in place for this type of work. SMTP uses positive/negative response code and classifications ideas. Spam Assassin already uses positive/negative classification as well as other heuristic based systems. Odds are good you will find more neural networks or fuzzy logic systems play a role, if not already.

Jim's non-compliant/compliant is also straight to the point. But not sure it helps in laying the ground work to handling results.

While "exception" can work for me personal, I don't see it as a good candidate for replacing suspicious. We might as will say "SSP Fault" or "SSP Failure".

My pennies of course.

--
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>