|< Day Day Up >|| |
The SMTP-based message transport uses several different components to ensure reliable and efficient message delivery. Perhaps the best way to explain these components is to examine the flow of a typical message, as shown in Figure 6.1.
Figure 6.1: Message flow
The message flow steps vary depending on the source of the message. Outbound messages submitted by MAPI clients are initially handled differently than inbound messages and messages submitted by Internet clients. Once the initial processing is completed and the messages are passed to the Advanced Queuing Engine, all messages are handled in the same manner. The message flow is described in the following sections.
The MAPI client submits the message directly to the Exchange Information Store.
The Information Store moves the message to the SendQ folder.
The Store Driver (Store) reads the message from the SendQ folder and constructs an IMAILMSG envelope. The Store Driver (Store) allows the transport to directly read and write files from the Exchange Information Store. Normally, SMTP components pass information using folders located in the \Exchsrvr\Mailroot directory. The Store Driver (Store) prevents the transport from having to copy the submitted message from the Information Store to a folder in the Mailroot directory.
The Store Driver (Store) passes the IMAILMSG envelope and message to the Advanced Queueing Engine.
The remaining message flow steps are described in Section 6.2.3.
When a message arrives, the Internet Information Server (IIS) SMTP service accepts the message and creates an IMAILMSG envelope for it.
The IIS SMTP service puts the IMAILMSG envelope and message into the Queue folder. The Queue folder is in the \Exchsrvr\Mailroot directory. (Other commonly used SMTP folders, such as Badmail, Drop, and Pickup, are also located in this directory.)
The Store Driver (IIS) passes the IMAILMSG envelope and message to the Advanced Queuing Engine.
The remaining message flow steps are described in the next section.
Regardless of how a message enters the system, at some point it is passed to the Advanced Queuing Engine. The Advanced Queuing Engine is the heart of the Exchange transport and all messages are processed by it. This is a change from Exchange 5.5 where 'local' messages (i.e., messages where the sender and recipient are on the same system) were handled entirely by the Information Store without involving the message transport. This change to handle all messages in the same manner allows custom event sinks to be used on all messages, including local messages.
The Advanced Queuing Engine sends the message to the Message Categorizer by adding it to the Message Categorizer's work queue.
In general, the task of the Message Categorizer is to examine the message and queue it for delivery on the basis of certain message attributes. The specific tasks include the following:
The Message Categorizer parses the sender name and asks the directory service to look up the sender's address.
If the envelope recipient list includes distribution groups, the Message Categorizer expands the distribution groups to identify the individual recipients.
The Message Categorizer parses the recipient names and asks the directory service to look up the recipient addresses. Any unresolved recipients are marked as unknown.
It applies the delivery restrictions and other limits for the sender and for each recipient.
If required, the Message Categorizer creates multiple copies of the message. This is generally done for two reasons:
Messages destined for Internet users are formatted differently from messages destined for Exchange users. If the message recipients include Internet and Exchange users, the Message Categorizer creates two copies: one for the Exchange users and one for the Internet users.
There are conflicting properties for different recipients, such as when a message contains both a read receipt request and a hidden group. Read receipts should not be generated for the members of the hidden group, because their membership must remain confidential. The Message Categorizer creates two copies of the message: one copy without read receipt requests for the hidden recipients and one copy with read receipt requests for the other recipients.
The Message Categorizer determines where each copy of the message is to be delivered (e.g., local delivery or sent to another system).
It then returns the message to the Advanced Queuing Engine.
The Advanced Queuing Engine sends the message to the Routing Engine by adding it to the Routing Engine's work queue.
The Routing Engine uses information about connectors, costs, and link states to determine the next system to which the message should be transferred. A cost is associated with each connector between two routing groups. When there are multiple possible routes between two systems, the cost is used to determine the preferred (i.e., lower cost) route. The routing topology and connector costs are made available to all Exchange servers in the organization.
With Exchange 5.5, one server in each Exchange site was responsible for collecting the routing topology information, calculating the costs, creating a Gateway Address Resolution Table, and relaying this information to other Exchange servers in the site. However, Exchange 5.5 had no mechanism for communicating the status of connections. Each server only knew the status of connections to adjacent systems and had no status information on other network connections. Consequently, a message may start on a multi-hop journey to its destination only to find that one of the downstream network connections has failed. This is known as direct vector routing.
Exchange 2003 continues to use routing topology and connector costs, but now uses a Link State Algorithm based on a Dijkstra algorithm that is a well-known, well-accepted method of finding least cost. This algorithm, also known as Open Shortest Path First, prevents looping and incorporates dynamic rerouting. Many network router vendors use Open Shortest Path First in their products for routing network packets. The Link State Algorithm communicates near real-time information about connector status between routing groups within the Exchange organization. Because all servers know the status of all connections, the originating Exchange server can make an intelligent routing choice rather than starting a message on a multi-hop journey only to find that one of the downstream network connections has failed.
One server in each Exchange Routing Group is responsible for collecting link state information and the routing topology information: the routing group master. The routing group master collects and relays this information to other Exchange servers in the Routing Group, including the Routing Group's bridgehead servers. The bridgehead servers relay the link state information to bridgehead servers in other routing groups, which then send the information to their local routing group master. Within a Routing Group, link state information is communicated using TCP port 691. Between groups, the information is communicated using SMTP.
The first server installed in a routing group automatically becomes the master, but this designation can be changed manually.
Each link has one of two states: up or down. When a bridgehead server detects that a link is unavailable, it marks that connector as down and sends the data to the routing group master. The master immediately sends the change to the other servers in the routing group and forwards the information to other routing groups.
Connector and cost information is kept in the Active Directory, but link state information is only kept in the memory of each Exchange server. If one of the servers fails, the remaining servers continue to redistribute the link state information.
Once the Routing Engine determines the next hop, it then returns the message to the Advanced Queuing Engine.
Once the next hop for each copy of the message is determined, the message is queued for delivery.
If the message is for local delivery (i.e., the recipient's mailbox is in the local Information Store), it is placed in the local delivery queue. The Store Driver (Store) takes the message from the local queue and delivers it to the Information Store.
If the message is destined for another system, it is queued for delivery to the domain of the next hop. The SMTP server takes the message from the queue and forwards it to the appropriate system.
|< Day Day Up >|| |