| WIKI | FAQ | Tech FAQ | |
 http://csua.com/feed/ | |
| ||||||
| 5/25 |
| 2006/8/5-10 [Industry/Jobs] UID:43916 Activity:nil |
8/5 question for the MS Exchange VSAPI aware folks out there. In
VSAPI, are scan engines implemented as DLLs (or similar shared
objects) that are loaded into Exchange's address space, specifically
the Information Store, or are they separete processes that
communicate with Exchange via pipes/sockets/etc ala Milter? I'd
"read the fucking documentation", but apparently MS doesn't make
that readily available to non-developer$ --Jon
\_ Developer$, developer$, developer$, developer$, developer$
developer$, developer$, developer$... --SweatyBallmer
\_ They are separate processes. -geek
\_ Try again:
Login: geek Name: Eugene Kim
Directory: /home/sequent/geek Shell: /csua/adm/bin/safesorry
Never logged in.
Mail forwarded to eek+geekfwd@ocf.berkeley.edu
\_ Jon, read this:
http://msexchangeteam.com/archive/2004/10/20/245157.aspx
...
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.
\_ Dude, who the hell would ever read that? -average American |
| 5/25 |
|
| msexchangeteam.com/archive/2004/10/20/245157.aspx first Exchange Team blogs, the VSAPI was conceived following the breakout of Melissa. Since we were well into a mature product lifecycle, Exchange 55 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 55 due to architecture and potential destabilization. The VSAPI has undergone 3 revisions, each released with the respective releases of Exchange: Version Description VSAPI 10 Introduced in Exchange 55 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 20 First introduced in Exchange 2000, VSAPI 20 represented the next evolution of the virus scanning interface. It allowed for a more robust and feature rich implementation. 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. 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 25 In Exchange 2003 version 25 of the VSAPI was introduced. This was a minor revision to the existing VSAPI 20 interface in Exchange 2000. This version added the following: * Additional MAPI properties were exposed allowing vendors to capture more detail regarding the message (eg Sender's Address) * Better handling of signed messages. 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. 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. |
| ocf.berkeley.edu EDU/ If the link above does not work, it is likely that the user whose page you are attempting to reach no longer has an account with our facility. |