Threading and Security

The following Component Object Model (COM) threading and security issues affect implementation of transport event sinks.

Security

Sink Runtime Credentials

The Microsoft® Windows® 2000 Internet Information Services (IIS) process and all event dispatcher threads run with local SYSTEM account credentials. Sink code executed in process within an event dispatcher thread and therefore also executes with SYSTEM account credentials. You can explicitly alter the credential level under which the sink code runs by using standard security application programming interfaces (APIs) (LogOnUser and ImpersonateLoggedOnUser), or by making your sink run out-of-process, preferably as a Microsoft COM+ component. Using COM+, you can restrict the level of privilege for executing sink code, or you can provide network privileges using a domain account by defining COM+ roles. When using COM+, your sink normally runs in a different process than IIS, which prevents sink faults and exceptions from affecting the Internet Information Services (InetInfo.exe) process.

Managing Event Bindings

Binding information is stored in the IIS metabase. Only accounts with administrative privileges can alter or create an event binding.

Threading

The event dispatcher thread executes in the multithreaded apartment (MTA) of the IIS service process. If an event sink COM class is registered to execute only in a single-threaded apartment (STA), the COM runtime will automatically create the necessary STA in the process and will serialize calls to the object in the standard way. If the in-process class is registered as supporting MTA and STA or MTA only, no marshalling is required. If the sink resides in a separate apartment, all interfaces must be marshalled across the apartment boundaries. This marshalling can degrade performance and may be a poor option for high-volume SMTP and NNTP services. Sinks written with scripting languages and Microsoft® Visual Basic® run in STAs.