Re: Spam

At 21:18 2004-02-04 +0100, Dallman Ross wrote:
> 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.
Anyone operating their own mailserver would do well to check out the load 
caused by spamd (yea, I'm not even talking about individual user-invoked SA 
processes).  I think SA is a great thing for people incapable of managing 
their own spam solution and who believe the solution to resource hogs is to 
upgrade to a supercomputer, but IMO, SA is just too much of a pig for some 
people to want to use it.
For a home user managing their own computer, who the hell wants to have to 
manage a separate host just for mail processing?  Hell, for a small 
business, who wants to do that?  More work, another box to set up (and need 
an IP for), back up, monitor, etc.  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.
There's something to be said for knowing precisely how your own spam 
filtering works.  Having "early exit" tests - knowing that some particular 
characteristic is POSITIVELY spam, and therefore needs no further testing, 
certainly makes a procmail solution easier to optimize (and thus faster and 
less of a resource pig) than the SA one.  SA might have early exit tests, 
though I've yet to see an installation where that was the case, and not 
using it myself - though I admin on a host which runs it, and have dealt 
with several others - I can't say positively that this isn't an option.
I don't know whether SA has options for skewing the results of checks based 
on whether the sender is in a greylist -- such as a recognized mailing list 
where you might permit a bit more lattitude WRT content discussions, while 
still choosing to check for spam.  This however, is quite easy to integrate 
into a procmail solution.
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.
However, don't let this be an argument keeping anyone from rushing off and 
using SA if they feel it is right for their particular situation. I just 
know I'm quite happy if I don't get a pager alert at 3am notifying me that 
the CPU load on some host has gone through the roof and stayed there...
---
 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