(Note: this article is #1 in the series that covers the Exchange VSAPI. For part 2 please go here and for part 3 please go here. There will be additional parts added in the future too.)
Keying off one of the comments regarding the VSAPI, I thought this might be an interesting post. Besides I haven’t blogged in a while... This article discusses some of the workings of the VSAPI I will mention Exchange 5.5, but will focus primarily on Exchange 2000/2003. There will be several parts of this VSAPI series.
History
As Jon points out in one of the first Exchange Team blogs, the VSAPI was conceived following the breakout of Melissa. Since we were well into a mature product lifecycle, Exchange 5.5 Service Pack 2, changes introduced by VSAPI had to be minimal. We elected to tackle the biggest bang for the buck, attachments. At the time attachments represented the easiest and most vulnerable aspect of a message. Anytime you introduce changes of this scale, you still have the potential of introducing problems.
At the same time, plans were being made on how to make VSAPI robust in Exchange 2000. There were limitations of what could be accomplished in Exchange 5.5 due to architecture and potential destabilization. The VSAPI has undergone 3 revisions, each released with the respective releases of Exchange:
| Version | Description |
| VSAPI 1.0 |
Introduced in Exchange 5.5 Service Pack 3. The main goal with this release was to provide a way for a vendors to gain first and exclusive access to attachments at a low level in the store’s processing. It had to be as fast as possible, thus the requirement the vendor must run within the context of the store process.
The vendor would identify an attachment as being safe, cleaned, or a having a virus present. The client requests were based upon timeout values, which led to less than acceptable client experience. No Perfmon counters were available to monitor the state of the scanning and the event logging was minimal (Start, Stop, Reload)
|
| VSAPI 2.0 |
First introduced in Exchange 2000, VSAPI 2.0 represented the next evolution of the virus scanning interface. It allowed for a more robust and feature rich implementation. For example:
· Message body streams (both MIME and MAPI formats) can be streamed to the vendor in addition to attachments. · The client timeout model was replaced with a notification based model. · A thread pool to process the virus scanning queue was introduced (vs. a single threaded model in VSAPI 1.0) · Vendors could obtain basic message properties such as sender/receiver/subject to report details regarding the message. · Perfmon counters and more detailed events added to address supportability.
|
| VSAPI 2.5 |
In Exchange 2003 version 2.5 of the VSAPI was introduced. This was a minor revision to the existing VSAPI 2.0 interface in Exchange 2000. This version added the following:
-
Additional MAPI properties were exposed allowing vendors to capture more detail regarding the message (e.g. Sender's Address) -
Better handling of signed messages. -
VSAPI Scanning of messages for gateway server scenarios |
Vocabulary
Before we can really delve into the details of VSAPI and how it works, it is important to have a common vocabulary. Unfortunately there is confusion at times between an ISVs definition and what really is happening inside the Information Store to accomplish the task.
| Term | Definition |
| Item |
An item is the basic element to be scanned. This could be the body of a message in MIME or MAPI format and/or an attachment.
|
| On-Access Scan |
This is a request to open an item directly related to a client operation. (e.g. Client double clicks on a message.) This operation occurs at high priority.
|
| Proactive Scan |
As items are delivered to folders they are placed into the queue as low priority items. If the system is in low stress conditions, items have an opportunity to be scanned before a client request them. Should a client request the item while it is in a low priority state, the item is promoted to high priority item. A maximum of 30 low priority items may reside in the queue at any given time. Items are removed in FIFO order as new low priority items are introduced.
|
| Background Scanning |
This is separate task thread that traverses through items in a database looking for instances of items that have not been scanned by the latest version of the scanning DLL.
|
| Queue |
Items waiting to be scanned by the vendor’s scanning engine. One queue exists for the entire Information Store process and contains both high and low priority items. A maximum of 30 low priority items can exist in the queue and are removed in FIFO order.
|
| Vendor Scanning DLL |
This is a DLL provided by an anti-virus vendor written to the VSAPI specification. The specification essentially states the vendor must provide 3 interfaces: A startup function, a scanning function, and a shutdown function. The Information Store loads this DLL into the Information Store process. Upon loading the DLL, the Information Store calls the startup function provided by the vendor. As with any DLL running in a process, the vendor can allocate memory, spawn new threads for supporting reporting functionality, or initiate communication to other processes on the system supporting the VSAPI engine.
|
- Jeremy Kelly