Do we need SMTP MTA Strict Transport Security (MTA-STS)?

I was not planning to add support for MTA-STS for my domain as I’ve previously deployed DANE for SMTP transport security. MTA-STS is an alternative solution that does not require DNSSEC for authentication but instead relies on certification authorities.

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.
Source: RFC 8461

Security model

The main concern with MTA-STS is that it relies on DNS TXT records for policy discovery and implements the trust on first use (TOFU) security model. And therein lies the flaw as we can’t reliably trust DNS without DNSSEC. Sure, that’s no different from HTTP-STS (HTTP Strict Transport Security), but then again, we don’t have a working HSTS preload list equivalent solution for mail servers.

However, Google is steering the MTA-STS train full steam ahead, so I decided to jump on board for the ride. After all, it’s easy to publish an MTA-STS policy, and it’s designed to not interfere with DANE.

How does it work? Google, email me!

1) Google performs a DNS TXT query against _mta-sts.paranoidpenguin.net to discover the availability of an MTA-STS policy:

; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_mta-sts.paranoidpenguin.net.	IN	TXT

;; ANSWER SECTION:
_mta-sts.paranoidpenguin.net. 900 IN	TXT	"v=STSv1; id=1586698235;"

2) Google then retrieves the policy by performing a GET request over HTTPS for mta-sts.paranoidpenguin.net/.well-known/mta-sts.txt:

3) Google verifies the domain policy and delivers the email, granted that the requirements in the policy (mta-sts.txt) can be fulfilled. Mode: enfore will not allow delivery if the certificate validation fails, or if STARTTLS is unavailable:

version: STSv1
mode: enforce
mx: server3.paranoidpenguin.net
mx: *.paranoidpenguin.net
max_age: 604800

4) Google also provides me with a daily report detailing our secure communication attempts (SMTP TLS reporting). I like this part:

{
    "organization-name": "Google Inc.",
    "date-range": {
        "start-datetime": "2020-04-18T00:00:00Z",
        "end-datetime": "2020-04-18T23:59:59Z"
    },
    "contact-info": "smtp-tls-reporting@google.com",
    "report-id": "2020-04-18T00:00:00Z_paranoidpenguin.net",
    "policies": [{
        "policy": {
            "policy-type": "sts",
            "policy-string": ["version: STSv1", "mode: enforce", "mx: server3.paranoidpenguin.net", "mx: *.paranoidpenguin.net", "max_age: 604800"],
            "policy-domain": "paranoidpenguin.net"
        },
        "summary": {
            "total-successful-session-count": 5,
            "total-failure-session-count": 0
        }
    }]
}

Wow… MTA-STS is awesome, right?

So, is that all it takes to enforce encrypted connections between mail servers? Well, you might be left with that impression after reading a few articles on MTA-STS. However, publishing an MTA-STA recipient policy for your domain does not automagically enable MTA-STS support between mail servers. As an example, I won’t be adhering to anybody else’s MTA-STS policy when delivering email from my (self-hosted) mail server.

I’ve not come across an open-source mail server solution that implements support for MTA-STS out of the box. As a result, we’re left to implement third party extensions where available. That process is also far more complicated than setting up an inbound MTA-STS policy. The delivery pseudocode from RFC 8461 demonstrates the logic of a compliant sending MTA.

MTA-STS adaptation

After going through a few weeks of logs, I’ve not seen a single email provider besides Google connecting to mta-sts.paranoidpenguin.net and fetching my MTA-STS policy. Other major email providers may publish their MTA-STS policies, but they don’t implement the mechanism on their sending MTAs.

Microsoft announces DANE and DNSSEC

Microsoft recently announced upcoming support for DANE and DNSSEC for Office 365 Exchange Online. I’m hoping this will create some momentum towards DANE instead of MTA-STS. In my opinion, this decision will give Microsoft’s email services a competitive edge compared to Google’s offering, so it might end up forcing Google’s hand.

STARTTLS everywhere

EFF has a project called STARTTLS everywhere where they provide a STARTTLS policy list containing email domains that meet a minimum set of security requirements. It’s like the HTTPS Everywhere extension, but for mail servers. Yeah, that’s probably not going to catch on, but hey, at least I’m in the mix.

In conclusion

MTA-STS is a somewhat unfortunate mechanism that most people agree with is inferior to DANE. Unfortunately, DNSSEC is not gathering much traction so MTA-STS is probably here to stay. I’m happy to publish an MTA-STS policy, but I’m not planning to jump through hoops to get the mechanism implemented on my Postfix mail server.

A year after Google announced that Gmail is making email more secure with MTA-STS, it’s still unclear whether others will follow down this path.