Spam Cleaning with the Big Boys: Page 2
Spam Protection at the Gateway
Regardless of the specific gateway program used, this kind of software always has several things in common. First, the gateways must run on boxes of their own. You can't run them on the same box as the mail server, regardless of whether you're running sendmail or Exchange 2000.
Next, you should take the memory requirements for any given program and double it on your production machines. It's not that the software won't run properly at the minimal required level of memory; it will. However, these programs need every KB of RAM they can get in order to more quickly weed out the bad mail. These processes take up a lot of RAM, and remember, the spam load is only going to get higher – much higher – in the coming years.
To keep the mail moving in a timely fashion, you'll also need as fast a connection as you can get between your spam killer, Internet gateway, and e-mail server. If you've been thinking about moving to Gigabit Ethernet, well, pulverizing spam is a better reason than most for the upgrade.
You do need to give your users some level of control over the spam process, as one man's spam is another man's steak. There are two basic ways to approach this. One is to simply deliver the spam to the user's client mailbox and set it up so that they can look in their spam mailbox whenever they want.
There are two problems with this approach. The first is that your internal network is still going to be clogged up by spam traffic. The other is that if you're going to go ahead and send all the spam along, perhaps an inexpensive or open source client-based solution like POPFile, would serve your users better.
The second way of handling it is to simply keep the most recent spam mail in a server-based folder for users to look in if they suspect that they've missed a very important message. This option isn't ideal either; in this case, you're committing valuable server disk space to spam.
But it's not as if you have much of a choice. Even with the best Bayesian filters and individually tweaked anti-spam settings, at least one message in a hundred will be misidentified. That's not so bad, especially when it means that your users will see a small fraction of junk e-mail instead of the flood they're used to, but every now and again, a message that needed to get through – a false-positive – will get blocked. It's for those valuable but misidentified messages that you need to give your users some mechanism to look at their spam mail.