Aaron Poffenberger

In its abstract we learn that RFC8461 defines a new mechanism for publishing MTA Strict Transport Security policies:

SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers (SPs) to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate.

As we continue reading, we learn that MTA-STS is a mechanism to publish SMTP security policies via DNS and HTTPS. DNS is used to publish an id that is changed whenever the policy changes, and HTTPS to publish the policy itself. The policy covers:

  • whether MTAs sending mail to this domain can expect PKIX- authenticated TLS support

  • what a conforming client should do with messages when TLS cannot be successfully negotiated

An SMTP security policy is itself a good idea. It solves the problem of a MITM stripping the STARTTLS option during initial negotiation, or at least warns the sending MTA that there's something wrong and what to do if a TLS sessions can't be created.


It's the requirement to publish the policy via https I find at best odd. I don't see a good justification in the RFC for this "mechanism" to require a web server in addition to DNS. Yes, I get it. DNS records can only be so long, yet we have protocols like SPF and DKIM that function just fine without a web server.

In the RFC, MTA-STS is described as an alternative to DNSSEC, but it doesn't solve the problem of unsigned DNS records. While the policy itself is served via https from a web server that must present a valid certificate, the mechanism still depends on DNS. The policy is published at a well-known location, at a well-known Policy-Host name resolved by DNS. So you have two required components of the mechanism that require DNS.

There's no way to implement this mechanism without DNS look-ups, so it's not a secure alternative to DNSSEC. It's just an alternative.

One might think speed and efficiency are the reason. Perhaps https (or more likely http2) are faster than DNS, but like HSTS, the policy is meant to be cached. Policy invalidation is handled by DNS look-ups that return the Policy ID which indicates the current policy is no longer current. Trading speed (assuming http/2 are faster than DNS) for a one-time look-up and then going back to DNS for invalidation look-ups makes little sense.

Lastly, it deviates from other SMTP policy mechanisms like SPF, DKIM, and DMARC which all rely on DNS. That alone is a strong argument for not adding a web server to host the policy.


I'm left scratching my head. Requiring a web server to host the MTA-STS policy seems like a gratuitous addition, using two protocols to serve the purpose of one. And worse, complicating SMTP daemons everywhere. To implement this mechanism, SMTP daemons can no longer rely on the OS resolver. They need a minimal https client. More code paths. More opportunities for failure.

Further Reading

Introducing MTA Strict Transport Security (MTA-STS)

From a post originally made on Lobste.rs.