Re[2]: [sniffer] problems!!!!
On Wednesday, February 8, 2006, 10:59:09 AM, Darin wrote: DC I have an idea. These problems seem to stem mostly from changes DC in the methods of handling rulebase updates. snip/ DC Would it be feasible to announce in advance when such changes DC are to be implemented? With advance notice of a date and time DC for the switch we could choose to freeze our rulebases just before DC that for a day to make sure the kinks were worked out before DC updating. A few spam messages that slip through are better than DC a slough of false positives that require review and are delayed in reaching the customer. That's a good idea, and we do, in fact, follow that procedure. Whenever we make any large scale changes we always announce them here on this list,... we usually also put them on our web site. There is an error in your comment however... the previous event (with the rule-bots) was completely unforeseeable. There was no way to announce that known good software would suddenly fail so spectacularly when no changes within our control were made. Thankfully, that kind of event is extremely unlikely also. It is unfortunate that these two events would happen so closely together. _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
Re: Re[2]: [sniffer] problems!!!!
There was no error in my comment. I completely understand that some issues will not be foreseeable... I did say mostly, not entirely. The switch to the automated bots caused a rash of false positives in our system. I'm not pointing fingers, but instead want to make sure I have the ability to decide what risks to take on my end. While mistakes are always possible... we are human after all... the more controls we have available to minimize possible impact, the better. What I would be looking for is an announcement of a specific date/time for a cutover so we could freeze just before that, and unfreeze once it was clear that no glut of false positives would result. Darin. - Original Message - From: Pete McNeil [EMAIL PROTECTED] To: Darin Cox sniffer@SortMonster.com Sent: Wednesday, February 08, 2006 11:13 AM Subject: Re[2]: [sniffer] problems On Wednesday, February 8, 2006, 10:59:09 AM, Darin wrote: DC I have an idea. These problems seem to stem mostly from changes DC in the methods of handling rulebase updates. snip/ DC Would it be feasible to announce in advance when such changes DC are to be implemented? With advance notice of a date and time DC for the switch we could choose to freeze our rulebases just before DC that for a day to make sure the kinks were worked out before DC updating. A few spam messages that slip through are better than DC a slough of false positives that require review and are delayed in reaching the customer. That's a good idea, and we do, in fact, follow that procedure. Whenever we make any large scale changes we always announce them here on this list,... we usually also put them on our web site. There is an error in your comment however... the previous event (with the rule-bots) was completely unforeseeable. There was no way to announce that known good software would suddenly fail so spectacularly when no changes within our control were made. Thankfully, that kind of event is extremely unlikely also. It is unfortunate that these two events would happen so closely together. _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[2]: [sniffer] problems!!!!
What is the correct Sniffer string in Declude Global.cfg file. SNIFFER external nonzero d:\imail\declude\sniffer\sniffer.exe code12 0 of SNIFFER external nonzero d:\imail\declude\sniffer\sniffer.exe code10 0 Thanks Filippo
Re[2]: [sniffer] problems!!!!
On Wednesday, February 8, 2006, 11:06:07 AM, Markus wrote: MG If a experimental rule showed to be reliable they move them in MG the appropriate category (rich, fraud,...) MG MG MG MG I'm not sure about this but I think it's so and so it shouldn't MG be necessary to do something like manualy block updates. This is not how it works. Experimental rule groups contain abstract rules that may not classify a particular type of message. Indeed, even rules that are coded to more specific groups will likely match messages that are outside of those categories because the blackhats frequently re-use domains and other features in many different campaigns. For example, the current chatty drugs, chatty loans, and chatty watches campaigns all tend to share the same domains in their links. Along the lines of delaying implementation of new rules, we can configure rulebases and rule groups within them to only accept rules with a specific minimum age in days. We might have to charge for this kind of custom modification, and it would by it's nature increase spam leakage. _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
