On Wed, Feb 04, 2004 at 03:43:58PM -0800, Bart Schaefer wrote:
A mail processor shouldn't consume more resources (cpu AND memory) than
_ALL_ of the other processes on a multiuser host providing web, pop,
ftp, and other services. Yet, SA manages to do this, and some people
don't see that as wrong.
Of course it's wrong, but it's also not a true characteristic of SA when
installed and used properly (which includes not feeding it enormous
messages -- spamc won't let you do that, but plain spamassassin will).
The only time I had a problem with SA was with an early release of the SA rpm
from Red Hat on RH 8.0 (don't start on Red Hat, ok?) It was something to do
with the environment and utf8 or something. I don't remember the details, but
it sent system load over 100 several times a day. By the time I started having
the problem, the bug was noticed and fixed. I installed an updated RPM and
have never had problems with it since.
Besides, if I've got to run procmail to take action on the SA-inserted
headers, I may as well just use procmail to do the checks. Plus, if
you've got to get intimate with SA to tweak it just right, you're
already investing more time than a "canned" solution should require.
It's not *necessary* to tweak SA. As usual it's the 80/20 problem -- SA
will kill 80% or more of the spam right out of the box. This causes
people to get bent out of shape about what still gets through, so they
expend a disproportionate amount of effort to try nail that other 20%.
Not to mention ANY "canned" solution is going to require a bit of tweaking.
Whether you do that in the canned solution, or add more procmail rules to get
what the canned solution missed, you're still tweaking.
--
Andrew Edelstein - http://andrew.pure-chaos.com/resume.txt
Please do not reply directly to me, or Cc: me on a reply to a list message.
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