Spam CookBook

Ingredient 1: Set up systemwide blocking rules that block known spam. We were getting a number of junk messages that had a particular string in the "From" header. We blocked these by creating a simple server-based rule that rejected mail with that particular header. Problem solved, and it took only a minute, at least for that single sender. And therein lies the problem--the target is always moving, and this solution is designed to hit a stationary mark.

Ingredient 2: Create blacklists of known offenders. A blacklist lets your customer's mail server query, via DNS, a list of known spammers maintained by a variety of organizations, such as the Mail Abuse Prevention System Realtime Blackhole List (at www.mail-abuse.org), SpamCop.net and Spamhaus.org. We use all three services, and that combination is about right for our users.

Stricter lists actually increase the risk of blocking legitimate mail. Others don't do enough to block spam. The lists are created and maintained in a variety of ways, from sending "robots" out to look for open relays, then listing them when they're found, to creating lists dynamically based on minute-by-minute analysis of user reports. SpamCop uses the latter method, along with a scoring system that factors in the percent of spam sent from a system vs. legitimate e-mail, the freshness of the report and whether the report is for mail sent to a spam trap.

Ingredient 3: Use whitelists. A whitelist identifies servers that can always deliver mail to your users. IronPort's Bonded Sender Program is a good example. IronPort's idea is that large e-mailers with legitimate business needs can post a bond, the size of which is determined by the amount of mail being sent. ISPs and corporations that subscribe to IronPort's whitelist allow all mail that has been bonded through to their users. Spam complaints about those messages generate fines that are paid from the bond.

Ingredient 4: Set up filters. We break this category down into three distinct groups: client-based, server-based and outsourced. Client-side products plug into your users' e-mail software or connect directly to their mailboxes, and include new entrants such as SpamSubtract.com and Audiotrieve.com's Inboxer. These packages typically cost less than $50 per seat, but they don't save your servers from having to process all the spam messages to begin with, and you have increased support issues as well once these products are deployed across an organization.

Server-based filtering products run the gamut from commercial software, such as Brightmail's Anti-Spam, Vircom's VOP modusGate and SurfControl's E-mail Filter for SMTP/ Exchange, to the free PERL-script-based SpamAssassin. Then there are outsourced solutions, such as Postini's Active EMS and products from Singlefin, which are more sophisticated versions of their client-based brethren, operating on e-mail as it enters the server rather than after it is delivered. If you implement a server-based product, your customers are freed from managing their own antispam measures, and support issues are centralized.

Before you start with any one of these products, make sure you can tailor spam-filtering activities for various user groups. Your clients' sales folks may want to receive all their mail unfiltered--the cost of their missing an important message due to a false positive may be high--while their engineers might want to filter 110 percent of their mail.

Ron Anderson is lab director at Network Computing. He can be reached at randerson@nwc.com.