This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.
This topic provides information using SMTP Event Sinks to develop messaging applications.
The Microsoft® Windows® 2000 SMTP and NNTP services provide a high-performance, component-based event architecture for message processing, delivery, and relay. These services can be extended by means of event sinks that can process a message as it passes through the system.
CDOSYS event sinks do not have all the capabilities of the SMTP protocol event sinks, but may be simpler to use. Microsoft® Transaction Server does not support SMTP event sinks. SMTP event sinks cannot be included in COM+ applications. Event notification filtering is not available for messages submitted by using MAPI clients when the event sink is registered on the same computer on which the message was submitted.
SMTP Event Sinks
Typical applications that use SMTP events include virus scanners, mailing list services, message routing services, queuing applications, local delivery mail storage, and protocol command extensions.
The event architecture is based upon the Component Object Model (COM). Sinks registered to handle events are simply COM objects that expose the appropriate COM interfaces. When a particular event occurs, the service creates an instance of the event sink COM class, requests to the appropriate interface, and executes the event method. To allow for high-performance, multi-threaded sinks, the framework allows for either synchronous or asynchronous sink processing. The message being transferred through the SMTP service is packaged in a MailMsg COM object for use by the event sink.
Data access model
The message data is presented to the sink as a MailMsg COM object.
Multi-threading can be used in event sinks.
SMTP event sinks run on the computer where the message is being transferred. Applications that use SMTP event sinks typically do not have a GUI application to configure how the event sinks operate. Instead, applications typically use registry settings or configuration files to control their operation.
SMTP event sinks must run on the computer where mail is being processed. SMTP event sinks cannot be used in COM+ applications.
SMTP event sinks do not use transactions.
SMTP event sinks have no built-in management capabilities. Windows Event Log entries and performance counters can be built into SMTP event sinks to provide additional management and monitoring capabilities. The contents of the Presubmission queue can be viewed in the Exchange System Manager on computers on which Exchange is installed.
SMTP event sinks are part of the SMTP service, a component of Internet Information Services.
SMTP Event Sinks
Languages and Tools
SMTP event sinks written in unmanaged code can only be written by using C and C++.
SMTP event sinks can be written by using scripting languages.
No special debugging tools are needed to debug applications that use SMTP event sinks. For particularly difficult protocol-interaction issues, a network monitoring utility may prove helpful, but is typically not required.
Developers who have significant previous experience with SMTP event sinks are uncommon, and learning how to use them can be difficult.
For information about developing by using SMTP event sinks, see SMTP Server on MSDN.
Developer / Deployment Licensing
No special licenses are needed for using SMTP event sinks. Depending on your configuration, your systems may require access to additional SMTP, NNTP, or Exchange servers to transport messages to their destination.
SMTP Event Sinks
Creating SMTP event sinks requires that the developer be permitted to register COM components on the local machine where e-mail is processed. This permission is usually granted by way of allowing the developer to install software. If the developer is not working on a production server, the possibility that unencrypted sensitive information will be available on that computer is lower. Permitting development work on production e-mail servers is not recommended.
Because unencrypted sensitive information may be flowing through the production e-mail server, use care when granting permission to install software. It is recommended that deployment to the production servers be performed by administrators.
SMTP event sinks run in the same process as the SMTP service, and share the same security credentials as that service account. This may affect what resources the event sink can access.
Built-in Security Features
SMTP event sinks provide no built-in security features. If an event sink changes a message after the user has digitally signed
it, the accompanying digital signature will be invalid. SMTP event sinks cannot apply disclaimers or access the body of S/MIME and other encrypted messages when the encryption keys are unavailable.
Security Monitoring Features
SMTP event sinks provide no built-in security monitoring features. SMTP event sinks can create Windows Event Log entries as needed.
SMTP Event Sinks
Server Platform Requirements
SMTP event sinks require that IIS Admin and SMTP services are configured and running properly. The Event sink COM component must be registered on the computer, and the event must be registered with IIS.
Client Platform Requirements
SMTP event sinks are not considered a client technology. Typical applications that use SMTP event sinks will usually not include a GUI application for configuring and monitoring the system.
Applications that use SMTP events can be deployed to computers by means of standard software distribution technologies. The installer should verify that IIS and the SMTP service are installed and configured properly.
SMTP event sinks run in the same process as IIS, and share the same security credentials as that service account. This may affect what resources the event sink can access.