At 15:22 2002-02-11 -0500, Don Hammond wrote:
| http://ceti.pl/~kravietz/spamrc/, and I am not sure why but it works
My real intent is to point out you probably need to be careful with
spamrc.txt. It looks like the author is using extended regular
expression syntax that's not supported by procmail. Specifically, it
looks like he's using {m,n} quantifiers and the perl-ish \d to denote
numerics. There may be others.
You noticed? I gave it a quick glance some time back, and I noted that
those expressions were used in scoring recipes, where their failure
wouldn't inherently lead to a failure of the recipe overall (though
obviously, that individual rule wouldn't work), thus the author is probably
totally unaware that the syntax is wrong. Though how one can write
something to match a certain spam and not at least try pumping that spam
back into the rule to see it actually match is a weird prospect...
Then, at 15:14 2002-02-11 -0600, Tom Warfield asked:
Do you have any suggestions on something else that would work better
with procmail?
Basically im just trying to stop my end users from getting spammed, so
with that in mind any recommendations?
RBLs have traditionally been very effective - the problem is that all the
useful ones are now pay-for (and pretty steep, as least for small
shops). Most of the free RBLs are very likely to toss a fair chunk of
perfectly valid email.
When filtering OTHER PEOPLE'S mail, it is generally best to err on the side
of caution - filters which get false positives result in lost email - and
enough of that (or just one important one), and you'll lose customers.
Email is sacred. People expect it to be reliable.
A popular alternative to tossing the suspect mail is to have your filters
*ADD* a header which the end-users can elect to use in their email software
(or with procmail, if they're using shell mail) to filter out the spam
based on your rulesets. That way, they can elect to participate or not -
if they feel your spam filters are too broad, they simply don't toss
messages with the identification header (or choose to filter certain
messages before doing so - such as those from certain clients). Users can
still benefit from your spam rules, without themseleves having to maintain
(and update, and revise, etc) any complex rules - all they do is add one
rule to re-file the messages identified as suspect.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail