XADM: Unable to Send to Remote Users Using SMTP Addresses

Last reviewed: April 15, 1997
Article ID: Q154685
The information in this article applies to:
  • Microsoft Exchange Server, version 4.0

SYMPTOMS

One of the following errors may be written to the Event Viewer Application Log by the receiving MSExchangeMTA when a message is sent between Exchange Sites using the SMTP Address of an Exchange user, rather than the X400/X500 Address:

  Event ID 142: "Unable to route to c=us;a=
  ;p=SendingOrgName;o=SendingSitename;DDA:SMTP=user1@RecvOrg.RecvSite.com."

OR

   Event ID 290: "A non-delivery report (reason code unable to transfer
   and diagnostic code MTS-congestion) is being generated for message
   c=us;a= ;p=orgname;l=RecvMTAname-960808200654z1. It was originally
   destined for
   c=us;a=;p=orgname;o=SendSite;DDA:SMTP=alias@RecvSite.orgname.com; and
   was to be redirected to.[MTA DISP:RESULT 20 136]."

A Non-Delivery Report (NDR) may also be delivered to the sender of the message stating that the message did not reach some or all of the intended recipients with one of the following reasons given:

    - "Recipient name not found",

OR

    - "due to congestion in the message transfer service".

The NDR is generated by the receiving MTA.

CAUSE

This error condition is caused by the receiving Exchange MTA's inability to route a message addressed with an SMTP address to an Internet Mail Connector for further resolution. This behavior is by design.

WORKAROUND

There are three methods to workaround this problem, depending on whether there is replication between the sites.

  1. Whether replication has occurred or not, using the X400 Address instead of the SMTP address to send to users in other sites will work, because Exchange is a native X400 messaging system.

  2. If replication has occurred between the sites and an IMC is available, the IMC can be configured (using the Email Domain . . . button on the Connections tab) to route all mail addressed to the various Exchange SMTP addresses (the SMTP addresses of users that actually have a mailbox on the Exchange system) will be forwarded directly back to the Exchange Server. In this case, the Address Space on the IMC should be SMTP and left blank. Once the message goes out the Internet Mail Connector and comes back in, it will be matched to an address in the Exchange directory and will be routed to the appropriate mailbox.

  3. If replication has not occurred among the sites, then an IMC must be configured in each site with the Address Space configured as "*@localsite.organization.com", for example. The IMC must be configured, as in the second case, to forward all mail back to the Exchange Server itself.

The last two options above consume processing power and memory, and the better solution would be to use X400 Addressing between sites if a user must, for some reason, use a one-off address (or custom recipient) to send to another Exchange user.

MORE INFORMATION

Exchange Server is not designed to support messaging between Exchange users on different sites using the Internet-style, or SMTP, addresses. Each time a message is sent that is addressed with an SMTP address, the MTA looks for a valid route for that recipient in the Routing Table (that is, the Gateway Address Routing Table, or GWART). If a route is found to another site through one of the site connectors (Site Connector, Dynamic RAS Connector, or X400 Connector), the MTA will successfully hand off that message to the MTA in the other site. However, if the receiving MTA cannot find another valid SMTP address space in its GWART to forward that message to, then it will generate this error condition.


Additional query words: IMC XCON
Keywords : kbusage XADM
Version : 4.0
Platform : WINDOWS
Issue type : kbprb


THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: April 15, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.