Microsoft KB Archive/188819

= XFOR: OV/VM Connector Returns Different NDRs to PROFS Sender =

Article ID: 188819

Article Last Modified on 10/28/2006

-

APPLIES TO


 * Microsoft Exchange Server 5.0 Standard Edition
 * Microsoft Exchange Server 5.5 Standard Edition

-



This article was previously published under Q188819



SYMPTOMS
Messages sent from PROFS to unknown PROFS addresses in Exchange using the LinkAge version 3.2 Connector or the Microsoft Exchange Connector for IBM OV/VM version 5.5 may result in different types of non-delivery reports (NDRs) being returned. +-+ +++        |         | OV/VM Connector | +++               +-+ +-+                +-+ Address Space on OV/VM Connector in Site 1: PROFS * cost=1 Address Space on X.400 Connector in Site 1: PROFS NODE2(*) cost=1 NOTE: This particular Address Space is not required to reproduce the NDR behavior.
 * PROFS     |
 * NODE3(USER3) |
 * NODE3(USER3) |
 * Exchange Site 1 | X.400 Connector| Exchange Site 2 |
 * NODE1(USER1) |  with Dir Rep  |   NODE2(USER2)  |
 * NODE1(USER1) |  with Dir Rep  |   NODE2(USER2)  |

Address Space on X.400 Connector in Site 2: PROFS * cost=1  Messages sent from a PROFS user to an unknown PROFS address in Site 1 result in an NDR similar to the following:

BADUSER unknown at NODE1; not received.

The conditions leading to the production of this NDR are explained in the CAUSE section (1), below. Messages sent from a PROFS user to an unknown PROFS address in Site 2 result in a different NDR message:

NODE2 cannot deliver to BADUSER.

This NDR does not indicate that the PROFS address was unknown. The conditions leading to the production of this NDR are explained in the CAUSE section (2), below.



CAUSE
This behavior is by design. The reason for the differences in the NDR messages is that the delivery error is detected at different points in the mail network. Depending upon the location in the network, where the problem is detected, and the circumstances under which it is detected, the NDR is created. It is not possible or desirable to guarantee the same error message for different "bad recipients."

A fundamental function of the connectors (PROFS, SNADS, and Notes) is to allow the use of Exchange as a messaging backbone. As part of this feature, it is not required that every address in every attached messaging system be registered in the Exchange directory adjacent to the connector. In fact, Exchange administrators may decide, for various reasons, not to enable directory synchronization (dirsync) between Exchange and PROFS. However, even if dirsync is enabled, directory replication latency may cause a valid address not to be immediately present in a directory.

 When a PROFS user sends an address to NODE1 (BADUSER) in the topology shown above, the connector determines that NODE1 is the PROFS proxy node name by reading the site addressing. The connector categorically knows that all proxy addresses with the node name of NODE1 must be registered in Site 1's Exchange directory. When the address lookup fails, the connector knows the user does not exist and immediately generates the appropriate error code for an unknown address NDR.

When a PROFS user sends an address to NODE2(BADUSER), the connector knows that NODE2 is not the PROFS proxy node name for the immediate site. Because NODE2(BADUSER) cannot be found in Site 1's directory, the message is submitted to the Exchange backbone for routing. If there is a specific NODE2(*) PROFS Address Space defined on the X.400 Connector leading to Site 2, the message transfer agent (MTA) routes the message to the other Site, where the receiving MTA attempts to resolve the address. If the address does not exist in Site 2's directory, the MTA once again routes the message, based on Site 2's GWART. Site 2 has a PROFS * Address Space defined on the X.400 Connector, which causes the MTA to route the message back to Site 1. The MTA in Site 1 eventually routes the message back to the OV/VM Connector based on the PROFS * Address Space defined on the OV/VM Connector. The OV/VM Connector detects that the message is looping and generates the error code that causes the following NDR to be generated:

NODE2 cannot deliver to BADUSER.

The looping message condition is detected even more quickly when the PROFS * Address Space defined on the OV/VM Connector is the only PROFS Address Space defined in Site 1.

Keywords: kbprb KB188819

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.