So, what's all the controversy about antivirus solutions for Exchange Server? Microsoft is telling customers one thing, and the antivirus product vendors are telling customers another. Who's telling the truth and what's the argument?
Historically, antivirus vendors have developed Exchange products that use Messaging API (MAPI) to better intercept messages with viral content. The antivirus software logs on to each MAPI mailbox and scans tables looking for new messages. When messages arrive, the software scans the content (mainly attachments) looking for virus signatures. This approach works well for the most part, but it has potential to miss viruses because in certain scenarios, new messages can slip by (e.g., inbox rules, delivery to PSTs). In addition, MAPI-based scanning engines add substantial resource overhead to the Exchange server. However, the MAPI-based approach was the defacto standard for the first several years of Exchange's life.
Enter Sybari Software with a new approach—a bit unorthodox but very successful. Sybari reverse-engineered the Exchange database API (contained in the ese.dll) and discovered a way to "shim" in its own version of the DLL to grant its software forbidden access to the inside of Exchange's database engine. Sybari's approach was to directly access the database attachments table and wait for new items. The nature of Exchange's database engine functionality (attachments must hit the attachments table when entering the Information Store—IS) leaves little chance for the software to miss items. The result is an innovative antivirus product for Exchange that provides a near-perfect scanning hit rate for known viruses, with lower resource overhead than traditional MAPI-based scanning engines for Exchange.
Sybari's success infuriated both its competitors and Exchange developers. In my opinion, the Exchange developers were upset because they didn't think of it first (it also hurts a software engineer's pride when someone reverse-engineers his or her code). However, Sybari's approach did provide some supportability challenges for Microsoft that prevented the company from fully embracing Sybari's solution for legitimate reasons. Exchange development reacted by developing its own antivirus API that it made available with Exchange Server 5.5 Service Pack 3 (SP3). The SP3 API was supposed to let antivirus vendors achieve the same results as Sybari's approach and provide Microsoft the ability to support antivirus vendors better. Several vendors have released products that support the SP3 API. However, if you scan through the Microsoft Support Online articles, you'll see that it's not clear whether the API really solved any problems (there seems to be just as many concerns with the new API).
As the situation currently sits, Microsoft has stated that antivirus vendors must embrace Microsoft's API for their software to be supported. However, Sybari is still going down its own path. The market is filled with antivirus products that use MAPI-based, API-based, and proprietary methods of virus detection. This race has no clear winner, and I'm not sure that any party is completely correct. Sybari would do well to work closer with Microsoft in this area, and Exchange development should work to understand what drove customers to demand a better antivirus solution (such as Sybari provided) and to work with all antivirus vendors on better methods and approaches to antivirus technology for Exchange. After all, who do you think knows more about this subject—Microsoft or antivirus vendors? For Exchange implementers and administrators, the matter hits a different nerve. We all have to be vigilant and understand the technical and political concerns that surround deploying antivirus solutions for Exchange. As if we don't already have enough to worry about.
