Internet, Email & Telephones > Spam Management

From Spam to Ham - The Story Continues

By Lasa Information Systems Team

This article follows on from the Knowledgebase article From Spam to Ham which examined the research and decision making process behind Lasa's wish to keep the never-ending stream of spam email from its mailboxes. As recounted in this article, Lasa had decided to use the open source SpamAssassin (http://spamassassin.apache.org/) solution - Ian Runeckles, Lasa's Circuit Rider, along with John Olufawo, Lasa's Network Administrator, took up the challenge. Ian tells the story...

The learning curve

Having purchased SUSE LINUX it seemed appropriate to get a little familiar with how it should be installed, what the various components are and how to administrate it. I went on SUSE LINUX 3-day course at Interquad in London which was a whirlwind introduction to a whole new computing world. Although I knew a little DOS from years ago, I'd not used UNIX commands before and everything was taught on the command line, the rationale being that if the Graphical User Interface (GUI) offered by the Gnome or KDE wasn't available then the server could still be administrated.

And anyway, serious Linux geeks never use the GUI…

Taking the plunge

Back in the office, we sat down and worked out how the spam solution would work. Mail would come in from the outside world via the router, through the firewall, be passed on to the Exim mail transfer agent running on the Linux server. Exim would then pass it to SpamAssassin where the mail would be scored against the various rulesets, be tagged as spam or cleared as ham, passed back to Exim which would hand over the mail to Exchange Server running on our Windows server.

From here it would end up in the user's mailbox. Simple.

Or so we thought.

We installed SUSE LINUX 9.1 Professional on our upgraded PC and configured it to appear on our network. At this point we diverted from our spam task and installed and configured DC Scripts which is running the Lasa internal discussion forum. This gave us more experience with using the server and we could see how stable it was going to be (in the eight months that the server has been running it's only been rebooted once). The next step was to install SpamAssassin and Exim. This was easily done as both are included in the suite of applications supplied on the Suse disks. The YaST tool was used for installation and it cleverly checked any software dependencies to make sure that we were running everything necessary to run our chosen applications.

We also installed WebMin which is a very friendly looking way of remotely administrating the server (and saves me walking four metres!).

(Con)figuring it out

After much head scratching, purchasing (but not understanding) Philip Hazel's Exim "bible", reading a nice how-to Exim practical guide that we found on the web  and, finally, getting straightforward help and advice from Ryan Cartwright at Contact A Family, we configured Exim.

Within the Exim configuration file we added a script so that (theoretically) when mail arrives it's sent to SpamAssassin for examination, appropriate action is taken, it's passed back to Exim and thence onwards to the Exchange server and individual mailboxes.

Going live

We'd planned to try to run the mail service in a test situation so that we wouldn't disrupt the mail coming in to the organisation. In the end we decided to go for it - as it was Christmas holiday time, there was little important mail coming in. So we changed settings on the Watchguard firewall to point incoming mail to the Linux box rather than the Exchange server.

Firing up Eximon, a graphical tool for examining the flow of mail through the server we waited impatiently for something to happen. Nothing - mail came in and got stuck and eventually just timed out. Emails flew back and forth to the long-suffering Ryan and he put his finger on the source of our problems - after a couple of changes to the Exim configuration, bingo, we were up and running on 5th January 2005!

At this point we informed all our users that we had SpamAssassin place and they were likely to get mail which had been tagged *****SPAM***** and wrapped in an email which explained why it had done so. We knew that we were likely to get some false positives - mail which wasn't spam - so we asked users to send them back to us so we could take appropriate action such as adding the email address or domain to a whitelist (SpamAssassin subtracts 100 points from anything on the whitelist so it's very unlikely that it will end up falsely tagged). We also knew that it would take a while to educate SpamAssassin (it can be set up to learn in a Bayesian manner about the mail that it's passing through so that it can adjust accordingly) so we asked for anything that wasn't being tagged but which was spam to be sent back to us so we could work on that.

Fine tuning SpamAssassin

So it was working. Well, sort of.

Although SpamAssassin was now examining the mail it was missing a lot of spam by not scoring it highly enough (the previous Knowledgebase article From Spam to Ham describes how Spam Assassin works).

Spam Assassin has a number of rulesets built in but they advise that you don't interfere with these or change the scoring - the rulesets are updated occasionally and if you make a change then that will be lost if it's updated. There are two main ways in which to change the scoring:

• Add your own ruleset file where you can write the rules - Ryan had sent over his rules and we used these and added to them. For example, we were seeing a lot of spam advertising drugs - we added a rule to score the word "viagra" at 7 points which immediately took it over the 5 point level at which SpamAssassin deems the mail to be spam.
  
• Use rulesets which other people have written. The site Rules Emporium has a list of a number of rules dealing with specific types of spam (such as adult material, fraud, financial spam, and more complex examinations of tricks of the spammers trade). We downloaded and installed a number of these

Almost there...

After SpamAssassin had been running for about 5 months we were fairly certain that it wasn't misidentifying mail so we decided to re-route any mail that scored over a certain amount to be deleted. Again Ryan helped us out with how to do this by setting up a system mail filter in Exim - any tagged mail which scored over 20 points was written into a holding file called suspect_spam.

We then set up a task using a Cron command (a UNIX command to run a task on a regular basis) so that the file was cleared out every night. Using WebMin we were able to keep an eye on the file's contents to check if genuine mail was being written to it. To date, as far as we know, it has only "eaten" one genuine message which unfortunately had references to viagra.

After a few days monitoring the spam mail that was still coming through we decided we could lower the threshold - it now effectively deletes any spam that scores over 8 points which leaves a 3 point margin of error. Users have noticed a sharp decline in the amount of spam getting through - we delete around 2 to 3 Mb of spam every day!

The bottom line

So, how much did it cost us? The main cost was in time - I'm not sure how many hours we put in, but it seemed like a lot (especially when things didn't go well!). We took advantage of the quiet Christmas period for the bulk of the work. The actual costs were:

• PC - no costs - we already had this and the new hard drive was a present from an American circuit rider over here for the Lasa Circuit Rider Conference who didn't want the hassle of taking it through customs on the way back. Why he had it in the first place is a bit of a mystery! Thanks, Allan.
  
• SUSE LINUX - £45
• Exim book - £6 (used copy from Amazon)
• 3 day SUSE LINUX course (price variable, heavily reduced rates if skills licence taken out)
  

Observations

1. It took a lot longer than we thought - about 3 months. This was mainly because of the steep-ish learning curve of installing SUSE LINUX and getting Exim to work the way we wanted it to. Also we didn't attempt to do it all in a single hit - we had real work to do alongside it!
   
2. The Exim book required a lot of networking knowledge which I didn't have, so made little sense. It was very much a "this is how it works" guide rather than "here's how to do it". In general the documentation on the web wasn't much better (the Exim FAQ did help by providing the correct "router" information we need but we needed Ryan to point this out). The actual settings in Exim that we needed were far simpler than the documentation made out...
   
3. There are a number of web forums which we could have used but I didn't feel confident that I knew enough to even enter into a discussion.
   
4. Without Ryan's help we'd have been stuck. We are extremely grateful for all his help and putting up with our constant pestering and dumb questions.

Is it the answer?

In the main we're pretty happy with the system. However, it does need attention and loving care to make sure that we stay ahead of the spammers - rules are added on a regular basis and scores adjusted where we are being a bit too aggressive or not hard enough. Maybe a managed service would have been more effective - but we wouldn't have had nearly so much fun (or headaches).