Re: some other approach
> I rather like the other approach. Using
> blacklists to waste spammer's time on a
> phony mail transport agent and drive the
> cost of spam skyhigh. I think the
> OpenBSD community did something in this
> direction. This combined with some kind
> of bayesian filtering that kills the
> spam *before* it reaches the MTA (or
> built into the MTA via some kind of hook
> that calls an external program). Nobody
> likes to queue spam. My system is not a
> spammer trash can.
Here's a couple of commands that might help you:
(echo -n '|'; `which procmail`) > ~/.forward
(echo ':0';echo '* ^X-Spam-Status: Yes';echo '/dev/null';echo) >> ~/.procmailrc
Then, assuming your mail's going through spamassassin, the message is instantly deleted. You don't waste any space on it.
Seriously, a lot of spam makes it past the checks that an MTA can make on the conenction info (RBLs, validity checks), so you need *something* to check the body and client-supplied headers for bad stuff. That has to be done after the message is received because of the way SMTP works. If you don't want to waste the space, you can use a mazimum message size limit in combination with a spam checker (I use SpamAssassin) and something that throws away messages marked as spam.
I've been using SA for a few months now - it tags around 100 messages daily (between the few accounts that I use). I've had 0 false positives. I've got some basic system-wide rules set up, and per-user whitelists stored in a database, managed with a simple PHP form that even our dullest users can handle. It's received only praise for letting users filter out their spam. My only advice is to look over the config settings, and change some of the defaults - the default setup is not ideal for the average user, IMHO.