1. 10
  1. 12

    In a nutshell, MTA Strict Transport Security (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 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)

    1. 2

      Oh, yeesh. I’ve only followed development of STS to the extent I knew it was a thing. No idea about the web server aspect. That’s weird. Good commentary.

      1. 1

        Looks like what they’re going for is being secure against spoofing the policy, even if it’s not possible to protect against completely stripping it (when not cached). Yeah, a bit weird – if someone mitms DNS, removing the header would be enough.

        1. 1

          The reason HTTPS is used is that the policy is validated with a TLS certificate. The whole thing has been introduced to have an alternative to DNSSEC-based mechanisms, because DNSSEC exists since more than a decade and hasn’t been adopted.

          Many people who are used to how things are done in E-Mail and DNS scratch their heads and don’t understand MTA-STS, because it’s doing things differently. They use HTTPS because HTTPS works and is successful. It is a good idea to use a security mechanism that works and build something on top of it.

          1. 3

            I think the question is more about the http part of https and not the s part.

        2. 7

          MTA-STS reintroduces a security problem which we deliberately cut out of DANE when the spec was locked down to forcibly exclude Usages 0 and 1 of the TLSA records (PKIX-TA and PKIX-EE). In effect, those usages said “if you want to send to me with security, you must trust this explicit Certificate Authority, not only for me, but also for all other sites on the Internet, including those not using DANE”. No site has any legitimate business decreeing who you must trust by default for communicating with others, so those Usage modes were excluded.

          The basic problem is “the mail must flow” and when mail doesn’t flow, The Boss comes breathing down the Postmaster’s neck, demanding that mail flow now, even if the other side is the cause of the issues. They’re violating spec by putting IP addresses directly in MX records? Who cares that it’s a spec violation, get the mail flowing. They’re saying that you must trust Symantec as a CA, for all sites? Who cares, do it.

          With DANE Usage modes, we got away from that: the secure DNS tells you either which certificate (DANE-EE, Usage 3) or which CA (DANE-TA, Usage 2) you need to trust for sending mail to just that one domain, with no influence over any other sites you send email to.

          But now the CA chosen for the HTTPS certificate for the mta-sts host becomes one which must be trusted for that site, and all others, unless developers come up with some mechanism to introduce conditional trust stores. So that one big “national company most people despise and which is known for their technical ineptitude, but we have to be able to send email to them” now can get you back to trusting Malfeasance CAs for everyone.

          The whole security model of the CA system is based upon the fiction that end-users can read CA Certification Practice Statements, evaluate the trade-offs, consider indemnity and so forth, and then decide to trust that CA for themselves without influencing anyone else. (If you think I’m exaggerating here, go back and look at the old claims for the CA system). This model is fundamentally inappropriate for backend item routers for federated systems.

          In practice, Google etc don’t want to implement DNSSEC and so while many smaller operators are deploying DANE and DNSSEC (Viktor Dukhovni puts out monthly stats showing the growth) if you want to offer some security for messages sent to your users from the likes of Google, then you have to publish mta-sts records and set up a webserver. We can suck it up and do that.

          AFAIK there are no plans by any Exim Developer to implement client support for MTA-STS. We’d be doing our users an active mis-service to actively promote this as anything more than something which we have to do to provide crutches for big companies to keep them from having to figure out DNSSEC.

          1. 1

            This seems to be somewhere between true and not actually a problem? The same situation exists for browsers, where any random site might demand you use some other CA, yet my own efforts to do so have met with limited success. In practice, chrome and Firefox work out a trusted list, and if you want to be on the web you use one of those CAs.

            Given that google sponsored this proposal, and receiving email from gmail is a priority for most sites, who is going to setup their incoming mail server to use a cert that google won’t trust?

            1. 2

              So our security boils down to “people will only use a cert from a CA which $OneBigCompany trusts and so as long as $OneBigCompany rotates bad CAs out of the trust for their mail platform, everyone else will have to follow suit” ?

              That has a kind of grotesque elegance to it. Completely against how Internet standards normally enforce security, but it will probably work.

              For a while. Right up until Google try to stop trusting a Large CA, while Microsoft and Yahoo continue trusting it, and Google get hit with an anti-trust lawsuit and we discover that we can no longer rotate out CAs.

              1. 1

                Aren’t most MTAs already using your system’s CA store (which is typically Mozilla’s ca_root_nss)?

                1. 1

                  MTAs by default typically don’t verify certs, since there’s no trustworthy meaningful identifier to assert and by spec they have to fallback to plaintext, so failure to verify terminating TLS would just retry with plaintext. Thus why disabling old protocols and ciphers which are still in use is not a forcing function to improve security but counter-productive. Not only are self-signed certs widespread, but anonymous TLS is seen in the wild too.

                  The old approach was to manually configure better behavior by mutual consent or spotting a published policy.

                  It’s only with DANE, and now MTA-STS, that there’s a federated system for changing the default behavior. MTA-STS provides TOFU protection, as long as you trust the CA ecosystem to not mis-issue. DANE provides protection including on first connection, and pins down (either by certificate or public key) either the CA or the certificate for the site. But DANE requires DNSSEC, which is steadily growing but still not predominant.

                2. 1

                  I mean, I agree it could have problems, but in practice google/chrome have done more to nuke more rogue CAs than anybody.

                  I too wish the web trust model were other than it is, but I’d at least like the web and email trust models to be coherent.

            2. 4

              HTTPS is able to implement Strict-Transport-Security by combining:

              • a header in response to the first visit that says STS is turned on
              • a permanent list, maintained in the browser, of all sites that have ever turned on STS
              • once STS is turned on, it can never be turned off

              As the spec itself says, STARTTLS is normally triggered by a feature flag sent at protocol set-up. Why not serve an STS flag at the same time, and have a list maintained by the MTA that prevents downgrades from happening, exactly like HTTP Strict-Transport-Security does? Why all this complexity?