The performance of the messaging system decreases, and NDR messages are not delivered in an X.400 connector messaging system in Exchange Server 2003

In a X.400 connector messaging system in Microsoft Exchange Server 2003, the performance of the messaging system decreases. Additionally, the NDR messages are not delivered.

This problem occurs when a non-delivery report (NDR) message that is sent to the wrong recipient address encounters a loop. When this occurs, the looping NDR message consumes CPU bandwidth, network bandwidth, and server disk space for log files.

Hotfix information

A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing this specific problem. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix.

If the hotfix is available for download, there is a "Hotfix download available" section at the top of this Knowledge Base article. If this section does not appear, contact Microsoft Customer Service and Support to obtain the hotfix.

Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft Web site: Note The "Hotfix download available" form displays the languages for which the hotfix is available. If you do not see your language, it is because a hotfix is not available for that language.

Prerequisites

Because of file dependencies, this hotfix requires that Microsoft Exchange Server 2003 Service Pack 2 (SP2) be installed on the server.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:

Restart requirement

You must restart the computer after you apply this hotfix.

Hotfix replacement information

This hotfix does not replace any other hotfix.

File information

The English version of this hotfix has the file attributes (or later file attributes) that are listed in the following table. The dates and times for these files are listed in Coordinated Universal Time (UTC). When you view the file information, it is converted to local time. To find the difference between UTC and local time, use the Time Zone tab in the Date and Time item in Control Panel.

Hotfix installation information

After you apply this hotfix, you must enable the hotfix. To do this, create the EnforceX400SiteAddressSpace registry entry on the server that is running Exchange Server. To do this, follow these steps.

Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.

1. Click Start, click Run, type regedit, and then click OK.
2. Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeTransport\Parameters
3. On the Edit menu, point to New, and then click DWORD Value.
4. Type EnforceX400SiteAddressSpace, and then press ENTER.
5. Right-click EnforceX400SiteAddressSpace, and then click Modify.
6. In the Edit DWORD Value dialog box, click Decimal under Base.
7. In the Value data box, type a value that is not zero to enable the function, and then click OK.
8. Close Registry Editor.

Note If the EnforceX400SiteAddressSpace registry entry is not present, or if you set the value to zero, the hotfix does not function.

Additionally, if the Share Address Space option is enabled, this behavior has no meaning. The new functionality compares the next hop, the user address, and the site address space. If the site address space is a better match than the next hop, the Exchange server takes ownership of the recipient. Then, the Exchange server sends the NDR message to the sender. Alternatively, the server treats the NDR message as bad mail.

A specific scenario in which this problem occurs is as follows:

• Server A is running Exchange Server 2003. The address space contains the following information:
  "c=US; a=Test; o=OR1"
• Server B is using a third-party X.400 mailbox server. The address space contains the following information:
  "c=US; a=Test;"
• Server C is running Exchange Server 2003 for operational redundancy. The address space contains the following information:
  "c=US; a=Test; o=OR1"
• The recipient address is as follows:
  c=US; a=Test; o=OR1; ou1=testou1; ou2=testou2

In this scenario, the Private Management Domain (PRMD) field is missing or is null in all addresses.

When Server A tries to route the message, no route to "ou1" is available. Exchange finally finds a matching route through the higher-node Server B. However, the higher-node Server B cannot deliver the message any better than Server A can. Then, Server B transfers the message to Server C. Server C routes the NDR message back to Server B. Therefore, the loop is "A-B-C-B-A."

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.