[conspire] anti spam

[Rick Moen]

Quoting Roger Chrisman (roger at rogerchrisman.com):

> Hi,
> 
> For years now I have been using Gmail because
> 
> 1. I am not much good at system administration and I enjoy having my
> email stuff survive when I do stuff like start over from scratch with
> a fresh Linux install.
> 
> 2. Bogofilter was no longer working well to filter spam and Gmail does
> it really well.
> 
> What level of success are others having who are still handling ones
> own email spam filtering?
> 
> What anti spam tools are you using to do it?

IMO, if you aren't running your own MTA, and aren't benefiting from someone
else (e.g., a technically proficient friend) doing a good job running an
MTA on a system you use, _then you are screwed_ and cannot do effective
spam-blocking.  For example, if you are one of the innumerable poor sods
stuck using an ISP-run SMTP host (MTA), then you are stuck using
poor-to-mediocre spam-blocking and have nothing but
poor/ineffective/dissatisfying otions to improve that situation.

I mention that because, 99% of the time when someone asks me the
question you're asking, he/she forgot to say 'I'm a {POP3|IMAP|webmail}
user of someone else's SMTP services, and am not willing to change that'.

Also, 99% of the time, when people tell me 'Bogofilter doesn't work
well', or 'SpamAssassin doesn't work well', it turns out he/she forgot
to say 'I'm a {POP3|IMAP|webmail} user of someone else's SMTP services.'

(Bogofilter and SpamAssasin actually work quite well -- if deployed at
the level of the MTA during SMTP receipt.)

Effective spam-blocking can be done ONLY at the MTA initial-acceptance
level.  If you're using someone else's MTA, then you will get whatever
spam-blocking the MTA operator has implemented.  When that MTA is an
ISP -- or GMail -- then in the overwhelming majority of cases, the
spam-blocking will be fairly poor.  Why?  Because the service provider
will get far more customer complaints from false-positive MTA rejection
of non-spam than from false-negative MTA acceptance of spam, so the
service provider will err on the side of over-accepting mail, every
single time.  People who run independent MTAs like mine are free to do
orders-of-magnitude better spam-rejection, because we have very few
users to satisfy, and don't have to deal with support tickets from
Grandpa Smith to the effect that 'How do you _know_ all the Irish
Sweepstakes mail to me wasn't legitimate?'

To answer your question:  Very good success, really -- even though my
last system rebuild was extremely rushed by having to be done
unexpectedly after my server was destroyed by a lightning storm in 2009 
just before I was scheduled to go into the hospital for major abdominal
surgery, and consequently I never did implement several improvements
planned for it.

Software in place:

Debian's exim4-daemon-heavy package.
sa-exim
SpamAssassin
...and a small amount of local tweaking, mostly done in a huge hurry,
the night I had to replace my fried server.

Improvements that should have been included in the April 2009 system
rebuild, but were omitted for lack of time:

J.P. Boggis's EximConfig bundle of Exim4 ACLs and other Exim4 improvements.
spfd and plumbing for checking of its return values by SpamAssassin's spamd.

Without those additional improvements, my results are significantly
better than GMail's, and the only administrative effort required is to
run commands a few times a year to feed mboxes of known-spam and of
known-non-spam to SpamAssassin's Bayesian classifier, to train it.

_With_ those improvements, spam rejection would be an order of magnitude
better still (which I know to be true because it was so prior to the
server destruction in 2009).

When I put up Linux machines (and BSD machines before that) on fixed IP
addresses on the open Internet, I wasn't any good at system
administration, either.  Guess what?  It turns out that, if you run
Linux, you _are_ a system administrator.  And you learn on the job, 
by continuing to run Linux and making it do things.