[sniffer] SNF Now directly supported in IMGate!
Hello Sniffer Folks, Message Sniffer is now directly supported in Len Conrad's IMGate. IMGate + SNF allows you to move your spam filtering out in front of your mail server improving scalability, stability, and performance. Here are some links: http://www.imgate.net/?page_id=101 http://www.imgate.net/?page_id=111 Best, _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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: SNF Now directly supported in IMGate!
Hi, Hopefully, you'll be able to convince Alligate and ORF next to use your new DLL API to scan the content during the SMTP connection without needing the command line environment... Best Regards, Andy -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Thursday, October 09, 2008 12:12 PM To: Message Sniffer Community Subject: [sniffer] SNF Now directly supported in IMGate! Hello Sniffer Folks, Message Sniffer is now directly supported in Len Conrad's IMGate. IMGate + SNF allows you to move your spam filtering out in front of your mail server improving scalability, stability, and performance. Here are some links: http://www.imgate.net/?page_id=101 http://www.imgate.net/?page_id=111 Best, _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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 sniffer@sortmonster.com. 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: SNF Now directly supported in IMGate!
Hello Andy, Thursday, October 9, 2008, 12:27:53 PM, you wrote: Hi, Hopefully, you'll be able to convince Alligate and ORF next to use your new DLL API to scan the content during the SMTP connection without needing the command line environment... We have approached Alligate and ORF about this. There are many ways to integrate w/ SNF. Everyone has their own needs and priorities. We will continue to support new and better ways to integrate SNF with these and other platforms as the opportunities arise. It always helps to have customers making the suggestion though ;-) _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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] ASSP Threshold
Hi Pete, SNF code spam threshold (ASSP_SNF_Threshold) The SNF result code threshold that is considered spam. SNF result codes at this level or above will be considered spam for the purposes of ASSP scoring. The default value of 20 is good in most cases. Are the result codes these: http://kb.armresearch.com/index.php?title=Message_Sniffer.TechnicalDetails.R esultCodes 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.). 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... Best Regards, Andy # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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. 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 sniffer@sortmonster.com. 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. 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 sniffer@sortmonster.com. 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 sniffer@sortmonster.com. 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]
