I have a new Exchange 2013 environment running on Windows 2013 R2 with 2x Edge and 4x CAS/Mailbox servers deployed. It is deployed in a resource forest, with proper trust relationships established to the primary forest. OWA, ActiveSync, and IMAP all work great.
For those clients that don't/won't work with ActiveSync, I of course need IMAP and SMTP (we're consciously giving a flat "no" to POP). IMAP is working fine; SMTP is not.
The default receive connector Client Frontend is configured to listen on port 587. When I disable TLS in e.g. Mac Mail (behavior's virtually identical regardless of client), I'm able to login only with users in the resource forest -- I cannot authenticate users in the primary forest. If I enable TLS (which is what I want, and what the settings seem to indicate), I can't connect at all.
Interestingly, the Client Proxy default receive connector (on port 465) does work, with TLS enabled and authenticating primary forest users. This tells me that the SSL certificate is fine, as well as the trust is functioning.
I can't figure out why the Client Frontend connector will not let me connect over TLS. When I use Telnet, I get the following introduction:
Trying x.x.x.86...
Connected to excmb1.example.com.
Escape character is '^]'.
220 example.com Microsoft ESMTP MAIL Service ready at Wed, 6 Aug 2014 15:51:27 -0800
ehlo
250-example.com Hello [x.x.x.155]
250-SIZE 36700160
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-AUTH GSSAPI NTLM
250-8BITMIME
250-BINARYMIME
250 CHUNKING
quit
221 2.0.0 Service closing transmission channel
Connection closed by foreign host.
I can't help but notice the lack of the "250-STARTTLS" line there -- it is present when I Telnet to port 465.
Using the EMC and the Get-ReceiveConnector
cmdlet, the two receive connectors are essentially identical. So why won't the one on 587 -- the one that clients are supposed to use for SMTP -- not work over TLS nor authenticate trusted domain users? Why does one receive connector -- the one that's supposed to just be for the Exchange servers to talk to each other -- work, while a seemingly-identical one not?
First check whether the Tls AuthMechanism is enabled on the connector:
If this is not the case, enable it:
Then also make sure that you have a certificate for the Smtp service registered:
Finally verify everything: http://www.checktls.com/index.html