The Great Antivirus Crusade

A confusing saga with a hopeful ending

Any Microsoft Exchange Server machine that you don't properly protect against email viruses is a disaster waiting to happen. Viruses spread quickly after they enter a messaging system, and today's viruses exploit Microsoft Outlook's programming capabilities, as well as human curiosity, to propagate faster than ever before. Although many antivirus products for Exchange Server exist, sorting out which products are the best in their class, why they're the best, and why you should deploy them can be confusing.

Microsoft's hesitance doesn't help the situation. For the past few years, the company has been fumbling to provide useful Exchange Server antivirus interfaces. Its slowness in doing so is partially the result of the advent of Microsoft Exchange 2000 Server. Exchange 2000 is much more open and approachable (from a programming perspective) than earlier versions of Exchange Server, so the development task is easier. But Exchange 2000's SMTP routing engine, storage groups (SGs), multiple mailbox and public stores, and front-end and back-end systems pose new challenges for the detection and isolation of incoming viruses. Also, an organization's need to keep Exchange Server 5.5 (and earlier) systems running until it decides to migrate to Exchange 2000 adds the challenge of ensuring that viruses don't get through in a mixed-mode server environment.

The existence of mixed-mode Exchange Server organizations, a war of words between Microsoft and various antivirus vendors, and claims and counterclaims between those vendors all contribute to a fear, uncertainty, and doubt (FUD) factor that might hold sway over your decision to purchase virus protection for your Exchange Server machines. Let's try and resolve some of that FUD by examining the situation: how we got to this point, what your current options are, and how those options might be about to change.

A Brief History
When Exchange Server 4.0 first shipped in 1996, most viruses were still being introduced to computer systems through infected 3.5" diskettes. As people swapped more and more attachments through email, the danger of spreading infected files through email or postings to public folders became increasingly evident. Trend Micro was one of the first companies to respond to the threat to Exchange Server and shipped its first Exchange Server antivirus product soon after Exchange Server 4.0 appeared.

Exchange Server 4.0 was a functional and feature-rich email system but wasn't very open to extensions; Messaging API (MAPI) was the only API available to developers who needed access to the Information Store (IS). MAPI is a messaging interface for clients and servers and wasn't designed as a way to integrate antivirus protection into Exchange Server. Nevertheless, products such as Trend Micro's ScanMail for Exchange and McAfee's GroupShield Exchange used MAPI to log on to user mailboxes and watch for arriving messages that contained attachments. As attachments arrived, the products scanned the content for viruses.

The Problem with MAPI
Implementing an antivirus solution through MAPI isn't straightforward and involves several problems. First, the antivirus agent needs to race the user to get to the attachment. Although software responds much faster than humans on nearly every occasion, the potential for a software glitch to let an infected attachment get through still exists. Second, the requirement for the agent to log on to each mailbox is inefficient and becomes more so as the number of mailboxes on a server scales up. This restriction wasn't too important in the early days of Exchange Server because few servers supported more than a couple of hundred mailboxes. However, the scalability issue became increasingly important as hardware improved and as Exchange Server machines began to support thousands of mailboxes. Third, if the same infected attachment is delivered to many users, disinfection must take place many times. The fourth and final problem is that Microsoft hasn't worked to develop MAPI since 1996. Some MAPI bugs have been fixed, but Microsoft's attention to protocols and interfaces has firmly focused on the Internet since Exchange Server 5.0 shipped in November 1996.

Despite these problems, antivirus vendors persisted with MAPI simply because they didn't appear to have any alternative. Microsoft didn't provide an antivirus interface and didn't document the private interfaces it used within Exchange Server. Faced with this situation, antivirus vendors made the best of what they had to work with. The vendors concentrated on steadily improving their products—building management interfaces and tools to make antivirus software easier to manage. The vendors also added capabilities to support Internet gateways and platforms other than Windows NT.

Sybari's ESE Shimmy
The first chink in the MAPI wall occurred when Sybari Software shipped Antigen for Exchange in 1998. (Antigen for Lotus Notes had been around for a while, so Sybari had some expertise in the antivirus-for-email systems area.) The Sybari product was different from other vendors' products because it didn't use MAPI and therefore wasn't affected by MAPI's inherent problems. But what interface did Antigen for Exchange use to access the IS?

Sybari was very closemouthed on this point and refused to disclose the answer. The vendor regarded the information as a trade secret and didn't want to reveal it to competitors. Over time, however, the answer became apparent: Antigen for Exchange used a "shimmy" to load code when the IS started. Essentially, the product swapped out the official version of ese.dll (i.e., the DLL that holds the code for the Extensible Storage Engine—ESE—the heart of the IS) for a brief period—long enough to load Antigen's code—then swapped ese.dll back in. Antigen then concentrated on monitoring write and update operations to the version store in the IS and sprang into action whenever an attachment arrived.

The shimmy technique was effective and scalable but totally unsupported by Microsoft, which promptly decried Sybari's methods. Microsoft Product Support Services (PSS) refused to support Sybari-protected servers and forced customers to remove the Antigen code before PSS would look at problems. PSS has moderated its hardline stance, however, and now follows a documented procedure to remove Antigen—through a Sybari-provided utility program—before working on a problem. (For a description of the procedure, see the Microsoft article "XADM: Understanding How Sybari Antigen Software Interacts with Exchange Server" at http://support.microsoft.com/support/kb/articles/q250/5/00.asp.)

Despite pressure from Microsoft, the acid test of the market supported Sybari. Antigen is now a well-accepted product in use by many large corporations, including Compaq. Antigen supports both Exchange 2000 and Exchange Server 5.5 and runs on clustered and nonclustered servers. The product is fast, scalable, and robust and has been put to the test by the various virus outbreaks we've seen over the past 2 years (e.g., Melissa, Worm.ExploreZip, VBS.LoveLetter). But a problem still exists in perception if not in reality: Antigen works, but it leverages an unsupported API. Soon, though, Sybari might overcome that hurdle.

Microsoft's Answer
In response to Antigen's manipulation of ESE and other antivirus vendors' complaints about MAPI, Microsoft developed the virus scanning API (VS API—previously called antivirus API), a supported interface that lets antivirus vendors integrate code directly into the IS. The first version of VS API shipped with Exchange Server 5.5 Service Pack 3 (SP3). So why weren't the antivirus vendors happy?

Well, the first VS API version (for either Exchange 2000 or Exchange Server 5.5) doesn't deliver as much functionality as the vendors can achieve through MAPI or the ESE shimmy. For example, VS API permits identification of an infected attachment but doesn't return much context (e.g., information about the sender, a link to the original message). Also, some problems have occurred with scanning products that work with VS API to scan SMTP mail. (For information about these problems, see the Microsoft article "XADM: Contents of the .stm File Are Not Scanned When Using Antivirus API" at http://support.microsoft.com/support/kb/articles/q286/6/38.asp.) No vendor wants to throttle back its product's functionality, and the vendors and Microsoft have exchanged some hard words.

Discussions continue, and a new VS API version that addresses vendors' needs will likely ship in Exchange 2000 SP1. Of course, this possibility will help you only if you're running Exchange 2000 and only after the vendors have a chance to build new product versions that exploit VS API—but the possibility is still a positive sign for the future. All the major antivirus vendors, including Trend Micro, McAfee, and Sybari, have committed to using VS API—as long as Microsoft fulfills its commitments to deliver the required functionality. (Sybari recently announced its specific intention to support this new version in Antigen.)

Trend Micro Goes ESE
In the meantime, customer demand and the need to remain competitive have forced Trend Micro to reconsider its original stance, in which it uses only its original MAPI-based implementation or the current version of VS API. The vendor is about to release a new version of ScanMail for Exchange that's based on ESE, a move that will delight Sybari and infuriate Microsoft. (At the time of this writing, the product was expected to ship in March.) (Sybari will be happy because Trend Micro's new product will validate Sybari's implementation; Microsoft won't want to see another product based on an unsupported and undocumented API.) Separate versions of ScanMail for Exchange will be available: One will continue to use the MAPI interface and another will use ESE. (Trend Micro doesn't use MAPI or ESE in its ScanMail product for Exchange 2000, which instead uses VS API.) Your choice will largely depend on whether you're comfortable using a product that's based on a formally unsupported interface. However, Sybari has done a pretty good job with ESE over the years, so Trend Micro might not present much of a risk.

I have sympathy for Trend Micro in its move to embrace the ESE approach after disapproving of its use for many months. Market forces often dictate behavior, and this vendor's change of heart is simply an example of how the market doesn't wait for a response from companies such as Microsoft.

Make a Selection
With such a confusing vista of MAPI-, antivirus API-, and ESE-based products, how do you select the best antivirus product for your organization? Because every implementation of Exchange Server is different, the best idea is to download trial versions from vendor Web sites and try out the products in a test environment that accurately mimics the characteristics of your production systems. These tests should give you the information you need to make a decision.

In some cases, factors unrelated to Exchange Server will also affect your decision. Trend Micro's major strength is that it offers a range of products that support multiple platforms. So, if you need to protect platforms other than Windows 2000 or NT, choosing this vendor might make the most sense. Sybari isn't a traditional antivirus vendor because it doesn't produce its own virus-checking engine; instead, it licenses engines from other antivirus companies, such as Symantec. Sybari concentrates on the management interface and the ability to run multiple virus-checking engines from one interface. (A new virus might get through one engine's scan but is less likely to survive multiple scans by different engines.) Support for multiple engines is Antigen's primary strength, but the product runs only on Win2K and NT.

Look to the Future
In time, VS API will mature and deliver the required functionality to let vendors develop high-level antivirus products that aren't plagued by MAPI's shortcomings. The vendors will have an API that works and that is scalable, secure, and reliable. We'll have a range of products built on a supported API. Everyone—even PSS—will be happy. Until then, we'll work with what we have, examine new products on our test systems, and make the best possible choices to protect our Exchange Server systems. (For more information about Exchange Server antivirus protection, see "Related Articles in Previous Issues," page 128.)