Avoiding Infinite Loops with Internal Relay Domains in Exchange 2007/2010

One of the types of Accepted Domains you can add to an Exchange Server 2007 or 2010 organization is an Internal Relay domain.

For Internal Relay domains the Exchange servers behave like this:

If I have a local recipient within the organization with the SMTP address that the email is addressed to then deliver it to that mailbox. Otherwise, send it outside the organization.

Internal Relay domains are commonly used in shared SMTP namespace scenarios, where two separate mail systems both use the same domain name for email. If you want to know more about this scenario read How to Share an Email Domain Between Two Mail Systems.

The steps for setting up an Internal Relay domain are usually:

  1. Add the domain name to the Accepted Domains for the organization
  2. Create a Send Connector to route the non-local recipients in that domain to another external mail system

However the fact is that it will work just fine if you only do step 1, and let your main Send Connector for the “*” namespace (ie, all external domains) handle the routing outwards from the organization (either via smart host or DNS).

That is, unless you are using Edge Transport servers.

If you are using Edge Transport servers, have configured an Internal Relay domain, and have not configured a specific Send Connector for that namespace, you may see non-delivery messages when internal senders try to send to external recipients of that namespace.

This happens because an infinite loop is created between the Hub Transport and Edge Transport servers.

  1. The Hub Transport is correctly routing emails for non-local recipients in the Internal Relay domain name out of the organization via the Edge Transport servers.
  2. However the Edge Transport servers recognize the Internal Relay domain as being local to the organization, and therefore route the email back into the Hub Transport server (as they would if they’d received an email sent from an external sender and addressed to a recipient of that domain name).

Under those conditions you may see non-delivery reports for emails sent to non-local recipients of the Internal Relay domain.

In the diagnostic information will be the reason, an infinite loop.

#554 5.4.6 Hop count exceeded – possible mail loop ##

You will also see the loop in action in the message headers provided with the NDR.

The solution for this problem is to configure a Send Connector for the organization that is specifically for that Internal Relay domain name, that is a lower cost than the default Send Connector.

On an Exchange 2010 server in your organization (not the Edge Transport server) open the Exchange Management Console and navigate to Organization Configuration/Hub Transport. Select the New Send Connector task in the Actions pane of the console.

Give the Send Connector a name and click Next to continue.

Add the SMTP address space for the Internal Relay domain. Choose a cost that is lower than the default Send Connector that EdgeSync creates, which is a cost of 100 by default. Click Next to continue.

You can choose to route via DNS or a smart host, whichever suits your specific scenario. DNS is probably going to be fine if the MX records for that domain already point to where you want the mail to be routed to. Otherwise a smart host may be required. Click Next to continue.

Set the source server depending on which server you want to send out the emails to that domain. For Internal Relay domains the source server for the Send Connector must be a Hub Transport server, not an Edge Transport server, in order to achieve the desired email routing for all scenarios. This means that the Hub Transport server you choose must be able to make SMTP connections through your firewall to wherever it needs to route the email for the Internal Relay domain.

Finally, click New to complete the wizard and create the new Send Connector.

With the Send Connector in place you should see the correct routing behaviour in each scenario. Outside senders who send to a non-local recipient in the Internal Relay domain will be correctly routed into the Exchange organization first, and then back out the Send Connector from the Hub Transport server. Meanwhile email sent to local recipients of the Internal Relay domain will be delivered locally.

 

Email sent from internal senders to non-local recipients of the Internal Relay domain will be correctly routed out the Send Connector as well, while email sent to local recipients of the Internal Relay domain will be delivered locally as expected.

This configuration achieves the desired message delivery without infinite loop conditions.

Bottom line is, if you are using Internal Relay domains and also Edge Transport servers you must configure a Send Connector for handling non-local recipients in that domain, or else you will create an infinite loop condition.

Comments

  1. Amit says

    Hi Thanks for the nice info … i am facing the similar issue as described below can you please suggest someting to rectify the same…
    ——————————————-
    One of the user getting approval requests (patch applications) from ChangeRequest@i7.com. However, when he respond, replies are rejected – see below.
    —————————
    From: Microsoft Exchange
    Sent: 29 September 2011 15:32
    To: James bond
    Subject: Undeliverable: RE: To install the MS patches at Saturday 11:00 PM CST to Sunday 01:00 AM CST

    Delivery has failed to these recipients or distribution lists:

    ChangeRequest%i7Tech@i7.com
    A problem occurred during the delivery of this message. Microsoft Exchange will not try to redeliver this message for you. Please try resending this message later, or provide the following diagnostic text to your system administrator.

    The following organization rejected your message: maileme.abc.com.
    _____

    Sent by Microsoft Exchange Server 2007

    Diagnostic information for administrators:
    Generating server: cashub2.abc.corp.local

    ChangeRequest%i7Tech@i7.com
    maileme.abc.com #554 5.4.6 Hop count exceeded – possible mail loop ##rfc822;changerequest@i7.com
    Original message headers:

    Received: from edge2.abc.com (192.168.1.1) by
    cashub2.abc.corp.local (10.10.1.1) with Microsoft SMTP Server (TLS)
    id 8.2.254.0; Thu, 29 Sep 2011 15:31:48 +0100
    Received: from cashub2.abc.corp.local (10.10.1.1) by maileme.abc.com
    (192.168.1.1) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 29 Sep
    2011 15:15:42 +0100
    Received: from Edge1.abc.com (192.168.1.2) by
    cashub2.abc.corp.local (10.10.1.1) with Microsoft SMTP Server (TLS)
    id 8.2.254.0; Thu, 29 Sep 2011 15:16:44 +0100
    Received: from cashub2.abc.corp.local (10.10.1.1) by maileme.abc.com
    (192.168.1.2) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 29 Sep
    2011 15:00:56 +0100
    Received: from edge2.abc.com (192.168.1.1) by
    cashub2.abc.corp.local (10.10.1.1) with Microsoft SMTP Server (TLS)
    id 8.2.254.0; Thu, 29 Sep 2011 15:01:39 +0100

    So while checking the below findings.

    1. There is only mail contact configured for that SMTP address changerequest@i7.com as no mailbox is present.
    2. mailema.abc.com” are the alias used by application or application groups. Maileme and Edge are the different machines and on Edge machine there is only one NIC installed.
    3. Under the accepted domain “i7.com” is configured as an authoritative domain which is set to false by default. Apart from this Under the Send connector there is a send connector configured which is set to disabled; address space is configured with “1″ cost and under the network tab i am seeing route mail through the following smart host is there which i am unable to ping the smart host. And Under the source servers are all CASHUB server listed.
    4. Do i need to change the setting under the network TAB to use DNS “MX” record to route email..??? Or do i need to change the setting under the accepted domain from “Authoritative” to “Internal relay Domain.” and enabled ??
    5. Tried sending the mail from external as well getting the similar error stating that Delivery to the following recipient failed permanently: changerequest@i7.com

    Technical details of permanent failure:
    Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 Invalid recipient (#5.1.1) (state 14).

    • says

      Amit, I’m having trouble picturing how your whole setup is configured, but it sounds like two separate issues – one issue is the mail loop, the other is the “invalid recipient” error when you test it externally.

      Is @i7.com and @mailema.abc.com both within the same Exchange organization? Is the user who replies to the emails and gets the mail loop a user within that organization, or a separate one?

  2. amit says

    Thanks paul on your reply .. and all effort. here i just want to update that while digging into more about the change request SMTP address found that change request is an application which does not support email integration so that’s was the issue.

    I liked your whole explanation about the same .

  3. says

    Yet another good article, thanks Paul.

    “Set the source server depending on which server you want to send out the emails to that domain. For Internal Relay domains the source server for the Send Connector must be a Hub Transport server, not an Edge Transport server, in order to achieve the desired email routing for all scenarios.”

    According to my tests source server doesn’t matter so we can use hub or edge transport servers as a source. In addition if we have edge transport we have to use a send connector for an external relay domain as well.

  4. Dario Palermo says

    I’m testing a shared namespace and I found an unexpected problem: Exchange is generating NDRs for non existent addresses (I mean, addresses that do not exist on Exchange or the other non exchange server). I was pretty sure Exchange would not generate NDR for a non-authoritative domain, yet it is.

    Did I miss something?

    bye, Dario

  5. Svein Maubach says

    Your article put me in the right direction, but I had to improvise since my setup is different:

    When one have one non-authorative Exchange server behind a non-microsoft mailgateway, which sorts out some mail-adresses to be delivered to other servers, one can still have the loop due to no mailbox existing.

    The solution then can be a combination of testing and tagging using private headers in the gateway.
    For instance two rules in the gateway applied to all mail being forwarded to the Exchange server:
    rule #1: test if the X-SomePrivateHeaderEntry header entry exists with value “true”, if it does, reject with a 550 message (Requested action not taken: mailbox unavailable)
    rule #2: set the X-SomePrivateHeaderEntry header entry to value “true”

    Then the loop will be limited to a once around instead of up to 25 times, and a sensible error is returned.

Leave a Reply

Your email address will not be published. Required fields are marked *