Internet message routing problems to Bridgehead server

I struggled with a problem the other day that I thought was worthy of mentioning. I did find the information I was looking for (eventually), but it was a challenge to narrow the problem down. This organization had just installed a new E2K3 SP2 mailbox server in to their organization. They had an existing mailbox server and an existing front-end/bridgehead server (for inbound and outbound SMTP). Once a mailbox was moved, it could send internal mail, receive internal and external mail, but they received an NDR message when they sent a message to the Internet.

The following recipient(s) could not be reached:
jim@external.net on 10/31/2006 10:57 AM
A configuration error in the e-mail system caused the message to bounce between two servers or to be forwarded between two recipients. Contact your administrator.


We were also seeing the following messages in the event log:

A non-delivery report with a status code of 5.3.5 was generated for recipient rfc822;externaluser@hotmail.com (Message-ID 21BB0C8F0C7EC74EB1BABCA27E16C82A0262A25B@internalserver).
Causes: A looping condition was detected. (The server is configured to route mail back to itself). If you have multiple SMTP Virtual Servers configured on your Exchange server, make sure they are defined by a unique incoming port and that the outgoing SMTP port configuration is valid to avoid looping between local virtual servers.

Solution: Check the configuration of the virtual server's connectors for loops and ensure each virtual server is defined by a unique incoming port.

In addition, when the new mailbox server would create a new temporary link queue to send mail to the SMTP connector, we would see the following message in the Additional Queue Information box at the bottom of the screen.

Unable to deliver the message because the destination address was misconfigured as a mail loop.

I went through the entire configuration a couple of times and missed the problem the first time. There were several issues:

1) The bridgehead server's name was BH.organization.com, but there was also a DNS domain zone (internal) called BH.organization.com.
2) The bridgehead server was registering a "backup network" IP address as well as it's corporate network address.
3) Finally, the SMTP virtual server's name on the bridgehead server had been changed, but that name was not resolvable in DNS internally. Someone had manually fixed this in a HOSTS file on the other mailbox server, but that was long before the current IT folks had possession of the server.

No, why did they change the SMTP virtual server's FQDN? (This is on the SMTP virtual server property pages). When an SMTP virtual server initiates a connection to a remote system, it sends an EHLO or HELO command followed by what it thinks is it's FQDN. It gets that from the SMTP virtual server properties.

Some firewalls and message hygiene systems confirm that this name is resolveable externally. It is not RFC compliant to do this, but they do it anyway. So, sometimes the name that you have for your internal SMTP virtual servers have to be publicly resolveable also. Yuck.

The problem is that Exchange uses this information internally for server-to-server name resolution. In the past, I have gotten around this by creating an internal DNS record so the internal name and IP address can also be resolved.