[exim] Spam Filtering, A Success Story

Góra strony
Delete this message
Reply to this message
Autor: Steve Dobson
Data:  
Dla: Exim Users
Temat: [exim] Spam Filtering, A Success Story
Hi everyone

I hope this is of interest to some as it is a bit of a success story of
mine using Exim, SpamAssassin and greylisting to defeat the spammers.
As both the client and I are happy with the result I thought I would
pass it on.

Steve
                * * *


Spam has always been a problem, but for me (until about a year ago) not
a particular burden. In the end it is an ongoing arms race between the
spammers and the e-mail admins, so I am always wary of new techniques to
block spam in case they are quickly defeated.

I had placed greylisting in that category. The idea of temporally
rejecting an incoming email is easy enough to understand. Well written
e-mail transfer software will just hold the message and try again later
at which point it is accepted; spam-bots, that implement there own
e-mail transfer software, just give up. But I saw re-trying as being so
easy to implement that I didn't think greylisting would work for long.

I was wrong - I am sometimes.

I turned greylisting on on my own server about a month ago with no great
improvement. SpamAssassin has been running on that server for quite a
while and doing a good job. I just don't get that much spam. So I
wasn't quite ready to start waving the greylisting flag.

But a couple of months back I configured a front-end e-mail server for a
client, and since then we have been progressively tuning the system.
It's just a filter and forwarding server. It runs SpamAssassin on all
inbound e-mails and then forwards them on to a Windows Small Business
Server (SBS) if they don't score highly enough. There is also anti-spam
software (GFI) running on the SBS to further check the incoming emails.

The email front-end server is a Debian GNU/Linux system running Exim
4.63 and SpamAssassin 3.1.7. I have configured rejection of very high
scoring spams in the Exim body ACL (thanks to so help on this list), but
this only accounts for a small number of spams, ~100 per day. Bad
destination addresses account for much, much more, some 1000-1500
spams/day and known spam IP addresses (thanks to SORBS) about 500-1000.

This left about 500-700 e-mails/day that got though, and of that about
150 were being sanitised by their SpamAssassin score for human checking.
Sanitised emails are dropped into an IMAP accessible account with
sub-directories for spam and ham training by the companies employees.

GFI (the anit-spam software on SBS) was doing a good job to, so we set
up a honeypot account to which GFI could forward it's spams for further
automatic training of SpamAssassin (and it was depositing around 250
spams/day). This account was also IMAP accessible to make it easy for
the staff to check things where going where they should.

Now all this filtering was taking care of the lions share of spams, but
there was still a burdensome 200-300 email/day that got though to a user
account. So yesterday I turned on greylisting on this front-end server
too.

What a difference! Yesterday's 600+ e-mails that were passed on to SBS
dropped to <200. Sanitised emails dropped by about 50%. But most
impressively GFI didn't send a single spam into the honeypot account.
The front-end server was doing all the spam filtering work.

Now I'm not claiming that you can completely remove the burden of spam.
I think it is also advisable to use a number of different technologies
to back each other up. But what I now say is that a well trained
SpamAssassin and greylisting can reduce it to a very acceptable level.