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 powerful than would be
required for the type of checks I'd like to see made, but the other
stipulation I mentioned was that it was an Easy way to add power and
flexibility. Scott and I discussed the idea of a simple scripting facility
but the added complexity of a custom script filter was of course not
worthwhile. Since there are already many regexp libraries freely available
for developers to use I figured this would be the quickest way to get the
results I want from the software I use.
Jools:
>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
Actually I was thinking it would be more effecient to do the negative checks
only after positive checks have run and found the message to be beyond the
threshold. This way you don't run checks on messages which might end up not
needing a negative value to make it through.
Good idea about the DNS test as well. It might be worthwhile to load a code
profiler against a running filter and see where the longest wait times are.
It would be trivial then to reorder the tests from quickest to longest.
Although its probably already been done.
I still think that stopping the positive test process after a message meets
its threshold is the easiest way to eliminate CPU usage however, unless I've
missed some other possibility? The process would be something like:
incoming message-->run positive tests (in order of fastest to slowest)----v
|
|
msg hits threshold
message below threshold----------------->DELIVER
|
v--run negative tests---v
| |
msg still above threshold msg below
threshold-------------->DELIVER
|
take spam action(BOUNCE,ROUTETO, etc)
I hope that ascii art doesn't get too mangled in transit ....
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.
