The best way to can spam

Spontaneous end-to-end communication used to be the Internet’s magic ingredient. But scarcity of IPv4 address space and legions of vandals resulted in NATs and firewalls. Now, unfiltered end-to-end communication happens, for the most part, by invitation only.

Free IT resource Virtualization Insights from Top Experts - Learn how virtualization gets real! Sponsored by Dell Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft DOWNLOAD REPORT    Looking for this InfoWorld Special Report in one complete, printable format? Download it for free. >> Special Report: Canning spam

Until recently, the lone exception was e-mail. You didn’t need permission to contact someone by e-mail, and you could be reasonably certain that a message you sent would land in the recipient’s inbox. Inevitably that had to change, too. The spam epidemic compels us to create and use the e-mail equivalent of NATs and firewalls: a combination of content filters, white lists, and blacklists.

The immediate tactical question is not whether to use these techniques, but how. There are also long-term strategic questions about the things we expect e-mail to do. But first things first: If more than a trickle of spam is landing in your organization’s inboxes, you need to solve that problem now.

Identifying the sender

The two main types of anti-spam solutions — those based on the identity of the sender and those based on the content of the message — can be, and usually are, deployed in combination. The two models for deploying anti-spam solutions — on gateways and servers or on clients — can also be used in combination, although many enterprises would prefer a server-based approach that won’t add to existing desktop support and training burdens.

Click for larger view.

Enterprise-oriented products, such as Proofpoint’s Protection Server and ActiveState’s PureMessage, run inbound e-mail through a gauntlet of checks defined by corporate policy. These can include virus scans as well as spam detection. In the latter case, the customer decides which identity- and/or content-oriented spam-detection modules to deploy and whether to reject, quarantine, or merely tag a message when its score tips the spam scale.

Identity is, however, a double-edged sword that can vilify or sanctify a sender. Modules that use DNSBLs (DNS-based blacklists) look up the sender’s IP address in databases that track misconfigured mail servers and reported spammers. These services exhibit varying degrees of transparency and accountability, making them useful yet controversial (see “Blacklists: The New Neighborhood Watch”). Some anti-spam vendors ship with DNSBL modules disabled, subject to customer override. Others use them by default, but judiciously, as a component of an overall score.

Eric Allman, CTO of Emeryville, Calif.-based Sendmail and creator of the company’s eponymous e-mail solution, calls DNSBLs “a dull sword”; a sample of my own messages caught by DNSBL filtering shows why this method should not be used in isolation:

Subject: Caldwell and Associates, Inc. Expands Grant Writing Department

Subject: Final Reminder — SOHO Reception

These legitimate bulk mailings are classic DNSBL “false positives” from probably legitimate bulk-mail senders who got blacklisted. To certify such legitimate senders and to avoid incorrect identification, another set of checks and balances is helpful. IronPort, for example, has created a Bonded Sender program that inverts the DNSBL idea. In this scheme, a high-volume sender (for example, CNET) puts up a bond that’s forfeited if one or more of its registered IP addresses violates a list’s opt-in policy or otherwise engages in spam.

This strategy is a DNSWL (DNS-based white list) from which a positive response means “trustworthy sender.” How an anti-spam system makes use of that judgment is, again, a matter of policy; skipping content checks would be a reasonable and likely policy.

Another new strategy for certifying the sender’s identity is the RMX (Reverse Mail eXchange) proposal. A DNS MX record creates a mail route for a domain name. A domain owner would use RMX records to identify those hosts within the domain that are specifically authorized to send mail, and a server receiving mail would check to see whether the sender’s IP addresses were so identified. Mail from an unauthorized host can be rejected or quarantined.

This is a nice idea that can be rolled out incrementally to combat forged From: addresses. The IP address of the mail server that delivers a message is nearly impossible to forge, but the address in the From: header is easy to rewrite. Spammers do that routinely, playing havoc with white lists or blacklists that depend on those addresses.

RMX is a bit problematic for road warriors who lack remote access to company mail servers and consequently transmit directly from their laptops. But once again, a missing or negative RMX response can be used as just one component of a message’s overall score.

“It’s like caller ID,” says Jesse Dougherty, Vancouver, B.C.-based ActiveState’s director of development. “If I don’t recognize your number, that’s one strike against you, but I may still choose to take the call.”