[This is preliminary documentation and subject to change.]
Follow these initial steps to implement a protocol event sink:
Make sure you have set up your development environment property. This includes downloading the Platform SDK build environment, and optionally, the messaging samples.
Make sure you understand the MailMsg COM class. This includes what information this object contains, and how to go about accessing this information.
Decide what type of protocol event you wish to sink. These types include inbound, outbound, and response protocol events. An understanding of what default handling occurs through the SMTP service for each event is highly recommended.
Having decided which events you wish to sink, examine the associated COM interfaces for which you will need to provide an implementation in your event sink COM class. If parameters for the various methods are not clear, first read the reference page for the entire interface, then read the conceptual material about the various protocol events.
Decide what configuration information your sink will require, and where this information will be stored. Think about how administrators will set this information for routine operations. For example, configuration information could be stored in each event binding in the SinkProperties property bag, as hard-coded data in the event sink COM class itself, in Active Directory, in the Registry, or in some other database. Bear in mind that some mechanism will be needed by administrators to configure your sinks operation. This could include an MMC snapin, a command-line WSH script, or code callable from the sink object itself.
Decide whether your sink should be cached for subsequent use. If not, the sink can be re-created for each event. Caching event sinks provides tremendous performance benefits, but care must be taken to ensure that reused sink instances are properly initialized for each use.
Read the guidelines lists for event sinks. Decide what threading model your sink will execute under.