Do the positive weight tests (black tests) first in highest to lowest
weight order.
I'll just comment here before this goes too far.
It is very unlikely that we will rearrange the order that the tests are run
it, as many of them must be run at a certain point, and there are several
cases where
TED] On Behalf Of John
>Tolmachoff (Lists)
>Sent: Wednesday, June 04, 2003 2:02 AM
>To: [EMAIL PROTECTED]
>Subject: RE: [Declude.JunkMail] Easy way to add power and flexibility.
>
>
>> Forgive the intrusion (I just troll here, don't actually have JM
>> ), but thi
Charles:
>They need to not be greedy matches or better yet support a very small set
of rules, an overly simplified
>engine could allow for word boundries and whitespace with optional letters
and make word and phrase
>filters much more powerful.
I agree, regular expressions are somewhat more powerf
ob Salmond
Sent: Sunday, May 04, 2003 8:10 AM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] Easy way to add power and flexibility.
Interesting point, I hadn't considered tests that add a negative weight.
(Although the default config only comes with two negatives as far as I
know
an
I guess you would do checks on the negative weights first and then the
positive and at any point a test goes above the threshold you would
stop. Unless by adding all the positive tests together it would still
be below threshold whereas you wouldn't need to do any positive tests
(unlikely though).
Interesting point, I hadn't considered tests that add a negative weight.
(Although the default config only comes with two negatives as far as I know
and I haven't had need to add others). However I think it would be safe to
make some assumptions in the test process that could cut CPU time and still
> Forgive the intrusion (I just troll here, don't actually have JM ),
> but this idea seems flawed. If you quit testing once a certain weight
> has been reached, wouldn't you cut off further testing that might reduce
> that weight? In a system where a score can go up and down depending on
> the t
- Original Message -
From: "Rob Salmond" <[EMAIL PROTECTED]>
> 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
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 a
>This may be overly obvious, but any CPU load could be minimized if RegEx
tests were only conducted
>on email that flunks other preliminary tests. Don't know if SpamChk works
that way or not.
I would only do that if there were CPU usage problems in to begin with. In
some cases a particular regexp
moment it's not clear how much this will influence the CPU
> utilization.
>
> Markus
>
>
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Rob Salmond
> > Sent: Saturday, May 03, 2003 4:09 PM
> > To: [EMAIL
TED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Rob Salmond
> Sent: Saturday, May 03, 2003 4:09 PM
> To: [EMAIL PROTECTED]
> Subject: [Declude.JunkMail] Easy way to add power and flexibility.
>
>
> In an earlier email I mentioned the idea of a scripting
> language for
In an earlier email I mentioned the idea of a scripting language for
building mail filters. It was brought to my attention that this is outside
the scope of a junkmail product which is of course quite true. Howerver
something that would be very useful in a junkmail filter would be a regular
expre
13 matches
Mail list logo
