Thank you Pete Harry Vanderzand inTown Internet & Computer Services 519-741-1222
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil > Sent: Wednesday, February 08, 2006 11:09 AM > To: Markus Gufler > Subject: Re[2]: [sniffer] problems!!!! > > On Wednesday, February 8, 2006, 10:48:10 AM, Markus wrote: > > MG> > MG> > MG> Harry, > MG> > MG> > MG> > MG> (please don't post your entire license code to a public list.) > > Yes, Harry, please don't. I'll be resetting your > Authorization code and sending it to you off list. > > Other than changing your authentication code you should not > need to change anything else in your configuration, that is, > unless you are having some other problem than we have assumed. > > MG> regarding the reliability of sniffer we should know that errors > MG> sometimes can happen, even at sniffer-side after they've > worked for > MG> years now very relaible. I don't expect that such errors > will happen now more often. > > Thanks for that. It is true that we've had a few bad days > here lately, but these things are unlikely to recur. For > example, the robot problem is a one-off event. It is > inexplicable how software that ran reliably for years > suddenly "loses it's mind" like that... the event was unforeseeable. > > Bad rules will happen from time to time, but less and less frequently. > To begin with, our staff has only recently been expanded, so > as time goes on they will become much more adept, less likely > to create errors, and more likely to catch them if they happen. > > Also, with each new event we learn new things about the > process and where it can fail, and then we implement changes > to prevent those failures. > > There will always be a non-zero probability of error... the > blackhats are continually changing their tactics, evolving > new techniques, and even mounting new kinds of attacks. In > order for us to respond to that environment we must also > continue to evolve with increasing speed - that means > entering unknown territory on a continual basis, and, with as > little damage as possible, it means we must make some > mistakes from time to time. > > MG> What you can do is trying to configure your declude > spamfilter in > MG> order to hold only if multiple or at least more then one test > MG> failed. For doing this the first step is to set the > maximum weight > MG> of each test (at least slightly) below your hold weight. > > This is always a good idea. No matter how good any single > component may be, you should a avoid relying on that single > component in order to mitigate risk and reduce errors - > nothing is perfect even if it can seem that way for a time. > > <snip/> > > MG> Thanks to Andrew and Goran for their info's and scripts. > Saved a lot of time here. > > I second that! > > MG> Pete: Any info if and if yes when you can adapt MDLP for the > MG> declude v3 logfile? I realy miss this data. Once > accustomized to the > MG> hourly results of MDLP e sometimes feel now like a blind chicken > MG> :-) > > I'm hopeful I can spend some time on that soon. I also miss the data. > > Thanks! > > _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
