Hello Andy, Thursday, October 9, 2008, 2:00:49 PM, you wrote:
>>> SNF code spam threshold (ASSP_SNF_Threshold) > The SNF result code threshold that is considered spam. <snip/> > If so, I don't think that this can be handled with a "greater than" type of > threshold, since your list from 20 to 63 are not at all in order of > "severity" (e.g., Caution is higher than Truncate, Experimental is higher > than Malware etc.). Strictly speaking, SNF doesn't really use a weighting or severity paradigm. SNF is a discrete logic system-- something either matches or it doesn't. There are different result codes for different rule groups but with few exceptions a match in any rule group is an accurate indicator of spam. Where the pattern matching engine crosses with the IP reputation system (GBUdb) the only result code you might not want to trust at the same level is the caution result -- but in most cases there is no meaningful distinction. > I would say this parameter would have to be a comma-delimited list of result > codes that you want to treat as Spam - or, if there is some "confidence > factor" that Sniffer uses internally, then that could be translated into an > ASSP score... I'm not sure what is possible with the plugin interface. The design of the plugin at the moment is a binary decision-- either the message is spam, or not. There is no way to say "how spammy" except to tune the plugin overall. Based on that limitation we ended up with a threshold. As a matter of convention, all nonzero SNF results indicate spam. The exception to this is when we create specialized rules. When we do this we usually code those rule groups with a symbol value (result code) at or below 10. For example, system specific white rules are usually coded to result code 1. After that there are really only 3 significant "levels" associated with SNF result codes. The caution result (40) _might_ be considered less certain that the other rules-- though the default tuning for the caution range is very conservative. The ordinary result codes for pattern matches are considered reliable. Finally, a truncate (20) result indicates that the IP reputation is so bad that there is no need to look at the contents. This result could be considered more certain than "ordinary". --- With regard to the caution result - that can be tuned using the GBUdb parameters-- or it can even be turned off. That would leave the remaining result codes 20 and above which are all considered reliable. --- In the best world you would be able to translate any SNF result code to any weight you want but that doesn't seem possible in the ASSP plugin API. If it is then please let me know and I'll look into making that adjustment. That said though-- even when SNF users have the ability to translate SNF results individually, in practice they don't. There doesn't seem to be a need as each nonzero result is a very accurate indicator of spam. The one exception that some systems might find is the caution result and if that proves to be a problem they can turn off that result in the SNF configuration. Hope this helps, Thanks! _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. ############################################################# This message is sent to you because you are subscribed to the mailing list <[email protected]>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
