On Wed, 4 Feb 2004, Chris Barnes wrote:
Bart Schaefer <schaefer(_at_)zanshin(_dot_)com> wrote:
Because SA is big and slow-moving and consequently a target for
spammer evasions, plus difficult or impossible to install in some
environments where procmail is already available (web-hosted accounts,
mostly).
Um, I would SERIOUSLY disagree with your characterization of SA. Several
of the big rule sets are updated weekly - or more. I don't know of any
Linux environments where it doesn't run (if *I* can install it, surely
someone who actually knows Linux can). Seems to work just fine with
both Horde & Squirrelmail.
Big: The big rule sets are just that -- big. And perl is bigger and
slower than procmail.
Slow-moving: The rule sets that are updated regularly are not part of the
spamassassin distribution, they're third-party contributions; they have to
be installed as the administrator unless the allow_user_rules security
hole has been deliberately opened; consequently few spamassassin users
have access to them. They're also not tuned against the same ham/spam
corpora nor against the default rules, so they have to be used with
caution because they violate the spamassassin "gestalt" -- the very reason
that SA releases are infrequent is so that all the rules can be tested for
interactions and scored collectively not individually.
Difficult to install: If I'm not an admin and my web-host doesn't provide
perl (soon to be "perl at least version 5.6.1") and/or I don't have shell
access, there's no way I'm going to be able to use SA. It's more common
to provide procmail and a way to drop in a .procmailrc.
All that said: I use spamassassin, and have installed it both on our mail
server at work and on my linux machine at home. I just have no illusions
about it being the end-all answer to everyone's spam filtering problems.
On Wed, 4 Feb 2004, Jason Crowe appended:
It's very active development wise, but slow moving resources wise.
Procmail recipes are generally a lot faster than using spamassassin. I
used procmail exclusively on our mail servers and never had a load
problem. Now that I am using spamassassin I need to upgrade to a faster
server.
On Wed, 4 Feb 2004, Dallman Ross agreed:
Yup. Besides which, I'd developed a good deal of my procmail
stuff before there *was* a SpamAssassin. And I get fewer false
positives and false negatives.
Here's some timing tests on one hundred spam messages. [...]
Okay, [procmail] took just over a minute-and-a-half, and seems to have
sent the load up a bit briefly on this machine. [...]
Christ. I interrupted [spamc] after *twenty-four minutes*!!! I thought
it must be stuck. But no, we were nearly 90% through: [...]
The load was between 110 and 128 the whole time! A couple of
minutes after I bailed on the job, it is back to 6 or 7 for the time
being. Hmm.
This indicates something seriously wrong with Panix's spamd setup. My
first guess would be that they're not using the "-m" option to limit the
number of forked copies of spamd.
Even so, however, I can't explain how you managed to run the load up over
100 -- with a formail loop, there should still be at most one spamc plus
one forked-off spamd at a time (not considering what other users might be
doing).
I've pumped mailboxes containing several *thousand* messages through
"formail -s spamc" in much less than 24 minutes and without killing our
500MHz PIII linux server.
Let me add some information: Panix has added an entire other host
machine to run these mail processes. There are no users logged in to
that machine! Most of its CPUs are used up running spamd. The load
is often extreme.
This still sounds like something gone wrong, to me.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail