Securing Inbound Email Transport with MTA-STS and STARTTLS-Everywhere

Friday 27th December 2019

The web security ecosystem has matured significantly over the past few years, partly thanks to organisations like Let's Encrypt and the ACME protocol, as well as because of encouragement from browser vendors for websites to implement HTTPS and other security controls such as Content Security Policy.

However, the email ecosystem unfortunately hasn't seen such levels of development. Existing technologies for securely transporting emails, such as STARTTLS, are not as resistant to attacks as their web-based counterparts, and the implementation methods available to sysadmins are far more limited.

In this blog post I'm going to talk about three new email security technologies: MTA-STS, TLSRPT and STARTTLS-Everywhere. These allow you to have greater control and insight into how your emails are securely transported. In this post I will focus on security and reporting for inbound/incoming emails, however in the future I may also cover outbound/outgoing emails.

Skip to Section:

Securing Inbound Email Transport with MTA-STS and STARTTLS-Everywhere
┣━━ MTA-STS
┣━━ Enabling MTA-STS For Inbound Email
┣━━ TLSRPT
┣━━ Enabling TLSRPT For Your Domain
┣━━ Interpreting TLSRPT Reports
┣━━ STARTTLS-Everywhere
┣━━ Adding Your Domain to the STARTTLS-Everywhere Policy List
┗━━ Conclusion

MTA-STS

MTA-STS (Mail Transfer Agent Strict Transport Security) is a new internet standard (RFC8461) which allows you to advertise a force-TLS policy for your domain by hosting a plaintext policy file at a specific location. Supported MTAs (Mail Transfer Agents) will then automatically read this policy when they send email to you, and force the connection to use TLS with a valid certificate. It is very similar to HTTP Strict Transport Security, which is a web security header used by websites to instruct browsers that future connections should be conducted over HTTPS only.

At the time of writing, the only large provider to have implemented MTA-STS is Google Mail. However, it is likely that many other providers such as Office 365 and FastMail will follow along in the future.

MTA-STS works on a TOFU (Trust On First Use) basis, meaning that once a policy is read at least once, it will be cached by the MTA for a specified length of time. This does technically mean that an attacker could defeat MTA-STS by preventing a victim MTA from ever making a request to the MTA-STS policy file hosted on the recipient's domain, however in most cases this isn't a significant concern. However, a mitigation for this is STARTTLS-Everywhere, which is discussed later in this blog post.

Enabling MTA-STS For Inbound Email

In order to enable MTA-STS for incoming email, you'll first need to create and host a policy file. MTA-STS policy files are plaintext files that must be accessible via HTTPS at the /.well-known/mta-sts.txt file path on the mta-sts subdomain. For example, a valid MTA-STS policy file path would be https://mta-sts.example.com/.well-known/mta-sts.txt.

An example of a policy file is shown below:

version: STSv1
mode: enforce
max_age: 86401
mx: mail1.example.com
mx: mail2.example.com

The file contains a selection of 4 standard directives:

Your policy file must be served over a valid HTTPS connection using the text/plain MIME type at exactly the /.well-known/mta-sts.txt path on the mta-sts subdomain.

Warning!

Enabling MTA-STS in enforce mode means that email deliverability will be directly dependent on TLS being enabled and a valid certificate being served on all of your mail servers. If your certificate expires or becomes otherwise invalid, or if your TLS implementation becomes non-functional, some emails sent to you may not get through.


Any updates to your mail server setup may also need to be reflected in your MTA-STS policy file, for example adding/removing/adjusting MX records.


It is recommended to first enable MTA-STS in testing mode, and use the associated TLSRPT standard (which is also discussed in this blog post) to verify that deliverability has not been impacted.

In addition to hosting a policy file, you also need to add a DNS TXT record under the _mta-sts label. This is used to indicate to supported MTAs that they should check for a policy file and enable MTA-STS using the specified mode if one is found.

An example of a valid DNS record for MTA-STS is below:

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

The DNS record contains just 2 standard directives, both of which are mandatory:

You don't need to specify the URL or path to your mta-sts.txt policy file anywhere in the DNS record, as the path is standardised within the specification.

Once you have hosted your policy file and set the required DNS record, MTA-STS will be enabled for your domain. You can use an MTA-STS validator in order to verify your configuration.

TLSRPT

MTA-STS is directly complemented by TLSRPT (SMTP TLS Reporting, RFC8460), which is a reporting mechanism that allows you to collect information on whether emails are successfully being delivered over TLS, as well as any errors that may have occurred (e.g. an expired certificate).

TLSRPT works in a very similar way to DMARC reporting. You specify a reporting endpoint (a URL or an email address) via a DNS record, which then causes email service providers to send you daily reports in JSON format.

Enabling TLSRPT For Your Domain

TLSRPT is enabled by setting a DNS TXT record under the _smtp._tls label to specify that you'd like to receive reports and where these should be sent. You'll need to have MTA-STS configured and enabled as well, in either testing or enforce mode.

An example of a valid TLSRPT record is shown below:

_smtp._tls.example.com IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com,https://reports.example.com/tlsrpt/"

Like MTA-STS, the DNS record for TLSRPT contains just 2 standard directives, both of which are mandatory:

Once you have enabled MTA-STS and TLSRPT, you should receive your first report within 48 hours, as long as an email provider which supports MTA-STS and TLSRPT (such as Google Mail) sends at least one email to an address on your domain.

Note:

In the event that sending MTAs cannot comply with your MTA-STS policy (e.g. if the certificate on your mail server expires, etc), TLSRPT emails will still be delivered. This is explicitly stated in the standard (section 5.3.1) in order to ensure that report emails will always get through, no matter whether they are delivered securely or not:

Interpreting TLSRPT Reports

Reports will be delivered in the form of a JSON payload, usually compressed using gzip. The .json.gz file will be HTTP POST-ed to an API endpoint or sent as an email attachment to the address(es) that you specified in the TLSRPT DNS record.

You can decompress gzipped reports using gzip -d report.json.gz. You can then prettify the resulting JSON using jq . report.json or python -m json.tool report.json.

An example of a TLSRPT report is shown below (prettified JSON):

{
    "organization-name": "Google Inc.",
    "date-range": {
        "start-datetime": "2019-12-11T00:00:00Z",
        "end-datetime": "2019-12-11T23:59:59Z"
    },
    "contact-info": "smtp-tls-reporting@google.com",
    "report-id": "2019-12-11T00:00:00Z_example.com",
    "policies": [
        {
            "policy": {
                "policy-type": "sts",
                "policy-string": [
                    "version: STSv1",
                    "mode: enforce",
                    "mx: mail1.example.com",
                    "mx: mail2.example.com",
                    "max_age: 86401"
                ],
                "policy-domain": "example.com"
            },
            "summary": {
                "total-successful-session-count": 773,
                "total-failure-session-count": 0
            }
        }
    ]
}

This report shows that Google's MTA (for Gmail and G Suite) successfully detected an MTA-STS policy for the domain example.com, and that there were 773 successful TLS sessions (emails delivered from Google's MTA to your domain) during the report timeframe.

Note:

One TLS session is not necessarily equivalent to one email, as in some cases multiple emails will be delivered over the same TLS session. However, the session count is a good rough guidance number for the total number of delivered emails in the majority of cases.

I personally use the URIports service as my reporting endpoint, which will automatically process reports, produce a graph showing deliverability, and can be configured to send alerts if a failure is reported.

STARTTLS-Everywhere

STARTTLS-Everywhere is a project founded by the EFF with the goal of creating a globally shared list of mail servers that are known to support STARTTLS.

The purpose of this list is to act as a point of reference for mail servers to know whether other mail servers support STARTTLS, prior to actually connecting to them and trying. This means that emails can be delivered between secured domains over TLS by default, rather than having to negotiate a secure/insecure connection.

Implementing STARTTLS-Everywhere means that man-in-the-middle and/or downgrade attacks against the email transport would be significantly more complex to carry out, as the bar is raised from having network-level access to now also requiring a valid certificate for the victim mail server.

STARTTLS-Everywhere is essentially HSTS Preload, but for email.

Adding Your Domain to the STARTTLS-Everywhere Policy List

Adding your domain to the list will result in incoming email from supported providers being delivered over forced TLS by default, even if your MTA-STS policy hasn't yet been cached by the sending mail server. In other words, STARTTLS-Everywhere eliminates the TOFU (Trust On First Use) aspect of MTA-STS.

If you also wish to utilise the STARTTLS-Everywhere list for outgoing email, you'll need to install the list on your mail server and configure it to force TLS connections to domains present on the list. I won't be covering this in the current article, however the EFF have published a Python utility to automatically update the list and generate config files for using the list with Postfix.

Before submitting your domain to the list, you can perform a preliminary security check on your domain using the form on the STARTTLS-Everywhere homepage. This will check whether your domain has implemented MTA-STS, and whether your mail servers support STARTTLS with a valid certificate and strong TLS configuration. It also checks whether your domain is already on the STARTTLS-Everywhere list.

A screenshot of the STARTTLS-Everywhere domain check results for jamieweb.net, showing that my mail servers support STARTTLS, but that I am not yet on the policy list.

If your domain check results are all OK, you can proceed to the STARTTLS-Everywhere submission form in order to add your domain.

A screenshot of the STARTTLS-Everywhere submission form, with the details filled in for jamieweb.net.

It helps massively if you have already implemented MTA-STS, as the form can just pull a list of mail servers from your hosted mta-sts.txt policy file. Otherwise, you'll have to manually enter each of the mail servers which are authorised to process mail for your domain.

Once you have completed the form, a verification email will be sent to the postmaster mailbox on your domain.

A screenshot of the confirmation prompt after filling in the form, asking me to check my email to view the verification message that has been sent.

Once you have received the verification email and visited the verification link, your domain will be queued for addition to the list.

A screenshot of the completed verification, confirming that my domain has been successfully queued for addition to the list.

Your domain will continue to be assessed for security and compliance for a period of time before being added to the list. If for any reason your domain ceases to be compliant (e.g. if you stop supporting STARTTLS, your certificate expires, etc), you will be removed from the queue and will have to re-submit.

You'll receive a confirmation email once you've been fully added to the list (which may take several weeks), however in the meantime you can run the domain security check again to view your status in the queue.

A screenshot of the STARTTLS-Everywhere domain security check, showing that my jamieweb.net domain is currently queued for addition to the list.

Once you receive your confirmation email, you can view the full, raw policy list and have a look for your domain!

Email providers which implement the STARTTLS-Everywhere policy list will now connect to your mail servers securely by default, no matter whether an MTA-STS policy has been cached or not.

Conclusion

I am hoping that adoption of MTA-STS and utilisation of the STARTTLS-Everywhere policy list will continue to increase, however support for both of these is currently quite limited, especially in proprietary email systems/services used by many large enterprises and governments.

I have also recently written a full end-to-end step-by-step guide on implementing MTA-STS and TLSRPT, including setting up a web server to host your policy file. This was done as part of my freelance writing work for DigitalOcean, so feel free to take a look if you'd prefer more of a tutorial-style article.

This article is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.