Message sent through a fax connector generates an NDR after you move the routing group in Exchange 2000 and in Exchange 2003

After you move a routing group to a different administrative group, messages that are sent through a fax connector that is based on an X.400 address space generate non-delivery reports (NDRs). This issue may occur after you migrate from a Microsoft Exchange Server 5.5 organization to a pure Exchange 2000 organization.

Additionally, the following events may be listed in the Event Viewer:

Event Source: MSExchangeMTA
Event Category: Field Engineering
Event ID: 285 Computer: Servername
Description:
A priority 0 held-for-delivery/transfer queue for CN=FAX GW,CN=CONNECTIONS,CN=RG-4,CN=ROUTING GROUPS,CN=ROUTING GROUPS - FIRST,CN=ADMINISTRATIVE GROUPS,CN=COMPANY,CN=MICROSOFT EXCHANGE,CN=SERVICES,CN=CONFIGURATION,DC=EXAMPLE,DC=NET was created and given the 0 identifier. [MTA MAIN BASE 25 213] (8)

-and-

Event Source: MSExchangeMTA
Event Category: MTA Administration
Event ID: 523
Computer: Servername
Description:
(MTA OPERATOR(18) Proc 166) (MTA OPERATOR(18) Proc 166) 12-03-02 02:57:57pm Add operation failed, entity /DC=NET/DC=EXAMPLE/CN=CONFIGURATION/CN=SERVICES/CN=MICROSOFT EXCHANGE/CN=COMPANY/CN=ADMINISTRATIVE GROUPS/CN=ROUTING GROUPS - FIRST/CN=ROUTING GROUPS/CN=RG-4/CN=CONNECTIONS/CN=FAX GW already configured (4)

When you trace the message, you see that the routing engine recognizes this fax gateway route correctly and delivers the message to the message transfer agent (MTA), but the MTA does not detect the fax gateway. Because of this, the MTA re-routes the message to the Simple Mail Transfer Protocol (SMTP) queue where it loops back and forth between the MTA and SMTP until the trace data is exceeded, and an NDR with the code 5.4.4 is generated.

Note This issue is not limited to fax connectors. This issue can occur with any connector that is created with the Microsoft Exchange Development Kit (EDK).

This issue occurs because the routing component cannot decode the X.400 address. The routing component only decodes the X.400 address if it determines that the X.400 address matches the local site's X.400 address. The local site address is determined from the default recipient policy instead of from the recipient policy for the particular site.

The routing component incorrectly processes the X.400 address in situations where the address does not match the X.400 address of the local site. If a recipient policy has a Legacy (Exchange Server 5.5) distinguished name (DN) that does not match the Legacy DN contained in a specific local recipient policy, the routing component uses the default recipient policy. However, the Microsoft Exchange Information Store uses the local recipient policy to create the X.400 address, instead of the default recipient policy.

Note This issue is not limited to changing the X.400 proxy address in the recipient policy. This issue can occur when you change the SMTP address in the recipient policy because the message is encapsulated in the IMCEA format as part of the delivery process.

To work around this issue, use one of the following methods:

Remove the Local Recipient Policy

1. Delete the local recipient policy for the site where you experience this issue.
2. Allow sufficient time for the routing change to propagate throughout the organization.
3. Stop and then restart the IIS Admin Service.

When you follow these steps, the Microsoft Exchange Information Store (Store.exe) uses the default recipient policy to match the routing destination. When you move to a native mode Exchange 2000 organization, it is best to delete all local recipient policies and use only the default recipient policy.

Change the X.400 Proxy Address

Change the X.400 proxy address on the affected recipient policy so that it matches the proxy address on the default recipient policy.