White Paper: Integrating Exchange 2003 in a Complex X.400 Infrastructure


上一次修改主题: 2008-01-28

Mark DeCoursey, Software Design Engineer and Serdar Soysal, Senior Technical Writer, Microsoft Corporation

February 2008

The release to manufacturing (RTM) version of Microsoft Exchange Server 2003 may not be able to take authority over messages or detect message loops when it is part of a complex X.400 infrastructure. The X.400 routing implementation has been updated in Exchange Server 2003 version 6.5.7653. The updated implementation performs additional checks when routing an X.400 message and provides more reliable routing.

This paper provides an overview of the X.400 routing implementation in Exchange 2003, outlines the issues with the Exchange 2003 RTM implementation, and explains the improvements in Exchange 2003 6.5.7653. It also includes instructions on how to configure recipient policies and X.400 connectors to ensure correct X.400 mail flow.

To print this white paper, click Printer Friendly Version in your Web browser.

Exchange Server 2003 can be seamlessly integrated into the messaging infrastructure of an organization that has an X.400 messaging architecture. However, the more complex the X.400 system, the more care needs to be taken when configuring Exchange to ensure reliable message routing.

In certain configurations, a message cannot be delivered and enters an endless loop, traversing the same path repeatedly. This situation can result in significant system performance degradation or even complete system failure. In the X.400 routing implementation of the release to manufacturing (RTM) version of Exchange Server 2003, there exists a possibility of message loops under certain complex routing topologies. The X.400 routing algorithm has been improved in version 6.5.7653 to prevent message loop conditions. The changes make the routing and handling of messages more reliable, but the new implementation is also less tolerant of mistakes in routing topology design.

The purpose of this document is to:

  • Explain the updated implementation
  • Explain proper X.400 routing configuration
  • Provide information to help you make optimum design decisions for X.400 routing

This section explains the issues with the implementation of X.400 routing in Exchange 2003 RTM and how Exchange 2003 6.5.7653 addresses these issues.

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.

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.

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


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


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
    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.


This section explains the configurations that are required for X.400 routing in an Exchange organization that is part of a larger X.400 infrastructure. Recipient policies and connectors must be configured correctly to ensure reliable X.400 routing. You can use Exchange System Manager to configure both recipient policies and connectors.

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.

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

X.400 Node (domain) X.400 Address space for the recipient policy









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.


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.

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.

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.

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.

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.

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

Configured in routing group Link Address space










<None (Connects Exchange routing groups)>



<None (Connects Exchange routing groups)>






<None (Connects Exchange routing groups)>



<None (Connects Exchange routing groups)>



<None (Connects Exchange routing groups)>



<None (Connects Exchange routing groups)>



<None (Connects Exchange routing groups)>






<None (Connects Exchange routing groups)>

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.

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.

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.
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.


This section outlines how the updated X.400 implementation on a server located in the Reference node processes messages addressed to various nodes in the reference topology shown in Figure 1. Table 3 lists the actions the X.400 routing algorithm takes based on the domain to which the message is addressed.

Table 3   Actions taken on a message that is received at the Reference node in the reference topology

Domain that contains the recipient address Action taken


Deliver it locally.


The recipient is in the Exchange organization, so it will be delivered within the Exchange organization.

X.400 processing stops. The message is routed to the Sibling node using the Reference-Sibling connector.


The recipient is in the Exchange organization, so it will be delivered within the Exchange organization.

X.400 processing stops. The message is routed to the Cousin node using the Reference-Cousin connector.


The recipient is in the Exchange organization, so it will be delivered within the Exchange organization.

X.400 processing stops. The message is routed first to the Sibling node using the Reference-Sibling connector and then to the Nephew node using the Sibling-Nephew connector.


The recipient is external to the Exchange organization. The X.400 routing algorithm is executed, and there are two possible paths:

  • Reference-Parent X.400 connector (N-match value of 1)
  • Reference-Child X.400 connector (N-match value of 5)

Because the X.400 connector to the Child has the higher N-match value, the message is routed using that X.400 connector.

Grand Nephew

The recipient is external to the Exchange organization. The X.400 routing algorithm is executed, and there are two possible paths:

  • Reference-Parent X.400 connector (N-match value of 1)
  • Nephew-Grand Nephew X.400 connector (N-match value of 6)

Because the X.400 connector to the Grand Nephew has the higher N-match value, the message is routed using that X.400 connector.

Unknown Nephew

The recipient is external to the Exchange organization. The X.400 routing algorithm is executed, and there are two possible paths:

  • Reference-Parent X.400 connector (N-match value of 1)
  • Sibling-Unknown Nephew X.400 connector (N-match value of 5)

Because the X.400 connector to the Unknown Nephew has the higher N-match value, the message is routed using that X.400 connector.

Indirect Child

The recipient is external to the Exchange organization. The X.400 routing algorithm is executed, and there is one possible path:

  • Reference-Parent X.400 connector (N-match value of 5)

The message is routed to the Parent node using the Reference-Parent X.400 connector.

Unknown Sibling





Any other nodes in the global X.400 address space

Any message that is addressed to a recipient in any of these domains must travel towards the root. The X.400 routing algorithm is executed, and there is one possible path:

  • Reference-Parent X.400 connector (N-match value of 1)

The message is routed to the Parent node using the Reference-Parent X.400 connector.

All message loops in an X.400 infrastructure can be avoided by adhering to the following simple rule: The address space on a connector must match the address space for which the target MTA is responsible. All recipient policy and connector configurations in an Exchange organization must conform to this rule to avoid potential problems.

In the updated X.400 routing implementation that is in Exchange 2003 6.5.7653, Exchange performs additional checks before routing a message. If the recipient is within its domains of authority, it will either deliver the message or generate an NDR for it. If the recipient is outside Exchange domains of authority, Exchange determines if the output of the routing engine would bring the message closer to its destination. If the output of the routing engine takes the message further away from its destination, Exchange does not route the message and generates an NDR instead. These changes provide a more robust X.400 routing implementation for Exchange 2003.


This section provides key concepts of the X.400 Standard.

The X.400 standard views the global address space as a set of major domains. The word "domain" in the X.400 context means "a realm or range of responsibility" or "the territory governed by a single entity".

The major domain types are:

  • National domain   Modeled after the global postal system, the architects of X.400 assigned the first level of domains to the nations or countries.
  • Administration domain   Each national domain may be divided into one or more Administration Management Domains (ADMD), equivalent to the national telephone networks, of which there may be more than one.
  • Private domain   Each administration domain may be further subdivided into Private Management Domains (PRMD). Private companies and organizations can be registered as PRMDs within an ADMD.

The difference between the ADMD and PRMD is that the ADMD is viewed as a public service subscribing to national policies, whereas a PRMD is seen as a private operation with local policies and privacy concerns. An ADMD handles public messages, whereas a PRMD manages the message traffic that is generated from within a private concern. The ADMD-PRMD boundary is viewed as the border between the public and private. If an organization wants to have such a boundary, it should assume the role of a PRMD.

An address is composed of attributes, each of which specifies a level in the address hierarchy, from the major domain and sub-domains to the individual. The three major domains are specified in most X.400 addresses.

Each attribute has a type and a value. For example, an address may begin as:


In this notation, "c", "a", and "p" are attribute types that correspond to the major domains, Country, ADMD, and PRMD, respectively. "US", "ThePhoneCompany", and "Litware" are the attribute values. SMTP addresses are highly comparable, varying only in detail. In citing an SMTP address, one gives only the attribute values, omitting the attribute types. Thus, we might have the equivalent SMTP address:


By naming the attribute types, X.400 defines distinct levels in the address hierarchy. SMTP is more relaxed in that, below the Country domain, SMTP allows for multiple sub-domains, arranged according to local design or custom.

The two categories of address attributes are routable and delivery. The routable attributes correspond to distinct levels, or domains, in the address hierarchy. The X.400 routable attributes continue through ever finer sub-domains. No organization is required to use the finer sub-domains, and their use may introduce unnecessary complexity. However, those sub-domains are available if needed.

The delivery attributes specify individuals or groups and are also known as personal-name attributes. Tables 4 and 5 list all the address attributes.

Table 4   X.400 routable attributes

Attribute type / domain Abbreviation



Administration Management Domain

ADMD or a

Private Management Domain

PRMD or p



Organizational Unit 1


Organizational Unit 2


Organizational Unit 3


Organizational Unit 4


Table 5   X.400 delivery attributes

Attribute type Abbreviation



Given name


Name initial


Generation qualifier (such as Jr., Sr., I, II)


Nickname or alias


Domain-defined attribute


If no delivery attributes are specified, X.400 treats the last ou attribute as the delivery attribute. This is known as organizational messaging. For example, you can configure the X.400 address c=US;a=Fabrikam;p=Contoso;o=Marketing for a recipient.

An attribute is required to have a unique value only within the containing attribute. Just like there is a Portland, Maine and a Portland, Oregon, you can also have:




Just as you cannot have two cities named "Portland" within the state of Oregon, you cannot have two PRMDs named Litware under the ADMD ThePhoneCompany. Uniqueness is required within the containing attribute. This requirement applies to all the attributes (sub-domains) of an X.400 address.

Technically, the organizational units are not individually addressable attributes. For example, the ou4 attribute cannot be assigned a value without first assigning values to ou1, ou2, and ou3. In this respect, the OUs are equivalent to SMTP sub-domains. The OUs are, by definition, a sequence of diminishing domains, each wholly contained within the previous. Thus, an X.400 address may appear as follows:

c=US;a=ThePhoneCompany;p=Litware;o=Marketing;ou1=Sales;ou2=West Coast;ou3=Seattle;ou4=Pike Street;s=Smith;g=John;

In reality, this address would be as improbable (and unnecessary) as the following in an SMTP environment:


Address Hierarchy

The defined levels in the address hierarchy can be represented as a tree. Figure 4 shows the address hierarchy for the reference topology shown in Figure 1. A highly populated drawing would show all PRMD nodes at the same level in the tree, all organization nodes at the same level, and so forth.

A well-formed address tree should conform closely to that classical triangular tree. Each node has a single parent node and zero or more child nodes. The address tree will function only as well as each node's knowledge of the tree's structure, and the true position of the node in that tree.


Address Arc

The line that leads from the root of the tree to a particular leaf is termed an arc. In discussing and processing routes, the arc is an important concept when considering various positions along that arc. For each node in Figure 1, the arc from the root is clearly shown. Although it is an important abstract concept, the arc may or may not be manifested in physical networking equipment or routing capabilities.


A connector is a component that enables the transfer of a message between two nodes in the logical address tree. The physical connections can be incorporated into the tree representation, which can be used for visualizing or planning the routing in a messaging organization (see Figure 5). Every Exchange organization that participates in an X.400 infrastructure will be somewhere in the universal address tree. The addresses that are configured on the connectors determine the limbs and branches to which a node (server or organization) is connected.

Consider a message that originates on a leaf on one side of the tree and is destined for a leaf on the other side. That message travels up the tree to a node held in common by origin and destination, and then travels down the tree to the destination. Typically, no message should take any path that brings it closer to the point of origin or further from the destination.


Each node has an area of responsibility, which can be determined from the logical addresses tree diagram, such as the one that is shown in Figure 4. The concept of area of responsibility can be characterized as the node’s shadow, and it consists of that node and all the other nodes that are hierarchically under it.

As previously stated, a connector is a component that enables the transfer of a message between two nodes. In Exchange, you need to manually configure X.400 connectors between nodes to route messages around the X.400 address tree.

Each connector represents a confirmed contract with the partner node that the partner will handle the address spaces listed on the connector. For each connector, you must specify the address spaces for which the connector will be routing messages. This address space must correspond to the area of responsibility of the target node. For example, if you configure a connector from the Reference node to the Aunt node shown in Figure 4, that connector must specify the address space for the area of responsibility of the Aunt node, which is c=US;a=Grandparent;p=Aunt. Similarly the connector from Aunt to Reference must have the address space c=US;a=Grandparent;p=Parent;o=Reference.


Improperly configured X.400 routing infrastructure may create a situation in which a message begins retracing its path, traversing routes and touching nodes that it has visited previously. This behavior is called a message loop. If the message encounters the same conditions and algorithms in the same nodes that it has previously visited, the system enters an infinite loop.

A message loop is a very serious situation because such messages cycle through the system very quickly, consuming CPU bandwidth, network bandwidth, and server disk space for logs. Performance degrades, and the message is not delivered. Several messages may match the conditions that create the message loop, causing the e-mail system to break down.

To prevent message loops, X.400 messages preserve their own history of travel, a feature called trace. Each trace entry gives the domain, the time the message crossed into the domain, and details concerning operations performed on the message. The first trace entry is created on message origination. That entry is often used as the measure of the age of the message.

The designers of X.400 presume that the routing decision by the servers in the message path would be duplicated each time the same message is processed. Therefore, if the same message touches the same domain or server a second time, further travel will be unproductive. Therefore, on entering a domain, the first task of the first server in the domain is to examine the trace for entries that might indicate the message has previously visited (or originated in) the domain. If such an entry exists, the message is stopped and any requested Non-Delivery Reports (NDRs) are issued. This activity is called loop detection.

Global Domain Identifier

The attributes Country, ADMD, and PRMD are of a different order than the other routable attributes. These three attributes taken together are called the Global Domain Identifier (GDI). Each node in the message path is identified in the trace by the GDI of the server.

If more than one server in the PRMD touches the message, only the first server on the GDI boundary adds a trace entry to the message. The designers of X.400 intended the GDI as the only information that a PRMD is required to reveal. The GDI is used to determine message loops that may exist for messages that cross multiple PRMDs.

Internal Trace

To prevent message loops within the PRMD, the message keeps a second history of travel within the PRMD, called the internal trace. The internal trace records the GDI of each node and the server name. Every server that receives the message adds a new internal trace entry.

Using the internal trace, each server receiving the message is able to determine whether the same message has been processed by the same server previously, and if so, eliminate a potential (and probable) loop.

To preserve the privacy and security of the PRMD, the internal trace is removed by the boundary server as the message leaves the private management domain.

Trace Exceptions

In certain situations, exceptions must be made to the rules of loop detection and trace. Three rules are recognized to address the exception situations, but only two are implemented in the 1988 implementation of X.400. These exceptions are:

  • Redirection   Like a traveler who discovers that a bridge is out on the intended route, a message may encounter a dysfunctional network link and be required to retrace a leg of the journey. Redirection may also occur when an alternate recipient (forwarding address) is set on the destination server, or set by the originator of the message and triggered when the message cannot be delivered to the intended recipient. A message requiring redirection should not trigger loop detection.
  • Distribution list (DL) expansion   A DL can have members located in sites other than the site in which the DL is located. It is possible to have a message addressed to such a DL from a site where one or more of its members are located. This situation will require the message to traverse its path back to the originating site for delivery to the DL members in that site after the DL is expanded. Such messages should be deliverable in the originating site without triggering loop detection.
  • Content conversion (not implemented in 1988)   A message may be required to travel to a special node, outside the normal line of travel, for content conversion. Returning to the normal route should not be considered a loop.

Thus, a new rule is added to the management of trace. Whenever one of these special cases is encountered in the life of a message, the trace (or internal trace) entry for the node in which it occurs is marked with the event. When processing the trace for loop detection, a server begins in present time and reads back in history only as far as the most recent redirection or DL expansion.

These special cases are noted as a reroute rather than the relay of the more typical trace entry. The details of a reroute-trace are operations, as described above.

Provision is also made for detecting mutual inclusion of DL names, such that a message might be sent on an endless loop of DL expansion. This issue is managed through the DL expansion history and is outside the scope of this paper.

The Exchange X.400 architecture underwent significant modifications for Exchange 2000 Server. These modifications were carried over to Exchange 2003. The primary center for routing decisions was removed from the message transfer agent (MTA) and put in the SMTP engine. This change made the management of reroute-trace too complicated to implement through the MTA, and the decision was made to remove all trace (and internal trace) prior to a reroute operation.

Truncating the trace history enabled a message to undergo a high number of reroutes without reaching 512, which is the maximum limit specified by the standard. Truncating the trace history created the potential for the following problems:

  • An X.400 standard-compliant system terminates a looping message because the number of reroutes specified in the trace reaches the maximum limit. Microsoft Exchange lost this safeguard. In Exchange 2003 RTM, a looping message continues to loop until a server fails.
  • An X.400 standard-compliant system recognizes the age of a message and stops it after four hours, based on the date of the earliest trace. Exchange lost this safeguard, too, when the message age-limit was changed from the standard four hours to the SMTP standard of 48 hours.
  • An X.400 standard-compliant system enables additional confirmation of the originator (and spam filtering) by comparing the GDI of the originator with the GDI of the earliest trace. After a reroute, Exchange messages cannot pass that check.


The sequence of diminishing domains is an important concept in X.400. Consider again the long address:

c=US;a=ThePhoneCompany;p=Litware;o=Marketing;ou1=Sales;ou2=West Coast;ou3=Seattle;ou4=Pike Street;s=Smith;g=John;

Each domain is fully contained within the larger domain. Therefore, the people, software, or servers in the domain


are expected to be completely within the domain


Also, the larger domain is authoritative for all messages (notifications, probes, e-mail messages, and reports) that are sent to any address containing the attributes c=US;a=ThePhoneCompany;p=Litware.

Routing follows the line of responsibility. Although no government organization is expected to get involved in routing on behalf of the country, the ADMD is expected to be fully responsible for everything that matches on country and ADMD. The responsibility of the ADMD is such that, if the ADMD cannot deliver or route a message within its own domain, no other organization in the world can deliver the message either. In Exchange, we refer to this concept of a node's responsibility as its authority.

Consider a message addressed from Great Britain:


The message is addressed to John Smith at Litware at the address:

c=US;a=ThePhoneCompany;p=Litware;o=Marketing;ou1=Sales;ou2=West Coast;ou3=Seattle;ou4=Pike Street;s=Smith;g=John;

The message is first sent from Jaffe’s client to his local server. Because the message cannot be delivered within the local GDI, it is passed to the higher domain, the ADMD c=GB;a=Contoso. That higher domain determines that the message does not share a common GDI, so it is routed to c=US;a=ThePhoneCompany.

The X.400 Standard does not envision any actual nodes at the country level, just as SMTP does not support nodes at the .com or .US level.

Prior to that point, the message is traveling from leaf to the root of the tree. After the message reaches c=US;a=ThePhoneCompany, each domain boundary that is crossed will bring it leafward, and closer to its destination.

When a message begins to pass from leaf to root, a properly configured routing system will not turn it back to the same leaf. Similarly, when a message is headed from root to leaf, it must never turn back toward the root. An effective routing design will always move the message further from the origin and closer to the destination. Even in consideration of the reroute exceptions stated previously (see "Trace Exceptions" in "Tracing and Loop Detection" earlier), a message always approaches closer to the destination, given the information available at the time of routing. Therefore, a message should (unless rerouted) never cross into a domain that it has previously visited.

The X.400 standard includes a series of recommendations. The following table lists the recommendations that are relevant to Exchange.

本主题中提供的第三方网站信息旨在帮助您查找所需的技术信息。URL 如有更改,恕不另行通知。

Table 6   X.400 standard references

Recommendation Title Description

ITU-T Rec. F.400/X.400
(ISO/IEC 10021-1)

Message Handling System and Service Overview

Provides a general overview and defines the overall service of a message handling system (MHS).

ITU-T Rec. X.402
(ISO/IEC 10021-2)

Overall Architecture

Defines the overall architecture of an MHS and serves as a technical introduction to it.

ITU-T Rec. X.411
(ISO/IEC 10021-4)

Message Transfer System: Abstract Service Definition and Procedures

Defines the abstract service that is provided by the Message Transfer System (MTS), and specifies the procedures to be performed by Message Transfer Agents (MTAs) ensure the correct distributed operation of the MTS.

ITU-T Rec. X.412
(ISO/IEC 10021-10)

MHS Routing

Specifies the means by which messages are routed through the MHS, and supplements the procedures that are defined in 14.3 of ITU-T Rec. X.411.

ITU-T Rec. X.419
(ISO/IEC 10021-6)

Protocol Specifications

Specifies the MTS Access Protocol (P3), the MS Access Protocol (P7), and the MTS Transfer Protocol (P1).

ITU-T Rec. X.420
(ISO/IEC 10021-7)

Interpersonal Messaging System

Defines Interpersonal Messaging, which is a form of Message Handling that is tailored for ordinary interpersonal business or private correspondence.