10.11 Exchange antivirus tools

---

The world was very different when Exchange 4.0 first shipped in March 1996. At that time, most viruses were spread through infected floppy diskettes, and good floppy hygiene was normally sufficient to stop virus propagation. As people started to swap more and more attachments through the email system, the dangers of spreading infected files through email or postings to public folders became very evident. Trend Micro Inc. was one of the first companies to respond to the threat for Exchange and shipped its AV product soon after Exchange 4.0 appeared. Originally, Exchange was a very functional and feature-rich email system, but it was not very open to extensions. MAPI was the only API available to developers to build client and server extensions for Exchange, and Microsoft never designed MAPI to be a way to integrate antivirus protection into Exchange. Nevertheless, products such as Trend Micro's Antivirus for Exchange used MAPI to log on to user mailboxes and watch for newly arriving messages that contained attachments. As attachments arrived, the AV product sprang into life and checked the content for viruses.

10.11.1 The problems with MAPI

Implementing an AV solution through MAPI is not straightforward, and a number of problems exist for the developers to solve. First, after Exchange accepts an infected message and delivers it to the user mailbox, a race occurs between the user and the AV agent to get to the attachment first. While software usually responds much faster than people do, it is unlikely, but theoretically possible, that an infected attachment might get through. Second, the requirement to log on to each mailbox is an inefficient access mechanism and becomes more inefficient as the number of mailboxes scale up on a server. This was not important in the early days of Exchange, since few servers supported more than a couple of hundred mailboxes, but the scalability issue became increasingly important as Exchange servers started to support thousands of mailboxes. Third, if Exchange delivers the same infected attachment to many mailboxes, the AV software might attempt to disinfect the attachment many times, duplicating the work repeatedly until it eradicates the virus.

Even with all these issues, AV vendors persisted with MAPI, simply because there did not appear to be any alternative. Microsoft did not provide an AV interface and did not document the private interfaces it used within the product. Faced with this situation, the AV vendors made the best of what they had to work with and concentrated on steadily improving their products, including building management interfaces and tools to make AV software easier to manage, as well as adding capabilities to support Internet gateways and platforms other than NT. The first break in the MAPI wall occurred when Sybari shipped Antigen for Exchange in 1998. Sybari knew about the problems with MAPI, so it avoided the problems and perfected a technique (the famous "ESE shimmy") to swap out ESE.DLL (the DLL that drives the Extensible Storage Engine, the heart of the Store) for a brief period to load its code and then swap ESE.DLL back. Once loaded, Antigen monitors the attachments table in the IS to check attachments as new messages arrive. It is an effective and scalable technique, but one that Microsoft hated and refused to support until convinced otherwise by the success that Sybari had and the fact that other vendors, such as Trend Micro, started to use ESE instead of MAPI in their products.

10.11.2 VSAPI-virus scanning API

Microsoft's response to Antigen's use of ESE and the complaints about MAPI from other AV vendors is the Virus Scanning Application Programming Interface (VSAPI), a fully supported and documented interface designed to allow AV vendors to integrate their code directly into important Exchange components, such as the Store, MTA, and Routing Engine. However, the first release of VSAPI did not include all of the hooks required to support the feature set provided by existing products, so most vendors built test versions that used VSAPI but continued to base their "real" products (or rather, those that they recommended to customers) on MAPI or ESE.

Microsoft responded with updated versions of VSAPI 2.0 in Exchange 2000 SP1 followed by VSAPI 2.5 in Exchange 2003. The latest version allows AV software to tag infected messages so that Exchange does not deliver them to users. With VSAPI 2.0, AV software can remove malicious content, but a message always arrives in a user's mailbox. Users know that they have received an infected message and can contact the originator to determine whether he or she knows if there is an infection problem. However, especially in the middle of a heavy virus outbreak, you simply want to suppress everything and have messages stopped dead in their tracks, so VSAPI 2.5 allows AV software to control whether the Store aborts the delivery of infected messages. It is up to the AV vendor whether to enable this feature in its software. Another change in VSAPI 2.5 allows AV software to send a notification automatically to the originator of an infected message to tell him or her that there is a problem. Of course, all the features in VSAPI are of no help unless you run Exchange 2000 or 2003 with an AV product that supports VSAPI, but at least we now have a common API. All of the major AV vendors, including Trend Micro, McAfee, and Sybari, are committed to VSAPI.

All classes of virus checkers-even VSAPI-have difficulty with encrypted messages. The problem is simple. By definition, the encryption process protects the contents of an encrypted message against access unless you possess the necessary keys. AV software does not have the keys, so it cannot detect the patterns in content that allow it to recognize viruses. While you might consider that not being able to deal with encrypted messages is a shortcoming and a potential hole in antivirus protection, the impact is lessened when you realize that people who send an infected message to your company are unlikely to possess the necessary public keys to allow them to encrypt the content, unless you share private keys outside the company. Encryption is more of a problem if a virus gets into a company and then is circulated in encrypted messages. This is one situation when an insistence that all messages should be encrypted to protect against unauthorized access can introduce problems that the authors of such policies do not even dream of. If a problem with encrypted messages occurs, all you can do is attempt to disinfect the Store and remove all instances of the offending message. Microsoft provides the ISSCAN utility for this purpose for Exchange 5.5, and you can use the ExMerge utility to remove specific messages from Exchange 2000 or 2003 servers.

Any virus checker will steal some CPU cycles from your system. In most cases, the cost is between 5 percent and 10 percent, which is acceptable given the benefit gained through better protection. Your mileage may vary in line with message volume. In any case, if your system can't afford to give up 15 percent of its CPU capacity, it's time to upgrade your hardware, since the server is incapable of handling the peaks in demand that are inevitable in any messaging environment.

10.11.3 AV impact on multilingual clients

The language of the first client that connects to a mailbox determines the names of the default folders (Inbox, Deleted Items, and so on). Usually, this is not a problem, since the client runs software in the same language as Exchange and the server, but it can result in an interesting side effect in multilingual environments, where the antivirus software runs in a language different from the client's language. Exchange is available in far fewer languages than Outlook, and antivirus vendors follow the example set by Microsoft and limit the number of supported languages. Thus, you may find an English-language Exchange server supporting clients running in Portuguese, Spanish, Greek, and so on.

The problem occurs if the antivirus software performs a MAPI logon to connect to a mailbox before the user. To Exchange, the connection appears the same as any other MAPI logon, so the server recognizes the language specified in the connect request and creates the default set of folders in that language. Therefore, we may end up with folder names that the users do not recognize and cannot work with. The problem does not occur with AV software based on the VSAPI.

Outlook provides no way to reset the names of the default folders (this was possible with the earlier Exchange 4.0 and 5.0 clients), but you can change the folder names through some VBScript commands. Scripts typically execute in the context of an active Outlook session, so you should put the commands in a script that can be stored in a public folder for users to access. You need no special privileges to run the script. Table 10.6 lists the standard set of folder names in English, along with the identifier you need to reference in order to work with each folder.

Table 10.6: Standard Folder Names and Identifiers

Folder Name	Identifier
Deleted Items	3
Outbox	4
Sent Mail	5
Inbox	6
Calendar	9
Contacts	10
Journal	11
Notes	12
Tasks	13
Drafts	16

Using these identifiers, we can build a script to modify the special folder names to whatever values we require. The script code in Figure 10.48 changes the Deleted Items folder to "Wastebasket" and the Calendar folder to "Diary"; this gives you an idea of what needs to be done to set the folders to whatever names you want, should the need occur.

Set myOutlookApplication = CreateObject("Outlook.Application") Set mynamespace = myOutlookApplication.GetNameSpace("MAPI") Mynamespace.GetDefaultFolder(3).Name="Wastebasket" Mynamespace.GetDefaultFolder(9).Name="Diary

Figure 10.48: Setting folder names in VBScript.

10.11.4 Selecting the right AV product

With such a confusing vista of MAPI, VSAPI, and ESE protocols and multiple AV products on the market, what should you do to select the right AV product? Because every implementation of Exchange is different, the best idea remains to download trial versions of products from vendor Web sites and test the products in a test environment that accurately mimics the characteristics of the production systems, especially the hardware configurations and clusters that you plan to deploy. You should also test the special features of each product to decide whether these features are important in your situation. For example, you could test the multiple scan engine feature of Sybari's Antigen, or look at how easy it is to deploy AV software to new servers using Trend's management tools. You may also want to test performance to establish the additional load that the server must handle when an AV product is active. In addition, be sure to test how easy it is to fetch new virus pattern files from the vendor's Web site after it discovers a new virus. The ideal situation is to be able to download a new pattern file automatically a matter of hours after detection. After these tests, you should have the information you need to make the right decision.

In some cases, the factors that drive the buying decision are unrelated to Exchange. For example, Trend Micro's major strength is its range of products that support multiple platforms, so if you are interested in protecting platforms other than Windows, it might make sense to focus on vendors that can support all the platforms that you operate. Sybari is not a traditional antivirus vendor, because it does not produce its own virus-checking engine. Instead, Sybari licenses engines from other major antivirus companies, such as Norton, and concentrates on the management interface and the ability to run multiple engines from different companies. The logic here is that a new virus might get through the scan by one engine, but there is a better chance that you will catch a virus if multiple engines are scanning. Support for multiple engines is a major strength of Antigen, but the product only runs on Windows.

Table 10.7 lists three of the major players in the Exchange antivirus market. This is only a small selection. A more comprehensive list of AV products for Exchange is at http://www.microsoft.com/exchange/partners/ antivirus.asp. The fact that the list contains so many alternatives is testimony to the relative approachability of VSAPI.

Table 10.7: Major Antivirus Products for Exchange

Company	Product	URL
McAfee	GroupShield	http://www.mcafeeb2b.com/products/groupshield-exchange2000/default.asp
Sybari	Antigen	http://www.sybari.com/products/antigen_exchange.asp
Trend Micro	ScanMail	http://www.antivirus.com/products/smex2000/

You do not even have to wait for an approved purchase order before starting to protect your system with a virus checker, since most vendors make 30-day test versions available for download from their Web sites.

Whatever AV software you use, it is critical that you download updated pattern files on a regular basis. Pattern files contain details of the signatures or definitions that allow checkers to recognize viruses. The speed with which new viruses appear and propagate means that you can only defend your Exchange servers if you download and install the latest pattern files on a regular basis. Some virus-checking products, such as Antigen, allow you to download the latest pattern files directly from the product itself, which is a nice feature. It is even better when the new pattern is automatically installed and operational as soon as the download completes.

Companies often look for information about others that use products before they buy. Premerger, Compaq used Antigen to protect its Exchange servers, while HP used ScanMail. Does this make either product better than the other? No, but it does reassure customers if they know that another large company protects its email infrastructure with a product that they are considering.

---