Exchange Server 2003 Message Handling

Message transfer in Exchange 2003 is primarily the task of the SMTP service. Note that the Exchange 2003 SMTP transport engine is involved in all message handling, regardless of the final destination of the message. A message might be destined to a user on the same server, another server in the same routing group, a server in another routing group, or a server in an external messaging system. The following figure shows the SMTP transport architecture of Exchange Server 2003. For detailed information about the components in the SMTP transport engine and their responsibilities, see SMTP Transport Architecture.

The Exchange Server 2003 transport architecture

In Exchange Server 2003, the SMTP transport engine handles messages as follows:

1. A message is received through SMTP, remote procedure calls (RPCs), X.400, or MAPI transfer protocols, as outlined in the following table.

   Incoming message transfer protocols

   Transfer Protocol	Comments
   SMTP	Exchange 2000 and Exchange Server 2003 servers communicate with each other through SMTP. Non-Exchange hosts and POP3 and IMAP4 clients also use SMTP to transfer messages to a server running Exchange Server 2003. These messages are received through the SMTP protocol service, which saves them in the \Exchsrvr\Mailroot\vsi 1\Queue folder on the file system before transferring them to the pre-submission queue. Each virtual SMTP server on an Exchange 2003 server maintains its own subdirectory under the Exchsrvr\Mailroot\ folder. For example, the path of the default virtual SMTP server's mailroot folder is \Exchsrvr\Mailroot\vsi 1. Another way to submit messages to the SMTP service is to use the \Pickup subdirectory under the virtual SMTP server's mailroot folder. Because the message file must be in RFC-822 format for the SMTP service to obtain and successfully process the message, this message transfer is also considered to be SMTP-based.
   RPCs	Exchange 5.5 servers communicate with each other in the local site through RPCs. Exchange 5.5 message transfer agents (MTAs) use RPCs to transfer e-mail messages to each other in the local site, without requiring a definition of a messaging connector. If Exchange Server 2003 is deployed in an existing Exchange 5.5 site, messages are exchanged with Exchange 5.5 through RPCs using the Microsoft Exchange MTA Stacks service. When using a site connector, Exchange 5.5 servers in different sites also communicate with each other using RPCs. Exchange 2003 can communicate with a site connector if you deploy a routing group connector that connects to an Exchange 5.5 server in a remote site. In this case, the routing group connector automatically switches to RPCs, instead of SMTP, for backward compatibility with Exchange 5.5.
   X.400	If you want to exchange messages with a remote X.400 message transfer agent (MTA), an X.400 connector must be configured. As mentioned earlier, you can also use X.400 connectors to connect routing groups to each other in your Exchange organization. The Microsoft Exchange MTA Stacks service receives incoming X.400 messages and passes them to the Exchange store. The Exchange store driver then places the messages in the pre-submission queue. For more information about X.400 architecture, see X.400 Transport Architecture.
   MAPI	MAPI-based clients, such as Microsoft Outlook, in addition to MAPI-based messaging connectors, such as Connector for Lotus Notes and Connector for Novell GroupWise, communicate directly with the Exchange store. For example, MAPI-clients put outgoing messages in the Outbox folder of the user's mailbox and then notify the Exchange store to transfer the message. However, MAPI-based messaging connectors use an MTS-IN folder in the Exchange store as their incoming message queue. MAPI-based messaging connectors convert inbound messages into Exchange format and then place them in the MTS-IN folder. Either way, the MAPI message is put in the Exchange store, and the Exchange store driver then puts the message in the pre-submission queue. For more information about MAPI-based messaging connectors, see Gateway Messaging Connectors Architecture.

2. The pre-submission queue is the entry point in the advanced queuing engine. When a message is put into the pre-submission queue, custom SMTP processing code, such as event sinks for antivirus screening, processes the message. The advanced queuing engine then moves the message to the pre-categorization queue, so that the categorizer, an internal component of the SMTP transport engine, can process it further.

3. The categorizer resolves both recipient and sender addresses, expands any mail-enabled groups, checks restrictions, applies per-sender and per-recipient limits, and more. If the recipient's mailbox resides in the local Exchange Server 2003 organization, the categorizer marks the recipient as local by setting a per-recipient property indicating the fully qualified domain name (FQDN) of the recipient's home server. This is an important routing step. Later, the advanced queuing engine uses the recipient's home server FQDN to determine the message transfer path.

4. After categorization, the advanced queuing engine puts the message in the post-categorization queue. Now, a distinction must be made between messages for local recipients and messages for recipients on remote systems, as follows:

   • Local delivery   For local recipients, routing is skipped. The mailbox store that holds the target mailbox is stamped on the message and the advanced queuing engine transfers the message to the Local Delivery queue. From the Local Delivery queue, the Exchange store driver obtains the message and puts it in the mailbox of the recipient.

   • Remote delivery   The routing engine must process all messages to non-local recipients, because the SMTP transport engine must find an available transfer path for the destination. Correspondingly, the advanced queuing engine transfers the message to the pre-routing queue, calls the routing engine, and then passes the destination address (that is, the FQDN of the recipient's home server for internal recipients or the SMTP domain name for external recipients) to the routing engine. The routing engine returns the next hop that the message will use to the caller and classifies the next hop, as listed in the following table.

     Hop types for remote delivery

     Hop Type	Comments
     The next hop is to the local server	This indicates that the transport engine must pass the message to the Exchange MTA for transfer, either through RPCs to an Exchange 5.5 server in the local routing group, through an X.400 connector to a remote X.400 MTA, or through a MAPI-based messaging connector, such as Connector for Lotus Notes or Connector for Novell GroupWise, to a non-Exchange messaging system.
     The next hop is to a server in the local routing group	This indicates that the transport engine must pass the message to the default virtual SMTP server for transfer to the destination over SMTP.
     The next hop is to a server in a remote routing group	This indicates that the transport engine must pass the message to a routing group connector on the local Exchange server. It must be noted, however, that this type applies only to messages transferred over SMTP. If you use X.400 connectors to connect routing groups, the transport engine passes the messages to the Exchange MTA (that is, the next hop is to the local server).
     The next hop is to a server outside the Exchange organization	This indicates that the transport engine must pass the message to an SMTP connector or virtual SMTP server that can transfer the message to the external messaging system. Again, this hop type only refers to destinations reachable through SMTP. If the message is destined to a non-Exchange messaging system connected through a MAPI-based connector that is controlled by the Exchange MTA, the transport engine passes the messages to the Exchange MTA (that is, the next hop is to the local server).
     The next hop is to a server that is currently unreachable	This indicates that a destination path exists, but that this path is currently unavailable. The transport engine retains the message until the transfer path is available again or until the message expires and must be returned to the sender with an NDR.
     The next hop is to a server that is unreachable	This indicates that no final destination path exists, and the transport engine returns the message to the sender with an NDR.

5. The advanced queuing engine caches the next hop type information and destination, and moves the message to a corresponding link queue. Link queues are dynamic and are managed by Queue Manager. The name of each link queue matches its remote delivery destination.

   Note

   Link queues exist and are available in the Queue viewer of Exchange System Manager only when messages are waiting for transfer to the corresponding destination. Queue Manager expires a link queue about a minute after the last message in the link queue is transmitted.

6. Messages in link queues other than the Exchange MTA queue are transferred using the SMTP protocol engine. However, messages in the Exchange MTA queue are transferred to the Exchange MTA outbound message queue in the Exchange store, which is a system folder named MTS-OUT. The Exchange store driver performs this task. The Exchange MTA obtains the message and then communicates with the routing engine through MTARoute.dll to determine the appropriate and available connector. If the message is for a connector to a non-Exchange messaging system, the Exchange MTA places the message in that connector's outbound message queue in the Exchange store (the connector's MTS-OUT folder). Otherwise, the MTA transfers the message directly using RPCs or an X.400 connector. For more information about the Exchange MTA, see X.400 Transport Architecture.