Connecting Routing Groups Using X.400 Connectors

It might be a good idea to use X.400 connectors between routing groups, particularly over unreliable network links. X.400 is advantageous because it supports graceful recovery of transfer associations. In many situations, message transfer can be resumed from the interruption point. Also, the X.400 connector does not inflate message size, because it transfers message content in native Exchange format without conversions. In contrast, routing group connectors and SMTP connectors must convert messages to RFC 822 and Multipurpose Internet Mail Extensions (MIME) format. This causes a 30 percent size increase. To specify remote routing groups for an X.400 connector, in the connector properties, use the Connected Routing Groups tab.

Load Balancing between Routing Groups

The local and remote MTAs of an X.400 connector are the only bridgehead servers that the connector can use in each routing group. If you want multiple bridgehead servers, you must configure additional X.400 connectors to point to different remote MTAs in the target routing group. A single server can support multiple X.400 connectors, each using the same or different MTA transport stacks. However, you can also configure multiple X.400 connectors on multiple servers, as illustrated in the following figure.

Multiple bridgehead servers and X.400 connectors between two routing groups

Note, however, that Exchange Server 2003 does not perform true load balancing over multiple connector instances. As explained in Message Routing Architecture, the advanced queuing engine calls the routing engine to determine a message route one time, caches this information, and then transfers all messages of the same type over the same connector. Additional connectors are used only if the first connector fails. However, a second server might select the second connector and in this way balance the load to some degree.

Message Routing over Exchange MTAs

In an Exchange organization in which messages are transferred through Exchange MTAs, message routing is performed twice by the routing engine. The first routing event occurs in the advanced queuing engine. The routing engine informs the advanced queuing engine that a message must be routed through a connection controller by the Exchange MTA, and the advanced queuing engine places the message in the message queue for the MTA. The Exchange store driver places the message in the MTS-IN folder for the MTA in the Exchange store. The Exchange store then passes the message to the MTA, using an SMTP XAPI gateway. The following event example shows a message passed to the MTA as just described. The relevant information is in boldface.

Event ID: 272

Source: MSExchangeMTA

Type: Information

Category: X.400 Service

Object 0600002D received from entity /DC=COM/DC=CONTOSO/CN=CONFIGURATION/CN=SERVICES/CN=MICROSOFT EXCHANGE/CN=FIRST ORGANIZATION/CN=CONNECTIONS/CN= , object is a Normal priority Message, the MTS identifier is C=US;A= ;P=First Organizati;L=SERVER01-040503155933Z-4, and content length is 1719. The number of objects sent so far = 1. External trace information (first 100 bytes) = 3080638061801302555300006280130120000013104669727374204F7267616E697A61746900003180800D3034303530333136303234315A8201008302060000000000. (10)

SMTP XAPI Gateway

From an Exchange MTA viewpoint, the SMTP service performs similar to a MAPI-based connector, such as Connector for Lotus Notes or Connector for Novell GroupWise. The Exchange MTA obtains messages from the SMTP XAPI gateway through the gateway's MTS-IN folder and routes messages to this gateway through the gateway's MTS-OUT folder. These message queue folders exist in the SMTP mailbox. The name of the SMTP mailbox is SMTP (<server name> - {<GUID of the mailbox store>}). In the event above, the mailbox name is SMTP (SERVER01-{43D5C017-4A4B-4AFD-85AF-06EAB90057AA}). A corresponding connector object for the XAPI gateway exists in Active Directory in the Connections container, directly under the Exchange organization object. This container is not displayed in Exchange System Manager, but you can view it using ADSI Edit or export its contents using LDIFDE. For example, you can use the following command line to export all SMTP XAPI gateway objects into a file called SMTPXAPI.ldf: ldifde -f c:\SMTPXAPI.ldf -s localhost -d "CN=Connections,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com" -r "(objectClass=mailGateway)".

The following table describes the important attributes of the SMTP XAPI gateway object.

Important SMTP XAPI gateway attributes

Exchange MTA Message Transfer

The following figure illustrates how the SMTP service and the Exchange MTA interact with each other.

Message transfer through the Exchange MTA

After receiving a message from the SMTP XAPI gateway, the MTA must determine a suitable connector to transfer the message to the next hop. In Exchange 2000 Server and Exchange Server 2003, the MTA no longer performs actual message routing, but contacts the routing engine through MTARoute.dll, which then routes the message. However, the MTA might change the O/R recipient names to a form that can pass to the routing engine.

The MTA does not call the routing engine for messages it receives from LAN-MTAs, X.400 MTAs, or MAPI connectors. It passes these messages straight to the MTS-OUT folder of the SMTP XAPI gateway. The advanced queuing engine, in turn, then handles the messages and calls the routing engine if a message is not directed to local recipients. In fact, a message might transfer back to the Exchange MTA through the Exchange store and SMTP XAPI gateway, if it must transfer to another LAN-MTA, X.400 MTA, or non-Exchange messaging system. The SMTP service sets a flag on all messages that it transfers to the Exchange MTA, to indicate that the MTA should call the routing engine. For detailed information about the message routing process, see Message Routing Architecture.

If the routing engine can determine a next hop for a message, the MTA determines whether the next hop is reached through the local SMTP service. It is possible, for example, that an X.400 connector and a routing group connector both point to the same routing group. If this occurs, the advanced queuing engine might pass the message to the MTA for transfer over the X.400 connector, and the MTA might then pass the message back to the SMTP service for transfer over the routing group connector, and so forth. To avoid this situation, the MTA calls the routing engine a second time if the initial routing suggests that the MTA should send the message back to the SMTP service. The MTA passes the recipient's X.400 proxy address in the initial routing call and the legacyExchangeDN in the second routing call, with the expectation that this will yield a different route than the route through the SMTP service.

Link State Information and Message Rerouting

If the routing engine can determine a next hop for a message, it returns the routing object name of a connector or MTA back to the MTA. The MTA converts this routing object name to a distinguished name to determine the connector or MTA directory object that the MTA must use for message transfer in Active Directory. The directory object defines the delivery mechanism and communication parameters.

If the routing engine cannot determine a next hop due to a temporary link failure, the routing engine flags the message to inform the MTA that it must reroute the message the next time link state information changes. As explained in Message Routing Architecture, link state information changes when you change the connector configuration in your organization or when the advanced queuing engine or MTA marks a connector as down or up. The link state algorithm ensures that updates to link state information are propagated to all servers in the organization that are running Exchange Server 2003.

When the routing engine on the local server discovers that link state information is changed, it calls the RoutingReset() function of the MTA. The MTA then calls the routing engine on all messages that are routed but not yet sent, to perform rerouting. Until the routing engine receives updated link state information from its routing group master, routing calls result in a temporary error, and the MTA places the messages in a Pending Reroute queue. The rerouting succeeds when the link state information is synchronized across the entire routing group.

Exchanging Link State Information Between Routing Groups

In an Exchange organization with routing group connectors, link state information is exchanged between routing groups using SMTP. If X.400 connectors are deployed to connect routing groups, then link state information must be exchanged over X.400 also. To accomplish this task, the Exchange MTA calls the routing engine to obtain the current MD5 digest, which is an encrypted signature that represents the version number for the link state table. Based on this information, routing engines determine whether they have the same link state information.

Before sending messages, the local MTA sends the GUID attribute of the Exchange organization and the current MD5 digest in a DIGEST_QUERY packet to the remote MTA. When the remote MTA recognizes the DIGEST_QUERY packet, it passes the information to its routing engine. The routing engine compares the digest with its own digest copy, and passes the comparison results back to its MTA. The remote MTA then sends the response back to the local MTA.

An example of a digest query and a query response

If the MD5 digests on the servers running Exchange Server differ, then a more detailed conversation follows between the MTAs to exchange OrgInfo packets. The OrgInfo packet contains the link state table, with all details and states of the routing topology. The MTAs pass the OrgInfo packets to their local routing engines, and the routing engines determine which server has the most up-to-date information. The server with the most up-to-date information discards the received OrgInfo packet. The other server passes the updated link state information to its routing group master, and the routing group master updates the link state information on all servers in its local routing group.

Exchange MTAs transfer digest queries even if they connect to MTAs outside the local Exchange organization. The receiving routing engine checks the organization GUID in the DIGEST_QUERY packet to determine if the link state information is from the local organization and ignores the MD5 digest if it is from a different organization. The query response indicates that no OrgInfo packets must be exchanged.