> > tests were only conducted > > on email that flunks other preliminary tests. Don't know if SpamChk > > works that way or not.
We must make some tests before we can say something about this. For sure, we can test for reg-expr. only if there was already something suspicious in the content. But this will prevent us to find something specially in this messages that until now hasn't triggered enough/any tests. > ... as soon as a > message has enough weight to fail and only running certain > tests after others have failed. (Or if others have not > failed?) Maybe for some sort of high traffic mode? Even if at the moment we've no CPU usage problem on our server I have an idea for this thread. I've asked this on the list some weeks ago but haven't recieved any answer. If we can find a tool/service that gives us an average CPU-usage value and can trigger some action based on this value, than we can prepare two different configuration files for declude junkmail, virus and also for SpamChk. (Something like "if more then 90% CPU usage for the 3 minute-average: switch the filenames of the configuration files") The "high traffic"-version of the config-files can have disabled the second av-engine, and other ressource-intensive tests. Even if this will decrease the detection rate, it will help us to keep up and running the service under a heavy load. Someone know's such a tool or a way how to implement this with the windows performance monitor? Markus > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rob Salmond > Sent: Saturday, May 03, 2003 10:52 PM > To: [EMAIL PROTECTED] > Subject: Re: [Declude.JunkMail] Easy way to add power and flexibility. > > > >This may be overly obvious, but any CPU load could be minimized if > >RegEx > > I would only do that if there were CPU usage problems in to > begin with. In some cases a particular regexp line might be > the only rule keeping a piece of spam out. And if you were > to design your expressions carefully you could likely cut out > a LOT of comparisons from those always growing blacklist files. > > Actually come to think of it, test pruning like you mentioned > could sure cut down a lot of redundancy. I've noticed that > the headers declude adds sometimes contain more than one test > which should have individually pushed that particular message > over the line and into the spam mailbox. You could probably > cut down a lot of CPU overhead by optimizing in both > directions, quitting the spam test process as soon as a > message has enough weight to fail and only running certain > tests after others have failed. (Or if others have not > failed?) Maybe for some sort of high traffic mode? > > Rob Salmond > Ontario Die Company > (519)-576-8950 ext. 132 > > > --- > [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
