MTA-STS (Strict Transport Security)

MTA-STS (Mail Transfer Agent-Strict Transport Security, STS for short) is a fairly new tool for making sending and receiving mail more secure. MTA-STS has meanwhile been recognized as RFC-8461 and can therefore be used. Similar to DANE, information is stored in the DNS for STS. The big difference, however, is that no DNSSEC is required for STS. Many hosters do not currently support DNSSEC, which means that DANE cannot be used either. STS is intended to provide a remedy here (at least temporarily until DNSSEC and DANE have become established across the board).

Functionality

MTA-STS is intended to prevent mails from being exchanged unencrypted between mail servers; this explicitly concerns communication from mail server to mail server, not communication between mail server and client. The receiving mail server can inform the sending server via DNS that it explicitly supports TLS for transport encryption. Before sending an email, the sending mail server can retrieve an MTA-STS policy from a web server that defines which mail servers accept emails via TLS. The sending mail server saves the policy for a defined period and only delivers emails via TLS for this period. This is intended to prevent an email from being sent without transport encryption, for example if the StartTLS command is suppressed by a MITM attack. In principle, this is forced StartTLS for mail servers from the first mail. Although STS is not as secure as DANE, it is easier to implement as it does not require DNSSEC. As there are still many domains, including mine, that cannot yet be resolved via DNSSEC, STS can be useful here, at least temporarily, until DNSSEC and therefore DANE are implemented.

This Youtube video explains MTA-STS and DANE quite well:

• SMTP STS (Strict Transport Security) vs. SMTP with DANE

Furnishings

Setting up STS is very simple. All you need is a mail server that supports TLS (StartTLS), 3 DNS names and a web server that is accessible via HTTPS.

Web server and MTA-STS policy

First, a policy must be created; for the test operation, this could look as follows for the frankysweblab.de domain, for example:

version: STSv1
mode: testing
max_age: 86400
mx: mail.frankysweblab.de
mx: *.frankysweblab.de

The policy contains the STS version (version), currently only STSv1 is available, the mode in which the policy works (mode: testing for tests mode: enforce for productive) and the time span that a mail server may cache the policy (max_age in seconds). In addition, all mail servers that require and support TLS are specified within the policy. These can be specified individually or as a wildcard (mx).

A productive policy for the domain frankysweblab.de would look something like this:

version: STSv1
mode: enforce
max_age: 15552000
mx: mail.frankysweblab.de
mx: *.frankysweblab.de

Compared to the test policy above, only the mode has changed, as well as the maximum cache duration (mode: enforce and max_age: 6 months 15552000 seconds).

The policy is now saved as a simple text file with the name mta-sts.txt The policy must now be transferred to a web server that is accessible via HTTPS, only http is not sufficient at this point.

In addition, the web server must be accessible under the name mta-sts.domain.de. For the domain frankysweblab.de, the web server must therefore be accessible under the domain mta-sts.frankysweblab.de. The policy is now saved in the .well_known directory:

The policy for frankysweblab.de can therefore be accessed via the following link: https://mta-sts.frankysweblab.de/.well-known/mta-sts.txt The URL is fixed and cannot be changed; the domain name of the e-mail address (frankysweb.de, gmail.com) and then the prefix mta-sts and the order .well-known with the policy mta-sts.txt are always required. Here are a few examples:

• https://mta-sts.frankysweb.de/.well-known/mta-sts.txt
• https://mta-sts.gmail.com/.well-known/mta-sts.txt
• https://mta-sts.web.de/.well-known/mta-sts.txt

The certificate for the web server must also come from a trustworthy CA. A self-signed certificate will not work here. Free certificates from Let's Encrypt and wildcard certificates are fine.

DNS entries

In addition to the DNS entry for "mta-sts" for the web server, two TXT records are also required:

• _mta-sts.domain.de
• _smtp._tls.domain.de (This TXT record is not mandatory, but without it the MTA-STS validator will complain)

The _mta-sts.domain.de entry only contains the STS version (v=STSv1) and an ID for the policy as a timestamp (id=20181230231800Z). This results in the following DNS TXT record for the domain frankysweblab.de:

• Name: _mta-sts.frankysweblab.de
• Text: v=STSv1; id=20181230231800Z

The ID must then be adjusted accordingly if the policy changes.

The second TXT record is used for error analysis, mail servers can send information about problems to the stored e-mail address, so it can't hurt to enter a corresponding e-mail address. The following entry results for the domain frankysweblab.de (again, only one version and a corresponding e-mail address must be specified):

• Name: _smtp._tls.frankysweblab.de
• Text: v=TLSRPTv1; rua=mailto:postmaster@frankysweblab.de

Test

First of all, you should check whether all mail servers (MX record) are configured accordingly for TLS; this can be done with the TLS test from CheckTLS check:

The mail server must support at least TLS 1.2 for STS.

The STS configuration can be configured with the MTA-STS validator from Ayke van Laëthem. Only the domain needs to be entered for the test. The result will look something like this:

In this example, it is still a test policy (see Mode testing), which therefore has a short time span (max_age). If there are no problems in test mode, the policy can be switched to production mode (mode enforce), in which case it is also necessary to significantly increase the time span (e.g. 4 - 6 months for max_age).

The web server that delivers the policy can be configured with the SSLTest from Qualys The web server should also achieve a proper ranking here and the certificate should be displayed as trustworthy.

Conclusion

MTA-STS is a good approach in itself, but unfortunately it is still not very widespread. Mail servers and antiSPAM solutions that already support STS are still very rare. As the standard is still very young, this is not very surprising, but you can set it up and help MTA-STS to become established more quickly. However, if the course has already been set for DNSSEC, then the use of DANE should also be considered directly.

A word about Exchange Server: Exchange (incl. Exchange 2019) does not support STS. Here you still have to rely on alternative solutions. However, since Exchange Server is mainly used in internal networks and is usually protected by upstream email security products, the lack of this feature can be ignored.