View all of our Customer and Partner Stories from the MSOnline Blog
See who picked BPOS over the competition
Read past blog posts from This Week in BPOS News
View recordings of webinars
Watch Executive Videos
Microsoft Online Services Announcements
Get walkthroughs and help with these posts that show you "How To"
Review the Header information for TLS, which indicates that the message was delivered using TLS:
Note: Perform this test in the opposite direction to make sure TLS is being used in both directions
Exchange Hosted Services (EHS) front-ends all Microsoft Online Mail and uses Deterministic TLS when sending/receiving messages, which means that it will attempt to send/receive mail via TLS (issuing EHLO statements to understand the message servers capabilities).
On-Premise à TLS à EHS à TLS à Microsoft Online Services
Microsoft Online Services à TLS à EHS à TLS à On-Premise
Note: IF TLS is not available anywhere along this path, delivery will fallback to SMTP port 25 and deliver in clear-text.
If a customer requires full TLS Messaging Transport capabilities, they will need a TRUSTED certificate (a certificate that can be verified and is trusted – Verisign, GoDaddy, etc.) on their On-Premise Exchange Bridgehead Server, so when MS Online/EHS delivers mail, it can properly negotiate the TLS session. ALSO, the On-Premise Exchange Admin must configure their SMTP Connector to use Outbound Security – TLS, in order to request a TLS session for any Address Namespaces (i.e. contoso1.microsoftonline.com) defined for that Connector.
This is great that TLS will be supported.
I am curious though, why won't the MTLS features take effect if a customer has Exchange 2007 on-site?
Also for those customer's who want to have private certificates, is there anything on the roadmap to allow private certs between the on-site email system and Exchange Online?
Hi Josh, EHS does not require a client (sending server) certificate, so we wouldn't do MTLS. EHS provides it's certificate, which is a commonly used certificate, which is trusted by ALL Windows machines. As a result, the sending server is able to successfully able to establish a TLS connection and deliver the message.
When EHS attempts to deliver a message to an On-Premise Messaging server (Coexistence), it will attempt a TLS connection and if enabled on the receiving server AND is using a certificate that can be validated (Not expired, on a CRL and the Common Name matches), then EHS will deliver using TLS.
So that end, private certificates cannot be used when receiving mail from an EHS endpoint over TLS.
I hope this helps
....Ryan
Verify Microsoft Online Services Transport Layer Security (TLS) E-mail Delivery - Microsoft Online Services Team Blog - Site Home - TechNet Blogs