Installation
Someday this section will cover how service providers are installed, where they are installed, etc. Also cover updating and removal.
When multiple transport providers are installed the user will choose an ordering of the providers to handle cases where multiple providers can handle the same type of delivery (e.g. local FAX provider and server-based FAX connection).
It is acceptable for each type of provider to have a specialized setup/configure program. For example, a phone-line based transport provider could allow selection of time of day to dial in to retrieve incoming messages.
Versions
Service Providers will be able to check the version of the Windows Messaging Subsystem to determine if it is recent enough for their needs. The Windows Messaging Subsystem will check the version of the SPI supported by each installed Service Provider and will only make calls appropriate to that version. If the versions are too different the Windows Messaging Subsystem may refuse to use a service provider.
This document describes SPI version 1.00.
Security Model
Each transport provider is responsible for implementing an appropriate level of security for access to its underlying messaging system. Each incoming or outgoing message that the spooler sends through a transport provider is sent in the context of a "login session" to the transport provider. The transport provider may display a login dialog that prompts for a user's credentials before allowing any message transfer to take place. Alternatively, the transport provider could remember the user's previously entered credentials and use them for access without prompting.
To assist the transport provider with its requirements for implementing security, the Spooler is capable of storing credential sets for the transport provider, at the transport provider's request. The transport provider can choose what information is retained for each local user. It might be as little as the network address of the server but no name or password, all the way up to a complete credential set. The Spooler will encrypt any information it stores for the transport provider.
Who's Job is It
Transport Provider DLLs provide the interface between the Windows Messaging Subsystem Message Spooler and the underlying messaging system(s). The Spooler and the transport provider work together to handle the responsibilities of sending a message. The interface between the Spooler and the provider is called the Transport SPI. The Transport SPI allows multiple installed transports on the same system.
Message Store Responsibilities
Store local identity of user in a message when it is marked for sending
Store date/time that the message was marked for sending
Maintain priority queue of messages in the order they were marked for sending
Allow the spooler to "lock" a message once it starts handling it
The spooler is the only thing that can access a msg after its locked.
Until a message is locked, the AbortSend() function is internal to the store
After a message is locked, AbortSend() marks the message for abort.
Spooler Responsibilities
Poll message store(s) to locate a message which needs to be handled
Add recipients to Personal Address Book (if option selected)
Expand personal distribution lists.
Obtain Email-Address for each recipient identified only by its Address Book EntryID
Add message to local Sent Mail folder (if option selected with SentMail-ID property)
Poll transports to determine which transports handle which recipient types
Generate Undeliverable message for recipients that no transport will handle
Maintain status of which recipients have been handled
Retain transport-specific information about the user as requested by the transport
Perform character set translation as requested by the transport
Pass message data to the transport
Convert ATTACH_BY_REF_RESOLVE attachments into ATTACH_BY_VALUE.
Delete the message from the Message Store when complete (if specified)
Generate undeliverable messages as requested by the transport
Poll transports for incoming messages
Perform character set translation as requested by the transport
Accept message data coming from the transport
Store the message in the Message Store when complete
Transport Provider Responsibilities:
Identify which recipient types the transport can handle
Specify character set translation for the Spooler
Dialogs for selecting a server and entering credentials
Perform any login required by the message system
Translate message format as required by the message system
Inform Spooler when an incoming message needs to be handled
Pass incoming message data to the Spooler
Delete the message from the message system, as appropriate
Background Operations
Except for dialogs at initial transport login, the Spooler and transport providers operate in the background. The Spooler does its work and makes its calls to the transport providers when the foreground applications are idle. To reduce disturbance to foreground processing, the transport providers should repeatedly call back to the Spooler to release the CPU whenever they are performing long operations. Current wisdom is that the transport provider should break up any operation that takes more than .2 seconds.
Since network activity often takes more than .2 seconds, transport providers generally use asynchronous network requests. This allows them to initiate a request, release the CPU by calling back into the Spooler, and then when the Spooler again gives them control they check to see if their network request has completed. If it has not yet completed they again release the CPU by calling back into the Spooler.
| 