MTA-STS explained

What is MTA-STS, and what is it for?

Last week, Google announced that they'd made email more secure by adopting the new MTA-STS internet standard (RFC8461). Many sites published articles about this, some claiming Google had made email ultra-secure and that this new standard would fix everything that's wrong with it.

Most of these articles contained comments from people making weird assumptions that they would now have to buy expensive certificates and make complex and time-consuming alterations to their servers if they wanted to continue exchanging email with Google. Some even implied that Google is abusing its power by forcing adoption and that the EU should make every effort to stop them (I'm not making this up).

SMTP MTA Strict Transport Security?

Let me try to explain what SMTP MTA Strict Transport Security (SMTP MTA-STS for short) really does and how it does indeed make email a bit better. Let's start by explaining how email transport works and dive into the weaknesses.

Whether you use the SMTP server from your internet service provider (ISP) or use a service like Gmail, email is not sent directly from your outbox to the recipient's inbox. Instead, the message is transferred from one server to another. This is done through a protocol known as SMTP.

This SMTP communication between servers can be done with encryption to avoid manipulation or eavesdropping. But pay close attention to the word can. An attacker could perform a man-in-the-middle (MiTM) attack by deleting parts of the unencrypted communication that initiate the encryption (STARTTLS). Doing so makes the sending SMTP server think that the receiving server does not support encryption and starts sending the message unencrypted. This allows the attacker to read and even manipulate the data.

Another type of attack would be to change the address of the recipient's server altogether by overwriting the resolved MX record (the recipient's mail server address). The sending server would then deliver the data straight to the attacker's SMTP server. While the communication can then still be encrypted, the received data after the transmission is not.

How does MTA-STS work?

MTA-STS is a mechanism that instructs an SMTP server that the communication with the other SMTP server MUST be encrypted and that the domain name on the certificate should match the domain in the policy. It uses a combination of DNS and HTTPS to publish a policy that tells the sending party what to do when an encrypted channel cannot be negotiated.

DANE

Sound familiar? You're right; it does sound like DANE (DNS-Based Authentication of a Named Entities). DANE and MTA-STS serve the same purpose, but DANE requires DNSSEC for DNS authentication, while MTA-STS relies on certification authorities. In addition, MTA-STS provides an optional testing-only mode, allowing you to deploy a policy without breaking anything.

DANE VS MTA-STS

Most people agree that DANE is superior to MTA-STS as it is easier to deploy, works with self-signed certificates, and does not require MTAs to cache policies. The problem is that not everyone wants to adopt DNSSEC because, in some situations, this is undesirable or impractical. However, MTA-STS is designed not to interfere with DANE deployments when the two overlap. So, if you're using DNSSEC, you don't have to choose—you can implement both.

Ultra-secure?

Unfortunately, MTA-STS does not make email secure. Although MTA-STS and DANE ensure that email is exchanged encrypted, and the recipient server is verified, it does not protect email from someone with access to the servers. Most email is stored in plain text on servers and can be read by anyone with access to the data files.

Can I deploy an MTA-STS policy?

If your mail server supports STARTTLS encryption, and you've got signed certificates installed in your mail and web server, you should publish an MTA-STS policy. No signed certificate yet? You can get them for free by using Let's Encrypt.

Hosted MTA-STS service

To save yourself the trouble of setting up a secure web server and publishing and managing an MTA-STS policy manually, we offer a Hosted MTA-STS service at no extra charge with our Pebble Plus, Stone, Mountain, and Himalaya subscriptions. Just add two CNAME records to the domain, and you are done. For more details about our Hosted MTA-STS service, please visit this blog.

Do it yourself? Let's get started!

Simply add two DNS records and host a text file within the ".well-known" folder on a properly secured subdomain of your domain. The first DNS record to add is a "_mta-sts" TXT record containing the version and an id.

_mta-sts.example.com.	IN	TXT	"v=STSv1; id=20160831085700Z;"

The id is used to track policy updates. This allows the sending server to determine when the policy has been updated. The second DNS record is an 'mta-sts' (without an underscore at the beginning) A or CNAME record that points to the server publishing the policy.

The policy should be made available at the following location: https://mta-sts.example.com/.well-known/mta-sts.txt and look something like this:

version: STSv1
mode: testing
mx: mail.example.com
mx: *.example.net
mx: backupmx.example.com
max_age: 604800

This will let any MTA-STS supporting mail server know that you want them to obey your policy. Note that testing mode does not prevent messages from being sent over an unencrypted channel or to a malicious server. If you are confident that everything is configured accurately, you can change the mode to enforce.

mode

You can configure the mode to be either enforce, testing, or none, indicating the expected behavior of the sending email server in case of a policy validation failure.

"enforce": The sending server will not deliver the message to the receiving server.
"testing": Messages will be delivered as though there was no failure but a report will be sent if TLS-RPT is configured (see below).
"none": Can be used to remove MTA-STS. The server will treat the policy as though it does not have any active policy.

mx

One or more patterns matching allowed MX hosts for your domain. Put each host on a new line with the mx: prefix if you have multiple.

max_age

This specifies the maximum lifetime of the policy in seconds (maximum value of 31557600). Mail servers will cache your policy up to this value from the last policy fetch time. To mitigate the risks of attacks at policy refresh time, it is expected that this value would typically be in the range of weeks or longer.

* UPDATE: Google will only process policies with a max_age higher than 86000 seconds. Policies with a max_age of 86000 or lower will be ignored, and a daily no-policy-found report will be sent if TLS-RPT is enabled (see "Monitoring and reporting" below).

Everything okay?

If you want to check whether your policy and DNS records are configured correctly, you can test them on our tools page here.

Monitoring and reporting (with URIports)

Just like with DANE, you could (and should) use SMTP TLS-RPT to enable mail servers to let you know how your policy is performing and whether any violations of your policy have come to pass. This will also keep you posted on expired certificates and other TLS-related issues.

You can add TLS-RPT by adding another TXT DNS record containing the rua (aggregate report URI) that reports should go to:

_smtp._tls.mail.example.com.	IN	TXT	"v=TLSRPTv1;rua=mailto:tlsrpt@example.uriports.com"

The sending mail server will send you a daily aggregate report containing helpful information about all the messages they've sent you. These reports contain a (compressed GZIP) JSON file like this:

{
     "organization-name": "Company-X",
     "date-range": {
       "start-datetime": "2016-04-01T00:00:00Z",
       "end-datetime": "2016-04-01T23:59:59Z"
     },
     "contact-info": "sts-reporting@company-x.example",
     "report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be",
     "policies": [{
       "policy": {
         "policy-type": "sts",
         "policy-string": ["version: STSv1","mode: testing",
               "mx: *.mail.company-y.example","max_age: 86400"],
         "policy-domain": "company-y.example",
         "mx-host": "*.mail.company-y.example"
       },
       "summary": {
         "total-successful-session-count": 5326,
         "total-failure-session-count": 303
       },
       "failure-details": [{
         "result-type": "certificate-expired",
         "sending-mta-ip": "2001:db8:abcd:0012::1",
         "receiving-mx-hostname": "mx1.mail.company-y.example",
         "failed-session-count": 100
       }, {
         "result-type": "starttls-not-supported",
         "sending-mta-ip": "2001:db8:abcd:0013::1",
         "receiving-mx-hostname": "mx2.mail.company-y.example",
         "receiving-ip": "203.0.113.56",
         "failed-session-count": 200,
         "additional-information": "https://reports.company-x.example/
           report_info ? id = 5065427 c - 23 d3# StarttlsNotSupported "
       }, {
         "result-type": "validation-failure",
         "sending-mta-ip": "198.51.100.62",
         "receiving-ip": "203.0.113.58",
         "receiving-mx-hostname": "mx-backup.mail.company-y.example",
         "failed-session-count": 3,
         "failure-error-code": "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED"
       }]
     }]
}

Reading and interpreting these reports can be a difficult task for a human. Thankfully, URIports has a solution that allows you to easily manage your reports and let you know exactly when something needs your attention.

TLS-RPT monitoring with URIports

Privacy

The TLS-RPT reports do not contain any content from the email messages themselves, and we at URIports do not use any data for anything other than providing you with a clear view of all your reports. Nothing is shared or sold, so your reports are safe with us.