EXTERNAL RELAY TROUBLESHOOTING 101

Recently I was brought in to a client site to troubleshoot an issue with a Windows Small Business Server 2011 migration. The migration, for the most part, went flawlessly by the organization’s IT partner, however there were now issues relaying emails from the company external web server off the new SBS 2011 Server.

I was quickly briefed that no firewall or external website changes had been made prior to or since the migration. The external web site was maintained by a separate vendor on a shared web hosting server. All emails from forms on the web site were not making it to the internal users of the company.

As relaying is configured differently in SBS 2003 (Exchange 2003) compared to SBS 2011 (Exchange 2010) I created an external relay connector, called EXT REC CONNECTOR, to accept authentication from the IP address of the external web site. I did this primarily so I could more quickly isolate the issue and, of course, further control the authentication mechanisms available for the external web server.

The web site vendor was able to setup a temporary test form and reassured us the IP address of the webserver had not changed recently. I confirmed the IP address of the web server by viewing the previous Virtual SMTP Connector Relay settings of the old server.

However, as I continued to test sending emails from the test form on the external web server the emails never arrived to the test mailbox addresses.

In my testing I did configure other external servers I had access to, to relay off this receive connector I created and I was able to relay test emails successfully with no issue.

Since neither I nor the web site vendor had access to the shared server maillogs (either via shell access or some type of control panel) it was really difficult to see what was going on between the communication attempts of the external web server and the internal Exchange server.

I then decided to configure the test form to use one of my external web servers as a relay. I configured the proper credentials on the external server I was using, then directed the test form to use this new information. Success! I was able to receive a test email and get the valuable information I needed to better troubleshoot this issue. The information I needed was contained in the internet headers of the email message.

Now that we had the internet headers, I was able to dig deeper through the email transfer history and see the communications between the various severs as they handed off email. What I saw was that the original IP Address of the external web server, which was always used as an approved relay address, was nowhere to be found in the internet headers of the test email we received.  Instead there was now a different IP address the external web server was using to send out emails. This is bolded in the image below.

Now that we had the new, and correct IP address of the external server that we needed to allow to relay off of the internal Exchange Receive Connector, we were able to change this IP address on the receive connector, and emails from the various forms on the external web site were able to be relayed off the server with no issue.

It was vital to our troubleshooting efforts to receive more information from the external web server, and being able to relay off one of our own external servers so we could receive the header information. Once we had this information we could verify the correct IP address the web server was actually attempting to send emails from.

NOTE: All IP Addresses in this article were changed to private IP addresses to protect the identity and interests of the client.