A user tried to send email, and got a delivery failed message (#550 4.4.7 ) and I ran the mail transport troubleshooting assistant, which reports "Error submitting mail" explaining "Mail submission failed: Error message: Server does not support secure connections" I had installed a UCC SSL successfully, and email was being sent normally, but then I suddenly found that email was not being sent to two addresses at different domain. What could suddenly cause the server to generate this error? Any leads on fixing or troubleshooting?

Hi, What's the version of the Exchange server? Could you post the full NDR message on the forum? Whether other senders have this issue to send the email to the problematic domain? Thanks Allen

Hi Allen, Exchange Server 2007, running with SBS 2008. After further investigation I believe the problem relates to the SAN I used for the UCC SSL. I hope that if I provide the network topology, you might be able to recommend the correct names for the SANs. The internet domain name is distance.com and the internal domain name is depth. The server name is Honeycomb. Based on some initial recommendation from the DNS provider (but which they won't support technically) I set the certificate common name as remote.distance.com and Subject alternative names honeycomb.exchange.depth exchange.distance.com autodiscover.distance.com distance.com The problem is that Exchange is generating an error that states: Microsoft Exchange couldn't find a certificate that contains the domain name HONEYCOMB.depth.local in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector send connection with a FQDN parameter of HONEYCOMB.depth.local. My question is: what would be the required names for the SAN? I mean, which of the names from the existing 4 SAN, should become HONEYCOMB.depth.local Second part: given the network topology I described, am I using the correct name for the autodiscover function? I think it may also need to be corrected, so that mobile devices can connect with the mail server.

Hi, Thanks for your information and I apologize for the delay response. From the information, I knew that you configured mutual TLS in your scenario. You need to include the Honeycomb.depth.local in the SAN of the certificate to make sure the FQDN of the send connector to be matched. Answer: 1, The required name is honeycomb.depth.local, honeycomb, autodiscover.distance.com, distance.com, remote,distance.com, exchange.distance.com 2, It's fine for autodiscover. More on Exchange 2007 and certificates - with real world scenario http://msexchangeteam.com/archive/2007/07/02/445698.aspx Thanks Allen

Thanks for your information and I appologize for the delay response as well. It turns out, I needed to set up the smart host. It really is terrible how marking terms like smart host are interpreted wrongly. I thought smart host was some new service I needed to buy, so I avoided it, and no where in my reading of sbs did I get told it is just my isp. So once I set my isp, I was fine. Unfortunately my Subject Alternate Name list is limited to 4 terms. I wish there was a really simple explanation of going about the naming. Anyway, thanks for your help.