MTA-STS is a newish IETF spec that lets mail operators declare that
all of their incoming mail servers support STARTTLS.  (See RFC 8461.)

The idea is to preclude mailstream hijacking. If a domain publishes
MTA-STS, it says what what the names MX'es should be; Before they
start sending mail, client systems check that STARTTLS works, and (if
MTA-STS is in enforced mode) that the TLS certificate from the mail
server is the right one. If not, the mail is presumably about to be
hijacked by a middlebox and the sending system doesn't send it.

For example, here's where you can find the MTA-STS for my

The big gorilla mail systems are implementing this now that they all
have STARTTLS support.

A detail a lot of people forget is that a mail server can have
multiple names, just like a web server can. During the TLS startup,
the client system sends SNI saying what name it expects, so the server
can send the correct certificate. At least that's the plan -- in my
experience a lot of mail client software doesn't send SNI, so MTA-STS
verification fails on servers with multiple names since the server
sends a default certificate that isn't the one the client expects.

Looking at the mail logs for my servers, it's pretty clear that Exim doesn't send SNI. I would also guess that if an Exim MTA has multiple names, it doesn't have any way to select a certificate using SNI. This is not hard to fix; I added SNI support to the mailfront SMTP daemon in a couple of hours. It took longer to get all the certificates signed.

FYI, it's not just me. Real systems use multiple names, e.g., Tucows'
large whitelabel mail service has a unique MX name for each hosted
domain, like this:

 $ host mail is handled by 0
 $ host mail is handled by 10
 $ host mail is handled by 0

If you're keeping score, Gmail gets SNI correct, Microsoft's
doesn't, but I think I've found the right people to fix it.


## List details at
## Exim details at
## Please use the Wiki with this list -

Reply via email to