Exchange 2010 – TLS negotiation on Send Connectors

Over the past month of so, I’ve been troubleshooting an issue that I felt I should blog about. What we would notice was that when Exchange receives emails with attachments, it took an awfully long time to forward the email to the smart host. An email with a 1Mb attachment would typically take between 10-15 minutes to be delivered to the external recipient. The issue only occurred when send emails to external domains via the smart host. To make things worse, while the mail with the attachment was processed, all other emails would be queued up.

To figure out exactly where the slowness was occuring, I decided to try a different smart host. We noticed that mail delivery was working perfectly with the new smart host. So my initial theory was that this was a smart host specific issue. After opening a ticket with the vendor, they informed me that they believe its an Exchange issue (surprise surprise!).  They sent me debug logs which showed that Exchange would open up an SMTP connection and just keep it open for 10 minutes before actually send ing the data to the smart host. What puzzled me was why I was not seeing the same behavior with the other smart host. You would think that if it was an Exchange bottleneck, the behavior should not be any different irrespective of the smart host.

So I finally decided to do a packet capture on the Exchange Hub Transport server. To my surprise I noticed that all the SMTP traffic including the MIME traffic was fully encrypted. So I quickly checked the Send connector and Smart host authentication was completely turned off. This really confused me as there are no other obvious settings to turn off TLS authentication. I wanted to rule out the possibility that encryption is the cause for slowness. So I did some research and found this article:

http://webbanshee.blogspot.com/2009/09/disable-tls-in-exchange-2007.html

For those who want a summary of the article, Exchange 2010 Hub Transport enables TLS encryption on the Send connectors by default and even if the setting is disabled in EMC, it is not truly disabled. To disable the setting, you need to use powershell and type the following commands:

Get-SendConnector | FL

This will list all the Send Connectors that are configured within the Exchange environment. The next step is to determine the send connector that is being used and look for the IgnoreStartTLS setting. If this setting is set to False (which is true by default), TLS encryption is enabled. This was true in our case. To disable TLS encryption for the send connector, issue the following command:

Set-SendConnector -Identity “Name of Send Connector” -IgnoreStartTLS: $TRUE

After issuing this command, restart the MS Exchange Transport Service. After I did this, mail flow was smooth and mails with very large attachments would take just a few seconds to forward to the smart host.

My conclusion was that there was some issue with TLS encryption between our smarthost and Exchange. We had TLS encryption enabled between Exchange and the second smart host as well and we did not face the same issues. So it seems isolated to the Sonicwall smart host in question.

All in all it was a good feeling to resolve the issue using packet captures. As they say, a packet capture never lies!