Re[2]: [sniffer] Running sniffer as a service
On Friday, February 24, 2006, 7:13:47 AM, Jeff wrote: JP Do I need to modify anything in my Declude configuration file where it calls JP the SNIFFER test in order for this to function ?? No. You set up a persistent instance outside of Declude and the other SNF instances adapt automatically. _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
[sniffer] False positive processing
Pete, Thanks for the quicker turnaround in the last few days for false positive processing. We're seeing abouthalf day now. Much appreciated! Darin.
RE: Re[4]: [sniffer] When to go persistent
Hi, I just got my service up and running using Matt's post http://www.mail-archive.com/sniffer@sortmonster.com/msg00169.html It was simple especially since I already the resource kit installed. Now I know that this I supposed to work to get the persistent instance to load the new rulebase after a download. REM Load new rulebase file. %LicenseID%.exe reload But is there any way to query the service and ask it to tell you when was the last time the rulebase was loaded? Or what version of the rulebase it is using? When running in peer mode this question does not arise since the instances read the file off disk so there is no problem. With the persistent instance this is not the case and I would like to know that it really is using the newest rulebase. Goran Jovanovic Omega Network Solutions -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Thursday, February 23, 2006 3:11 PM To: Rick Robeson Subject: Re[4]: [sniffer] When to go persistent On Thursday, February 23, 2006, 1:22:53 PM, Rick wrote: RR I thought you had to run this as a service? RR Rick Robeson RR getlocalnews.com RR [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Strictly speaking you do not have to run it as a service, but it is more convenient to do so. If you run it from the command line then you would need to remain logged in. Running the persistent instance from the command line is convenient for testing, but it is much better to run it as a service in a production environment - that way it starts and stops with the other services as expected, doesn't require any account to be logged in, etc... _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: Re[4]: [sniffer] When to go persistent
Goran, When you issue a reload you can tell that the new rulebase is being used because the *.svr file's date and time will change to the current time. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Goran Jovanovic Sent: Friday, February 24, 2006 7:31 AM To: sniffer@SortMonster.com Subject: RE: Re[4]: [sniffer] When to go persistent Hi, I just got my service up and running using Matt's post http://www.mail-archive.com/sniffer@sortmonster.com/msg00169.html It was simple especially since I already the resource kit installed. Now I know that this I supposed to work to get the persistent instance to load the new rulebase after a download. REM Load new rulebase file. %LicenseID%.exe reload But is there any way to query the service and ask it to tell you when was the last time the rulebase was loaded? Or what version of the rulebase it is using? When running in peer mode this question does not arise since the instances read the file off disk so there is no problem. With the persistent instance this is not the case and I would like to know that it really is using the newest rulebase. Goran Jovanovic Omega Network Solutions -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Thursday, February 23, 2006 3:11 PM To: Rick Robeson Subject: Re[4]: [sniffer] When to go persistent On Thursday, February 23, 2006, 1:22:53 PM, Rick wrote: RR I thought you had to run this as a service? RR Rick Robeson RR getlocalnews.com RR [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Strictly speaking you do not have to run it as a service, but it is more convenient to do so. If you run it from the command line then you would need to remain logged in. Running the persistent instance from the command line is convenient for testing, but it is much better to run it as a service in a production environment - that way it starts and stops with the other services as expected, doesn't require any account to be logged in, etc... _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re[6]: [sniffer] When to go persistent
On Friday, February 24, 2006, 10:31:25 AM, Goran wrote: GJ Hi, GJ I just got my service up and running using Matt's post GJ http://www.mail-archive.com/sniffer@sortmonster.com/msg00169.html GJ It was simple especially since I already the resource kit installed. GJ Now I know that this I supposed to work to get the persistent instance GJ to load the new rulebase after a download. GJ REM Load new rulebase file. GJ %LicenseID%.exe reload GJ But is there any way to query the service and ask it to tell you when GJ was the last time the rulebase was loaded? Or what version of the GJ rulebase it is using? By default, the persistent instance will reload the rulebase about once every 10 minutes. The reload command creates a semaphore file in the workspace and waits for it to disappear. When the persistent instance has complied it will delete the file. Therefore, the command licenseid.exe reload will generally not return until the rulebase has been reloaded. In some cases, due to a timing function bug, the persistent instance may not respond to the reload or other semaphores... however, it does still reload itself every 10 minutes or so. A sure way of reloading the rulebase if you need to force it and you suspect something isn't quite right is to restart the persistent instance. GJ When running in peer mode this question does not GJ arise since the instances read the file off disk so there is no problem. GJ With the persistent instance this is not the case and I would like to GJ know that it really is using the newest rulebase. Just to clarify a bit... in peer-server mode, a server-peer will load the rulebase, process some number of messages including it's own, and then return. So, reloads are frequent, but not guaranteed. Client-peers do not load the rulebase. The persistent instance processes many more messages than a server-peer and then reloads after it drops. Otherwise it is very much the same as an ordinary peer instance. As a rule, unless something is broken then you can be sure the new rulebase is running within about 10 minutes (by default) of when it appears in the workspace. Hope this helps, _M PS: I'm working on adding some of the version 3 features to version 2 for testing and tuning on our way to a full version 3 engine. Soon I will be coming out with incremental version 2 releases on our way to 3. I will be making instrumentation features a priority since they will be helpful while tuning and (hopefully not) debugging the new prototoypes. This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] IP Blacklist rules
Hi, Thanks. I will treat result code 63 with a combo filter so that any parallel hit with a regular RBL won't end up counting twice. That should take care of it. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Friday, February 24, 2006 03:38 PM To: Andy Schmidt Subject: Re: [sniffer] IP Blacklist rules On Friday, February 24, 2006, 2:56:02 PM, Andy wrote: AS Hi, AS I'm realizing that some Sniffer rules amount to nothing more than IP AS blacklists. AS received:~+[nnn\.nnn\.nnn\.nnn] AS AS Are all sender IP rules properly grouped so that I can identify AS and ignore them by return code. I already use IP blacklists (and AS other means) to cross check Sniffer and add to my confidence AS value before a mail is finally blocked. AS I can't afford Sniffer to effectively double up those sender-IP tests. AS Ideally, Sniffer should perform content checking. Please review the result code explanations here: http://www.sortmonster.com/MessageSniffer/Help/ResultCodesHelp.html IP rules are coded to symbol 63. The voting system on each SNF node sees rules with lower symbol values as more fit, so the only time you will see a result code of 63 is when no other rule matches that message. You may want to reconsider ignoring this result code - there is added value. When an IP rule is in the SNF rulebase, it indicates that: * The rule is from a message that reached our spamtraps. * Additional algorithms were used to classify the IP as a spam source. * The source has been consistently and recently active and detected at our user's system. Inactive IP rules are forgotten after a short period. * There have been no false positives reported against the rule. We remove IP rules on the first FP case and place the rule in a problematic rule group so that it cannot be reinstated without a strict review. * No other rules in our system are currently identifying the associated message content. Though we do focus on content, it is clear that in some cases an IP is the most efficient indicator. Since most other blacklisting services focus on a broad spectrum of IPs, there is bound to be overlap between them and also with SNF IP rules. However the fact that the IP shows up in our system does carry some unique information about that IP (see above). We explicitly do not aggregate IP rules from other lists. We recognize that other IP black lists are used in spam filters along with SNF and we encourage that as well as the use of other tests. (Even though SNF encapsulates diversity in it's algorithms and continues to expand this diversity, the best filtering systems will always use as many useful mechanisms as possible.) Additionally, as we move forward, IP rules in the SNF ruelbase will be gathered by unique, sophisticated mechanisms such as wavefront detection and cross-feature source correlation, etc. As a result, IP rules found in the SNF rulebase will increasingly represent some unique characteristics not found in other IP lists. Hope this helps, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
