Programming Guidelines for Event Sinks

Exchange Server 2003

Topic Last Modified: 2004-06-08

This section outlines guidelines for implementing an event sink.

  • For optimal performance, create an in-process Component Object Model (COM) class that supports execution in a multi-threaded apartment (MTA). The event dispatcher threads execute from within the Microsoft® Internet Information Services (IIS) MTA. If your sink supports the single-threaded apartment (STA) only (and the default for Visual Basic), then all interfaces will be marshalled across the MTA apartment and STA apartment boundaries.
  • Provide an implementation of the IEventIsCacheable interface by your sink. If you implement the IEventIsCacheable interface and the IsCacheable method returns S_OK, the event dispatcher will cache the sink and will use the same object for subsequent events; otherwise, each event will create a new instance of the sink.
  • Never install an untested sink on a production server, especially a sink that runs in- process. Exceptions thrown from within these in-process sinks may disable the IIS (inetinfo.exe) process or cause it to stop responding.
  • Do not place Microsoft® Collaboration Data Objects (CDO) interface definitions in your sink’s interface definition language (IDL) file (if you use one directly) when working in C or C++. Information about CDO types—including all classes, interfaces, enumerations, and modules—can be found in the supplied headers. If you do place IDL information in your IDL file, and any of these types are referenced from within your library statement, you will re-map various Interface IDs (IIDs) from the CDO dynamically link library (DLL) to your DLL. This will not cause immediate harm because your DLL contains the necessary type library information required for the universal marshaller to function properly; however, if you subsequently remove the sink from the registry, the CDO libraries will function improperly.

Note  if an SMTP event sink changes a message after the user has digitally signed it the accompanying digital signature will be invalid. If an event sink modifies the body of a signed message the sink should remove the digital signature, the event sink should indicate why the signature will appear invalid, or the event sink should re-sign the message. SMTP event sinks cannot apply disclaimers or access the body of S/MIME and other encrypted messages when the encryption keys are unavailable.