On Thu, 18 Jul 2002, Jeffrey Wheat wrote:
> Spam Assassin has cost me a large number of headaches. We have
> tried to use it a number of times which only resulted in customers
> getting extremely irate about how we are altering their emails. It
> causes a busy server to drive cpu load up through the roof, resulting
> in poor performance and lost email when the server begins to reject mail
> due to system loads.
You acknowledged yourself that doing a good job of detecting spam is a
hard thing. I think it therefore follows that it will require a lot of
CPU to acheive it.
I have some spam-blocking systems in place. I (and my housemate) spent
time on them mostly for the fun of it, but they do a pretty good job of
it.
1. I keep my addressbook in LDAP (actually I use Pine, so I have scripts
to convert from Pine to LDAP daily). exim looks sender addresses up with
LDAP - if it finds a match, a header is added indicating that the address
is whitelisted. If it is it is not passed to:
2. A filter, written in Perl, which my housemate wrote. It turns out that
the stategy is kinda similar to SA - basically emails accumulate points
according to RegEx matches of the text and various other features (having
more than a certain number of addressees in the same domain, having
matching To: and From: headers etc). All these features are configuarable
on a per-user basis. Further headers are added to indicate the status of
these checks.
3. Based on the headers, the emails can be filtered away.
Of course, this is all highly inefficient. It does two LDAP lookups per
email (couldn't find any other way of doing it), and starts a Perl
interpreter for any email that the LDAP doesn't find.
John
--
It would have been jolly to talk like this, and really, it wasn't
much good having anything exciting like floods, if you couldn't share
them with anybody.
