To illustrate the concepts, routing decisions, and the X.400 implementation, a reference topology will be used throughout this paper (Figure 1). The figure shows both the logical connections that comprise the X.400 address tree and the actual physical connections that are used for routing messages.

The topology is designed to provide a sample for complex routing configurations that might exist in an X.400 infrastructure. To demonstrate the relationships between the nodes of the X.400 address tree, the nodes are named using family references.

In the reference topology, an Exchange organization is integrated into a larger X.400 infrastructure. Exchange is authoritative for four nodes of the X.400 address tree: Reference, Sibling, Cousin, and Nephew. The area of authority for Exchange in the X.400 address tree is shown as the shaded area in Figure 1.

Figure 1   Reference topology

Note:

The area of authority for an Exchange organization can span multiple nodes of the X.400 address tree as can be seen in Figure 1. In a configuration like this, any Exchange mailbox can have an X.400 address in any of the nodes for which Exchange is authoritative, regardless of where it is physically located. For example, John Smith's mailbox that physically resides on a server in the Reference routing group can have the following X.400 address: c=US;a=Grandparent;p=Parent;o=Sibling;s=Smith;g=John

All examples and configurations in this paper provide routing decisions for an X.400 Message Transfer Agent (MTA) that is located in the Reference node. You can use this reference topology as a template when making configuration decisions for your own deployment topology. To configure X.400 settings for an MTA in your topology, match the connections that MTA has in your environment to the connections that the Reference node has in the reference topology. Then, configure those connections in the same way that the matching connections in the reference topology are configured. For example, your network configuration may require you to route messages addressed to a sub-domain through a domain that is higher up in the hierarchical X.400 address tree. In that case, you should configure an X.400 connector similar to the Reference-Parent connector shown in the reference topology that allows messages to be routed to the Indirect Child node.

Important:
You should not share an X.400 address space between your Exchange organization and an external system.

Return to top

When a server is processing a message, for each recipient, it must determine whether to deliver the message locally, route it, or stop delivery and generate a non-delivery report (NDR) for it. Delivering the message locally is a straightforward process: If there is a mailbox with a matching address, the server should deliver the message to that mailbox. Generating an NDR is also a simple process. If the server cannot deliver the message within the Exchange organization, or route it, it should generate an NDR. Routing the message is the complicated part of the process.

In section 14.3.11 of the X.411 recommendation, the X.400 committee recommends a routing algorithm to illustrate the issues that must be considered. The MTA code in Exchange is an exact implementation of this algorithm. The algorithm can be described as follows:

1. For each recipient on the message for which this MTA is responsible, attempt to deliver the message locally. If any of the recipients for which the MTA is responsible cannot be delivered locally, continue with steps 2 through 5 for each of those recipients.
   
2. Gather all available routes into the set of possibilities, called Set A.
   
3. Examine the trace and internal trace back to the last reroute operation and create a set of all domains and/or MTAs that exist in the trace and internal trace. Call that Set B.
   
4. Delete all members of Set B from Set A, and call the remaining list of possible routes Set C.
   
5. Execute the routing algorithm using only the routes from Set C. For any recipients for which the MTA is responsible and to which a valid route could not be found from the routes in Set C, generate an NDR.
   

Notice that this algorithm does not take the X.400 routing tree into account and may route a message in an undesirable manner. For example, assume that the MTA located in the Reference node in the reference topology (Figure 1) receives a message addressed to a non-existent node called Grandchild with the X.400 address of c=US;a=Grandparent;p=Parent;o=Reference;ou1=Child;ou2=Grandchild. Such a message needs to travel in the direction from root to leaf in the X.400 address tree. Because there are no known routes to the Grandchild node, the MTA fails to find the route that would lead to the destined leaf, and the algorithm would route the e-mail to the Parent node, toward the root. This situation could result in a message loop between the Parent node and the Reference node.

Each node in an X.400 address tree has a domain of authority, which can be determined from the logical addresses tree diagram. The concept of domain of authority can be characterized as the node’s shadow, and it consists of that node and all the other nodes that are hierarchically under it. A node must take authority for any messages addressed to recipients within its domain of authority.

In addition to the recommendations specified in the X.400 standards, Microsoft Exchange has another requirement. Exchange must be able to store multiple address spaces simultaneously, select the correct address for any particular situation, and operate for that address authoritatively. The mechanism for configuring the multiple address spaces is the recipient policy capability, which provides the potential for entering multiple independent address spaces for which an Exchange server should operate with authority.

The original implementation of X.400 routing in Exchange 2003 RTM has three issues that need to be addressed:

• Inability to Take Authority   When Exchange cannot locate a recipient in the Global Address List (GAL), the Exchange server may fail to determine whether the recipient is within its domain of authority. For example, if the recipient contains additional routable attributes and the routing engine does not find a match for those attributes in the connectors, the message is routed toward the root of the X.400 address tree. This action sometimes causes a message to loop through the system.
  Even when the message loop is detected and the message is eventually stopped by the system, it is still forced through arbitrarily long paths, exhausting all possible routes, consuming network and server bandwidth before the system can determine that the recipient had been incorrectly addressed.
  
• Inability to Detect an Incorrectly Addressed Message    Because Exchange uses SMTP as the primary message transfer protocol between routing groups and it deletes X.400 trace information during the conversion, it may fail to detect an incorrectly addressed message if that message is converted as it travels through the Exchange organization. Consider the reference topology shown in Figure 1. Assume that in addition to the connectors shown, there is a second X.400 connector configured between Parent and Sibling. This connector would have all the address spaces for which the Exchange organization is authoritative. When an Exchange server located in node Reference receives an incorrectly addressed message, it does not take decisive action, and routes the message toward the root of the address tree, the Parent node. At this point, the X.400 MTA at the Parent node chooses among the available routes that do not appear in the message trace, selects the alternate route from Parent to Sibling, and returns the message to the Exchange organization.
  The bridgehead at Sibling would also not take decisive action and then forward the message to the Reference for routing to Parent. The bridgehead at Reference will then find its own trace in the message, and the loop is terminated. This type of limited loop is undesirable, but may not be fatal.
  
• Inability to Detect Loops   With Exchange 2003 servers, the communication protocol between servers in the same routing group is SMTP, and in the conversion to SMTP, the message's internal trace (including the information that the message had ever encountered the bridgehead or the X.400 backbone) is lost. Therefore, if a message comes to the same bridgehead the second time, instead of being stopped, it is relayed to the X.400 backbone once more. Without the trace history, no server can detect the looping behavior, and the cycle repeats.
  In the example described above, if the message is converted to SMTP format in the process of routing from Sibling to Reference, it will lose the X.400 trace. At this point, the bridgehead at Reference will be unable to find its own trace in the message and will route it back to Parent. The MTA at Parent will also not find its own trace in the message and it will treat it as a brand new message, routing to the Sibling node, thereby creating the message loop.
  There are several scenarios in which Exchange 2003 partially or totally deletes the message history contained in the trace and internal trace:
  
  • Relaying a NDR through the server
    
  • Relaying any message through SMTP intra-organization links (that is, SMTP links within the Exchange messaging organization)
    
  • Rerouting a message
    
  • Expanding a distribution list
    
  • Redirecting to an Originator-Requested Alternate Recipient
    
  • Redirecting to a Recipient-Specified Alternate Recipient
    

Return to top

The updated algorithm performs an additional three-way comparison between the domains for which Exchange is authoritative (addresses configured in recipient policies), the routes determined by the routing engine, and the recipient address. The best matching address is the one that matches the greatest number of X.400 routable attributes of the recipient address. This three-way comparison process is known as N-match calculation.

For each recipient address on a message, the updated algorithm applies the following steps:

1. Look up the recipient address in the GAL. If the address is found, deliver the message and stop. Otherwise, continue to step 2.
   
2. Run the recipient address through the routing engine, and save the result.
   
3. Remove the personal-name attributes (S/G/I/Q/CN/DDA) from the recipient address. If there are no personal-name attributes, subtract the last OU attribute. For example, the following two recipient addresses
   C=US; a=fabrikam; p=contoso; o=marketing; ou1=sales
   and
   C=US; a=fabrikam; p=contoso; o=marketing; cn=westcoast
   both become
   C=US; a=fabrikam; p=contoso; o=marketing
   
4. Examine the addresses configured in all recipient policies to find the best match for the output from step 3.
   
   1. If a perfect match is found, the recipient address is within the domain of authority of the Exchange organization, but the recipient does not exist in the GAL. Stop message processing, and generate an NDR.
      
   2. If the recipient policy that is the best match is a perfect substring of the address, the recipient is leafward (the recipient is in a sub-domain of one of the domains for which Exchange is authoritative); the recipient is outside the Exchange organization, and the Exchange organization is closer to the recipient than the root node. Save the match, and continue to step 5.
      Otherwise, continue to step 4c.
      
   3. The recipient is rootward; the recipient is outside the Exchange organization, and the root node is closer to the recipient than the Exchange organization. Route the message according to the routing engine's output. Routing is now complete.
      
5. Compare the routing engine's output to the result from 4b.
   
   1. If the routing engine's output is a perfect substring (rootward) or a perfect match, it means that, although the Exchange organization is closer to the recipient than the root node, the routing engine did not produce any routes that are better matches than the route to the root node. Stop the message, and generate an NDR.
      Otherwise, continue to step 5b.
      
   2. There is a connector to the leafward node. Route the message according to the routing engine's output.
      

In the algorithm that was used in Exchange 2003 RTM, if the recipient address is not found in the GAL and is a full match to the address specified in the default recipient policy (DRP), Exchange generates an NDR. Otherwise, it would route the message.

In the updated algorithm in Exchange 2003 6.5.7653, if the recipient address is not found in the GAL and the recipient address completely matches the address space configured in any of the recipient policies, Exchange generates an NDR. Otherwise, it first ascertains whether the output of the routing engine would take the message closer to the destination, given the address spaces for which Exchange is authoritative. If the output of the routing engine is equal to or further from an address space configured in the recipient policies, Exchange generates an NDR. Otherwise, it routes the message.

In the example given in "Routing Algorithm Implemented in Exchange 2003 RTM" earlier, the updated algorithm will actually generate an NDR for the message instead of routing it back to Parent. This action occurs because the route to Parent does not take the message closer to its destination. Because of the updated algorithm, Exchange is able to determine this fact and take decisive action.

Return to top

A recipient policy serves as a rule for creating the e-mail addresses within an Exchange organization. In the context of X.400 routing, it also defines the X.400 domains for which the Exchange organization is authoritative. Every Exchange organization has a default recipient policy with an X.400 address space. If the Exchange organization is authoritative for more than one domain (for example, multiple nodes in an X.400 address tree), custom recipient policies are used to define the additional address spaces that correspond to the additional domains. All recipient policies apply to the entire Exchange organization. Use the diagram of your logical address tree when you configure the recipient policies for your Exchange organization.

Important:
The default recipient policy is used when determining the domains of authority only when no custom recipient policies are defined in the organization. If custom recipient policies are present, they are used for determining the domains of authority and the default recipient policy is ignored.

As previously stated, each domain or node for which the Exchange organization is authoritative should have a recipient policy with the address space of the node. The recipient policies that apply to the reference topology are listed in Table 1.

Table 1   Recipient policies for the reference topology shown in Figure 1

To configure a recipient policy, access the X.400 Address Properties dialog box by clicking the E-mail Addresses tab of the recipient policy properties. Fill in the appropriate value for each attribute using Table 1. Figure 2 shows the X.400 Address Properties dialog box for the recipient policy that defines the address space of the Nephew node.

Figure 2   X.400 configuration for a recipient policy

You must configure recipient policies for all the X.400 domains listed in Table 2.

When you create a new recipient policy, you will have a choice whether to apply the policy. If you select Apply, a new X.400 address will be generated for all mailboxes in the entire Exchange organization. You should ensure that you configure a recipient filter to specify the mailboxes for the recipient policy before you apply it.

Note:
There are additional steps required for creating a recipient policy. For step by step instructions about creating a recipient policy, see Creating a Recipient Policy.

A connector is a component that enables the transfer of a message between two nodes. The address space configuration on an X.400 connector is used to determine which messages can be routed through that connector. You can configure one or more address spaces for each connector.

Note:
A connector is a valid path for the address space and all of the sub-domains of that address space. You do not need to configure each sub-domain explicitly. For example, a connector with the address space c=US;a=Fabrikam is a valid path for recipients in c=US;a=Fabrikam;p=Contoso.

Message transfer that is completely internal to an Exchange organization is typically handled using the routing group connectors. However, the routing group connectors use SMTP for message transfer and, during the conversion, the trace information of X.400 messages is lost, which could result in message loops. Therefore, f your Exchange organization is participating in an X.400 infrastructure, you should use X.400 connectors to connect routing groups instead of the standard routing group connectors. For more information about connecting routing groups using X.400 connectors, see Connecting Routing Groups Using X.400 Connectors. 

Important:

You do not need to configure address spaces for the X.400 connectors that connect routing groups. All recipients in all routing groups are known to all Exchange servers. Therefore, if a recipient exists in the Exchange organization, all Exchange servers in the organization can deliver the message to that recipient. Exchange does not use the routing engine when delivering to a recipient inside the Exchange organization.

Each connector represents a path for message travel. You must design your connectors with the X.400 address tree in mind, and create a functional routing configuration with distinct paths toward the root, the leaves, or peer nodes in the routing tree.

Multiple address spaces may be configured for each connector, and multiple connectors may be created between any two nodes. Each additional configuration introduces complexity to the X.400 routing design and should be carefully planned. The address spaces configured on a connector must match the address spaces for which the target node is authoritative. The majority of your connectors should have only a single address space.

Use the diagram of your network infrastructure together with the X.400 address tree when configuring the connectors for your Exchange organization.

Note:
Before you can create an X.400 connector, you must create an X.400 protocol stack for each server that will be an X.400 bridgehead. For more information about creating X.400 protocol stacks, see How to Create an X.400 Protocol Stack.

Table 2 lists all the X.400 connectors required for the Exchange organization in the reference topology shown in Figure 1. 

Note:
The configurations of the connectors that are completely external to the Exchange organization are outside the scope of this paper. Those connectors are included in the diagram to provide an overall view of the X.400 address tree for the reference topology shown in Figure 1.

Table 2   Connector configurations for the reference topology

Table 2 shows the address spaces that are required on each X.400 connector. Because the node Reference is the bridgehead for the Exchange organization, it should have the c=* address space configured. This configuration ensures that any message that is addressed to a recipient that is outside the area of authority of Exchange is routed to the root of the X.400 address tree. In the reference topology, the Reference-Parent connector also requires a second address space to ensure that any messages addressed to Unknown Child are routed through Parent. If this additional address space is not configured on that connector, the routing algorithm will generate NDRs for any message addressed to Unknown Child. 

Note:
All the connectors in the reference topology are configured with unique address spaces. It is important to avoid configuring identical address spaces for multiple connectors to achieve predictable and reliable routing.

To configure the address space on an X.400 connector, access the X.400 Address Space Properties dialog box by clicking the Address Space tab of the X.400 connector properties. Fill in the appropriate value for each attribute using Table 2. Figure 3 shows the X.400 Address Space Properties dialog box for the X.400 connector from Reference to Child.

Figure 3   Address space configuration for an X.400 connector

Note:
There are additional steps required for creating an X.400 connector. For step by step instructions about creating an X.400 connector, see Creating an X.400 Connector.

Note:
Microsoft does not recommend using costs to force routing decisions unless there are actual physical cost or bandwidth considerations.

The routing group connectors do not require address space configuration. For detailed information about configuring routing group connectors, see How to Configure the Options for a Routing Group.

Return to top