[sniffer] Re: ASSP Threshold
Hello Andy, Friday, October 17, 2008, 1:04:14 PM, you wrote: > Hi Pete, > Then let me approach it from a different angle: Is there a way in the > Sniffer config files to "silence" certain groups? Yes. But not locally. We can customize a rulebase to block rules or rule groups as needed. So far that is a very rare occurrence. > This way, if someone doesn't want to outright block email based on certain > groups, they could just exclude those groups from triggering at all. Understood. _M # This message is sent to you because you are subscribed to the mailing list . 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]>
[sniffer] Re: ASSP Threshold
>The vast majority of folks currently treat all nonzero SNF results the >same. I confirm that IMGate running SNFClient through Aaron Millis' spamassassin plugin (which we've modified) on FreeBSD works like this and work well in spam-or-ham binary mode, rather than multi-valued returns from SNFClient. We "trust" SNF's hits and spamassassin score them as 5.0 when our spam kill level is 4.5. SNF is great for catching the crumbs that the rest of sa's filtering would have passed. Len __ IMGate OpenSource Mail Firewall www.IMGate.net # This message is sent to you because you are subscribed to the mailing list . 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]>
[sniffer] Re: ASSP Threshold
Hi Pete, Then let me approach it from a different angle: Is there a way in the Sniffer config files to "silence" certain groups? This way, if someone doesn't want to outright block email based on certain groups, they could just exclude those groups from triggering at all. Best Regards, Andy -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Friday, October 17, 2008 12:41 PM To: Message Sniffer Community Subject: [sniffer] Re: ASSP Threshold Hello Andy, Thursday, October 9, 2008, 3:28:44 PM, you wrote: > Hi: >>> The design of the plugin at the moment is a binary decision-- either > the message is spam, or not. << > I understand - but currently the plugin has a config option that performs a "Resultcode >>= Threshold" test. I think it would be more appropriate to have > a "Resultcode in (n, n, n...) " test. It doesn't affect the logic > and doesn't add more complexity Actually, this would add some complexity. The vast majority of folks currently treat all nonzero SNF results the same. ASSP 2.0 is new and the API doesn't yet provide the flexibility to multiplex results from plugins -- Perhaps we missed it or perhaps that will change. At this time we will keep things as they are. Once a few people are using the plugin and we have some feedback then we will be able to consider upgrades. Thanks! _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list . 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]> # This message is sent to you because you are subscribed to the mailing list . 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]>
[sniffer] Re: ASSP Threshold
Hello Andy, Thursday, October 9, 2008, 3:28:44 PM, you wrote: > Hi: >>> The design of the plugin at the moment is a binary decision-- either > the message is spam, or not. << > I understand - but currently the plugin has a config option that performs a "Resultcode >>= Threshold" test. I think it would be more appropriate to have > a "Resultcode in (n, n, n...) " test. It doesn't affect the logic > and doesn't add more complexity Actually, this would add some complexity. The vast majority of folks currently treat all nonzero SNF results the same. ASSP 2.0 is new and the API doesn't yet provide the flexibility to multiplex results from plugins -- Perhaps we missed it or perhaps that will change. At this time we will keep things as they are. Once a few people are using the plugin and we have some feedback then we will be able to consider upgrades. Thanks! _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list . 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]>
[sniffer] Re: ASSP Threshold
Hi: >> The design of the plugin at the moment is a binary decision-- either the message is spam, or not. << I understand - but currently the plugin has a config option that performs a "Resultcode >= Threshold" test. I think it would be more appropriate to have a "Resultcode in (n, n, n...) " test. It doesn't affect the logic and doesn't add more complexity - but would allow more control over what is rejected as SPAM on the same level as ORF (where you can configure which Resultcodes to block outright), albeit not quite as much as Declude. I would want to block some result codes outright during the connection (based on a resultcode list as in ORF) and allow other resultcodes (in which I have lesser confidence) to go through and be subject to other tests. Best Regards, Andy -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Thursday, October 09, 2008 3:01 PM To: Message Sniffer Community Subject: [sniffer] Re: ASSP Threshold 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. > 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 . 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]> # This message is sent to you because you are subscribed to the mailing list . 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]>
[sniffer] Re: ASSP Threshold
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. > 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 . 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]>
