In brief, MTA-STS is a method to further protect emails from interception (i.e., man-in-the-middle attacks aka MitM) during transmission between email servers. It partially addresses inherited architectural issues of email protocols and is outlined in the relatively new standard RFC 8461. Mail.ru is the first major email service in the RuNet to implement this standard. More details are provided below.

What problem does MTA-STS address?

Historically, email protocols (SMTP, POP3, IMAP) transmitted information in plaintext, making it susceptible to interception, for example, when accessing communication channels.

Here is how the mechanism for delivering an email from one user to another works:

Historically, MitM attacks were possible at every point where emails traverse.

The RFC 8314 standard mandates the use of TLS between the user's email application (MUA) and the email server. If your server and the email applications you use comply with RFC 8314, you have largely mitigated the risk of man-in-the-middle attacks between users and email servers.

Adhering to established best practices (standardized by RFC 8314) eliminates the threat close to the user:

Mail.ru email servers complied with RFC 8314 even before the standard was adopted; in fact, it merely formalizes already accepted practices, and we had nothing additional to configure. However, if your email server still allows users to connect via insecure protocols, you must implement the recommendations of this standard, as it is likely that at least some of your users are working with email without encryption, even if you support it.

The mail client always connects to the same mail server of the same organization. All users can be forced to connect securely, after which it becomes technically impossible to connect insecurely (this is exactly what RFC 8314 requires). This can be challenging, but it is achievable. Traffic between mail servers is even more complicated. The servers belong to different organizations and are often used in a 'set it and forget it' manner, making it impossible to switch to a secure protocol without disrupting connectivity. SMTP has long had the STARTTLS extension, allowing servers supporting encryption to switch to TLS. However, an attacker who can influence traffic can 'strip' information about the support for this command and force the servers to communicate over the plain text protocol (known as a downgrade attack). For this reason, the validity of the certificate is typically not checked for STARTTLS (an untrusted certificate may protect against passive attacks, and this is no better than sending an email in plain text). Therefore, STARTTLS only protects against passive eavesdropping.

MTA-STS partially addresses the issue of intercepting emails between mail servers when an attacker has the ability to actively influence traffic. If the recipient's domain publishes an MTA-STS policy, and the sending server supports MTA-STS, it will only send the email through a TLS connection, only to servers specified in the policy, and only after verifying the server's certificate.

Why partially? MTA-STS works only if both parties have taken care to implement this standard, and MTA-STS does not protect against scenarios where an attacker has the capability to obtain a valid domain certificate from one of the public CAs.

How MTA-STS Works

Recipient

Sets up STARTTLS support with a valid certificate on the mail server.
Publishes the MTA-STS policy via HTTPS, using a special domain mta-sts and a special well-known path, for example https://mta-sts.mail.ru/.well-known/mta-sts.txt. The policy contains a list of mail servers (mx) authorized to receive mail for this domain.
Publishes a special TXT record _mta-sts in DNS with the policy version. When the policy changes, this record must be updated (this signals the sender to re-fetch the policy). For example, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Sender

The sender requests the DNS record _mta-sts; if present, it makes a policy request over HTTPS (verifying the certificate). The obtained policy is cached (in case an attacker blocks access to it or substitutes the DNS record).

When sending mail, it checks that:

the server to which the mail is delivered is in the policy;
the server accepts mail using TLS (STARTTLS) and has a valid certificate.

Benefits of MTA-STS

MTA-STS uses technologies that are already implemented in most organizations (SMTP+STARTTLS, HTTPS, DNS). No special software support for the standard is required on the recipient's side.

Drawbacks of MTA-STS

It is necessary to monitor the validity of web and mail server certificates, name compliance, and timely updates. Certificate issues will lead to an inability to deliver mail.

On the sender's side, an MTA with MTA-STS policy support is required; currently, MTA-STS is not supported 'out of the box' in MTAs.

MTA-STS uses a list of trusted root CAs.

MTA-STS does not protect against attacks where the attacker uses a valid certificate. In most cases, MitM near the server implies the possibility of issuing a certificate. Such an attack can be detected through Certificate Transparency. Therefore, in general, MTA-STS mitigates but does not completely eliminate the possibility of traffic interception.

The last two points make MTA-STS less secure than the competing DANE standard for SMTP (RFC 7672), but more technically reliable, i.e., for MTA-STS, the likelihood that an email will not be delivered due to technical problems caused by the implementation of the standard is low.

Competing standard — DANE

DANE uses DNSSEC to publish certificate information and does not require trust in external certificate authorities, which is much safer. However, the use of DNSSEC often leads to technical failures, based on statistics from several years of use (although there has been a positive trend in the reliability of DNSSEC and its technical support overall). For DANE to be implemented in SMTP on the recipient's side, DNSSEC is mandatory for the DNS zone, and correct support for NSEC/NSEC3 is essential, which has systemic issues in DNSSEC.

If DNSSEC is misconfigured, it can lead to mail delivery failures if the sending party supports DANE, even if the receiving side is unaware of it. Therefore, despite DANE being an older and more secure standard already supported by some server software on the sender's side, its penetration remains insignificant in practice, as many organizations are reluctant to implement it due to the need to implement DNSSEC, which has significantly hindered DANE's adoption throughout the years that the standard has existed.

DANE and MTA-STS do not conflict with each other and can be used together.

What about MTA-STS support in Mail.ru?

Mail.ru has long published an MTA-STS policy for all major domains. We are currently working on implementing the client side of the standard. At the time of writing this article, policies are applied in a non-blocking mode (if delivery is blocked by the policy, mail will be delivered through a 'backup' server without applying the policies); later, a blocking mode will be enforced for a small portion of outgoing SMTP traffic, gradually applying policies for 100% of the traffic.

Who else supports the standard?

Currently, about 0.05% of active domains publish MTA-STS policies, but nevertheless, they already protect a large volume of mail traffic, as major players like Google, Comcast, and partially Verizon (AOL, Yahoo) support the standard. Many other mail services have announced that they will implement the standard soon.

How will this affect me?

No, unless your domain publishes an MTA-STS policy. If you publish a policy, emails for users of your mail server will be better protected against interception.

How do I implement MTA-STS?

MTA-STS support on the recipient's side

It is enough to publish the policy via HTTPS and DNS records, configure a valid certificate from one of the trusted CAs (Let’s Encrypt is an option) for STARTTLS in the MTA (STARTTLS is supported in all modern MTAs), no special support from the MTA is required.

Step by step, it looks like this:

Configure STARTTLS in the MTA you are using (postfix, exim, sendmail, Microsoft Exchange, etc.).
Ensure a valid certificate is used (issued by a trusted CA, not expired, the subject of the certificate corresponds to the MX record where mail for your domain is delivered).
Configure a TLS-RPT record to receive reports on policy implementation (from services supporting the sending of TLS reports). An example record (for domain example.com):
```
smtp._tls.example.com. 300 IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"
```
This record instructs mail senders to send statistical reports on TLS usage in SMTP to the address tlsrpt@exmple.com.
Monitor the reports for a few days, ensuring there are no errors.
Publish the MTA-STS policy via HTTPS. The policy is published as a text file with CRLF line terminators at the location.
```
https://mta-sts.example.com/.well-known/mta-sts.txt
```
Policy example:
```
version: STSv1
mode: enforce
mx: mxs.mail.ru
mx: emx.mail.ru
mx: mx2.corp.mail.ru
max_age: 86400
```
The version field contains the policy version (currently it is STSv1), Mode specifies the policy application mode, testing — test mode (policy is not applied), enforce — 'production' mode. First, publish the policy with mode: testing; if the policy has no issues in test mode, after some time you can switch to mode: enforce.
The mx field lists all mail servers that can accept mail for your domain (each server must have a certificate configured that corresponds to the name specified in mx). Max_age specifies the caching duration of the policy (once cached, the policy will be applied even if an attacker blocks its delivery or corrupts DNS records during the caching time; the need to request the policy again can be signaled by changing the mta-sts DNS record).
Publish the following TXT record in DNS:
```
_mta-sts.example.com. TXT "v=STS1; id=someid;"
```
You can use any identifier (such as a timestamp) in the id field; when the policy changes, it should change as well, allowing senders to understand that they need to re-request the cached policy (if the identifier differs from the cached one).

MTA-STS support on the sender's side

Currently, it is lacking as the standard is new.

Exim — no built-in support, but there is a third-party script https://github.com/Bobberty/MTASTS-EXIM-PERL
Postfix — no built-in support, but there is a third-party script detailed on Habr https://habr.com/en/post/424961/

As a postscript about 'mandatory TLS'

Recently, regulators have been paying attention to email security (which is a good thing). For example, DMARC is mandatory for all government institutions in the USA and is increasingly required in the financial sector, reaching 90% penetration in regulated areas. Some regulators currently require the implementation of 'mandatory TLS' across individual domains; however, the mechanism for ensuring 'mandatory TLS' is not defined, and in practice, this setting is often implemented in a way that provides minimal protection against actual attacks, which are already addressed by mechanisms like DANE or MTA-STS.

If a regulator requires the implementation of 'mandatory TLS' with individual domains, we recommend considering MTA-STS or its partial analogue as the most suitable mechanism; it eliminates the need to configure secure settings for each domain separately. If you encounter difficulties implementing the client side of MTA-STS (which is likely as the protocol has not yet gained wide support), such an approach can be recommended:

Publish your MTA-STS policy and/or DANE records (it makes sense to add DANE only if DNSSEC is already enabled for your domain, and MTA-STS is mandatory in any case); this will protect traffic to your side and eliminate the need to ask other mail servers to configure mandatory TLS for your domain if the mail server already supports MTA-STS and/or DANE.
For large email services, implement an "analog" of MTA-STS through separate transport settings for each domain, which will fix the MX used for relaying mail and require mandatory verification of the TLS certificate. If the domains are already publishing an MTA-STS policy, this can most likely be done without issues. Simply enabling mandatory TLS for a domain without fixing the relay and verifying the certificate is inefficient in terms of security and adds nothing to the existing STARTTLS mechanisms.

Source: habr.com