Since the Melissa virus gave everyone a wake-up call in 1999, administrators understand the need to protect their Microsoft Exchange Server servers against incoming threats. From an Exchange administrator’s perspective, establishing effective defense against email-borne viruses was the immediate priority, followed closely by educating users about how viruses infect systems and how to recognize suspicious content. Today, most servers are well protected against viruses but perhaps less so against spam. Now is a particularly good time to review your antispam protection because Microsoft has included some new features in Exchange Server 2003 that Independent Software Vendors (ISVs) can leverage in antispam tools.
The concept of defense in depth means using multiple layers of suppression to block as much spam as possible between initial penetration through mail servers to final mailbox delivery. Defense in depth also means increasing user awareness of the likelihood that they'll receive spam if they contribute to Internet newsgroups and other forums, and of the techniques that spammers use to discover addresses that they can't harvest. Of course, like antivirus protection, defense in depth is expensive to establish. Some companies—especially small to midsized enterprises—choose to implement one suppression method rather than multiple layers. If you go this route, server-based suppression is smart because it affords maximum protection to clients (including Microsoft Outlook Web Access—OWA) without requiring you to upgrade desktop software. Let's take a look at some of the tools and techniques you can use to implement defense in depth, as well as the new features in Exchange 2003 that Microsoft has introduced to combat spam.
Defending the Perimeter
Large companies such as HP commonly deploy bastion servers to watch incoming SMTP traffic and make the decision whether to pass messages through for further processing. You can certainly use Exchange 2003 as a bastion server, particularly if you deploy Exchange 2003 on Windows Server 2003 and use an antispam package rather than the software's built-in connection-filtering capability. Although you can also deploy Exchange 2003 on Windows 2000, Windows 2003 is a more secure platform, primarily because of Microsoft Internet Information Services (IIS) 6.0 and the overall effect of Microsoft’s Trustworthy Computing initiative.
Perimeter-defense servers accept SMTP connections for a domain (e.g., abc.com) and perform two quick checks: first, to ensure that the inbound messages don't contain known virus payloads; and second, to check against a recognized Real-time Blackhole List (RBL) provider such as the Mail Abuse Prevention System (MAPS), Spamhaus, or the Open Relay Database (ORDB) to immediately detect spam. Blackhole lists contain entries for known spammers and servers that act as open relays, which spammers can hijack when they want to use someone else’s computing power to send their messages. So, checking incoming messages against a blackhole list is a good way to suppress a lot of spam, assuming the blackhole list is up-to-date. (Don't forget to test traffic against an RBL filter before you introduce the filter into production. Some RBLs let a lot of spam through, whereas others suppress traffic that you need. You might want to combine lookups against multiple RBLs to ensure that you catch as much spam as possible—a capability that Exchange 2003 supports.)
Optionally, bastion servers can validate that a given message is addressed to a valid recipient within the target organization. To do so, the server checks the address against directories such as the Exchange Server 5.5 Directory Store, Active Directory (AD), or another Lightweight Directory Access Protocol (LDAP)–compliant directory. As an example, HP's bastion servers handle approximately 30 million messages per month addressed to hp.com recipients and drop 70 percent of the traffic, leaving roughly 9 million messages to pass through to email servers for processing. Unfortunately, a rising proportion of these validated messages contains spam—a tribute to the skill of spam generators as they combat efforts to suppress their messages.
If you aren’t yet ready to deploy Windows 2003 and Exchange 2003, you can choose from a variety of available commercial perimeter-defense products, such as Clearswift’s CS MAILsweeper for SMTP (which monitors gateways and network connection points) and CS MAILsweeper for Exchange. To avoid the preponderance of attacks against Microsoft systems, some administrators prefer to deploy Linux or UNIX servers as their connection points to the Internet, then adopt antispam and virus-checking solutions that work with sendmail or Postfix Message Transfer Agents (MTAs).
Exchange 2003 Defense
When Microsoft designed Exchange 2000, spam wasn't the annoyance that it is today. Viruses represented the major threat to Exchange servers, so Microsoft concentrated its energies on developing the Virus Scanning API (VSAPI) and convincing major ISVs to support VSAPI by including it in its products. You can configure filters on Exchange 2000 SMTP virtual servers to reject messages from specific users or domains, but this approach isn't sufficiently sophisticated to combat today’s spammers. As Exchange 2003 progressed through development, Microsoft understood that it would need to boost the server’s ability to suppress spam. Exchange 2003 therefore introduces connection filtering, which you can configure through the Exchange System Manager (ESM) console's Global Settings node. Select the Message Delivery object, choose Connection Filtering to define the rules that are applicable for the organization as a whole, then apply the new filters to the SMTP virtual servers on the Exchange servers that host SMTP connections to the Internet.
Figure 1 shows how to configure lists for connection filtering. To ensure that you catch as many unwanted messages as possible, you can configure multiple filters and elect to look up multiple RBLs (or Block List Services). You can also configure exceptions so that Exchange doesn't regard messages from important partners or other correspondents as spam—even if they contain potential spam signatures, such as an offer to "get rich quick." In addition to connection filtering, Exchange 2003 lets you define recipient filters and sender filters. Recipient filters apply blocks to incoming messages that are addressed to specific recipients. You can also create a recipient filter that checks all incoming messages against AD and refuses any messages that aren't addressed to a valid recipient. Spammers routinely use automatically generated addresses in an attempt to send messages to everyone in a domain, so recipient filters let Exchange avoid incurring the overhead of accepting spam and processing it through the routing engine.
Sender filters are similar to recipient filters except that you define a list of email addresses from which you never want to accept messages. When Exchange detects an incoming message from one of the addresses on the "dump" list, it immediately drops the connection. You can also use sender filters to drop connections for messages that have blank sender information—another favorite trick in the spamming community.
Transport Sinks
In Exchange 2000, Microsoft replaced the X.400-based MTA with an extensible SMTP-based routing engine. Ever since, ISVs have been able to implement transport sinks that include code to examine messages as they arrive at the SMTP service (before Exchange accepts them for categorization and further processing). Blocking spam at the SMTP entry point is an efficient use of system resources because Exchange doesn't need to resolve email addresses, expand distribution groups, determine the most effective routing path, or any other message-routing processing. Also, immediately scanning and dumping spam is preferable to propagating spam within the Store. After spam gets into user mailboxes, it typically requires further server overhead in the form of storage, management, transport, and backup—not to mention user annoyance. Finally, server-based spam suppression lets you protect many types of clients without needing to worry about implementing antispam software on Outlook, Outlook Express, and different Web browsers. And wireless-device users will appreciate that spam isn't wasting valuable wireless bandwidth.
Relatively few ISVs have taken up the challenge of developing transport sinks to combat spam, largely because viruses have been the major threat to servers and therefore represent a more lucrative product market. However, some software developers have recognized the possibilities that event sinks offer for spam warfare. A good example of a product that uses an event sink to suppress spam in Exchange 2000 is martijnjongen.com's ORFilter, a freeware tool that checks incoming SMTP messages against lists of open-relay servers and rejects those that come from a known open relay.
I've recently noticed an increased interest in the use of transport sinks for spam suppression among both antivirus vendors (who want to increase the functionality and competitiveness of their products) and developers of purpose-designed tools. Sybari Software’s SpamManager is a good example of a company using a transport sink to extend the capabilities of a well-known antivirus product to provide spam suppression. Sybari's newly introduced Advanced Spam Defense product takes an innovative step by incorporating Commtouch technology that uses digital signatures and network probes to detect, stamp, and suppress spam.