In short, MTA-STS is a way to additionally protect emails from interception (i.e., attacker-in-the-middle attacks aka MitM) when they are transferred between mail servers. It partially solves the inherited architectural problems of e-mail protocols and is described in the relatively recent RFC 8461 standard. Mail.ru Mail is the first major postal service in the Russian Internet to implement this standard. And in more detail it is already under the cut

What problem does MTA-STS solve?

Historically, e-mail protocols (SMTP, POP3, IMAP) transmitted information in the clear, which allows it to be intercepted, for example, when accessing a communication channel.



What the mechanism for delivering a letter from one user to another looks like:







Historically, a MitM attack was possible in all places where mail goes.



RFC 8314 requires the mandatory use of TLS between the user's mail program (MUA) and the mail server. If your server and the mail applications you use are RFC 8314 compliant, then you have (largely) eliminated the possibility of Man-in-the-Middle attacks between the user and the mail servers.



Adherence to common practices (standardized by RFC 8314) eliminates near user attacks:







Mail.ru mail servers complied with RFC 8314 even before the standard was adopted, in fact, it simply captures the already accepted practices, and we did not have to configure anything further. But, if your mail server still allows users via insecure protocols, be sure to implement the recommendations of this standard, because most likely at least some of your users work with mail without encryption, even if you support it.



The mail client always works with the same mail server of the same organization. And you can force all users to connect in a secure way, and then make it technically impossible to connect insecure (this is exactly what RFC 8314 requires). It is sometimes difficult, but realizable. Traffic between mail servers is still more complicated. The servers belong to different organizations and are often used in a "set and forget" mode, which makes it impossible to switch to a secure protocol at once without breaking connectivity. SMTP has long provided the STARTTLS extension, which allows servers that support encryption to switch to TLS. But an attacker who has the ability to influence trafficcan "cut" information about the support of this command and force the servers to communicate using a plain text protocol (the so-called downgrade attack - an attack to downgrade the protocol version). For the same reason, for STARTTLS, certificate compliance is usually not checked (an untrusted certificate can protect against passive attacks, and this is no worse than sending an email in clear text). Therefore, STARTTLS protects only against passive eavesdropping.



MTA-STS partially eliminates the problem of intercepting messages between mail servers, when an attacker has the ability to actively influence traffic. If the recipient's domain publishes the MTA-STS policy, and the sender's server supports MTA-STS, it will only send the email over a TLS connection, only to the servers defined by the policy, and only with the server certificate verified.



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

How MTA-STS Works

Recipient

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

Sender The



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



When sending mail, it is checked that:

• the server to which 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). For implementation on the recipient side, no special software support for the standard is required.

Disadvantages of MTA-STS

It is necessary to monitor the validity of the web and mail server certificate, the correspondence of the names, and the timely renewal. Issues with the certificate will make it impossible to deliver mail.



On the sender side, an MTA with support for MTA-STS policies is required, currently out of the box MTA-STS is not supported in the MTA.



MTA-STS uses a list of trusted root CAs.



MTA-STS does not protect against attacks in which 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 the MTA-STS less secure than the competing DANE standard for SMTP (RFC 7672), but more technically sound, i.e. for MTA-STS, there is a low probability that the letter will not be delivered due to technical problems caused by the implementation of the standard.

Competing standard - DANE

DANE uses DNSSEC to publish certificate information and does not require trust in external CAs, which is much more secure. But the use of DNSSEC is significantly more likely to lead to technical failures, if you rely on statistics for several years of use (although there is a positive trend in the reliability of DNSSEC and its technical support in general). To implement DANE in SMTP on the recipient side, the presence of DNSSEC for the DNS zone is mandatory, and for DANE, correct support for NSEC / NSEC3 is essential, with which DNSSEC has systemic problems.



If DNSSEC is configured with errors, it can lead to denials of mail delivery if the sending side supports DANE, even if the receiving side does not know anything about it. Therefore, despite the fact that DANE is an older and more secure standard and is already supported in some server software on the sender's side, in fact its penetration remains insignificant, many organizations are not ready to implement it due to the need to implement DNSSEC, this significantly slowed down the implementation of DANE all those years that the standard has existed.



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

What's with MTA-STS support in Mail.ru Mail

Mail.ru has been publishing the MTA-STS policy for all major domains for quite some time now. We are currently implementing the client side of the standard. At the time of this writing, the policies are applied in a non-blocking mode (if delivery is blocked by a policy, the letter will be delivered through a "backup" server without applying policies), then the blocking mode will be forced for a small part of outgoing SMTP traffic, gradually for 100% of traffic policy enforcement is supported.

Who else supports the standard

So far, the MTA-STS policies publish about 0.05% of active domains, but, nevertheless, they already protect a large volume of mail traffic, because the standard is supported by major players - Google, Comcast and partially Verizon (AOL, Yahoo). Many other postal services have announced that support for the standard will be implemented in the near future.

How will this affect me?

Nothing if your domain does not publish the MTA-STS policy. If you publish the policy, messages to your mail server users will be better protected from interception.

How do I implement MTA-STS?

MTA-STS support on the recipient 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) 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:

1. Configure STARTTLS in the MTA you are using (postfix, exim, sendmail, Microsoft Exchange, etc.).
2. , ( CA, , MX-, ).
3. TLS-RPT , ( TLS). ( example.com):
   
   
   
   

   smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:tlsrpt@example.com»

   
   
   TLS SMTP tlsrpt@exmple.com.
   
   
   
   , .
4. MTA-STS HTTPS. CRLF .
   
   
   
   

   https://mta-sts.example.com/.well-known/mta-sts.txt
   

   
   
   :
   
   
   
   

   version: STSv1
   mode: enforce
   mx: mxs.mail.ru
   mx: emx.mail.ru
   mx: mx2.corp.mail.ru
   max_age: 86400
   

   
   
   version ( STSv1), Mode , testing — ( ), enforce — «» . mode: testing, , mode: enforce.
   
   
   
   mx , ( , mx). Max_age ( DNS- , mta-sts DNS).
5. Publish the TXT record to DNS: 
   
   
   
   

   _mta-sts.example.com. TXT “v=STSv1; id=someid;”
   

   
   
   In the id field, you can use an arbitrary identifier (for example, a timestamp), when changing the policy, it should change, this allows senders to understand that they need to re-request the cached policy (if the identifier is different from the cached one).

Support for MTA-STS at the sender



While it is bad, because the standard is fresh.

• Exim - no built-in support, there is a third party script https://github.com/Bobberty/MTASTS-EXIM-PERL 
• Postfix - there is no built-in support, there is a third-party script which is described in detail on Habré https://habr.com/en/post/424961/

As an afterword on "mandatory TLS"

Regulators have been focusing on mail security lately (and that's a good thing). For example, DMARC is mandatory for all government agencies in the United States and is increasingly required in the financial sector; in regulated areas, the standard's penetration reaches 90%. Now some regulators require the implementation of "mandatory TLS" with separate domains, but at the same time, the mechanism for ensuring "mandatory TLS" is not defined, and in practice this setting is often implemented in a way that does not even minimally protect against real attacks that are already provided for in such mechanisms as DANE or MTA-STS.



If the regulator requires the implementation of "mandatory TLS" with separate domains, we recommend considering MTA-STS or its partial equivalent as the most suitable mechanism, it eliminates the need to make secure settings for each domain separately. If you have difficulties with the implementation of the client side of MTA-STS (until the protocol has received widespread support, they most likely will be), you can recommend this approach:

1. Publish the 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 in any case), this will protect traffic in your direction and eliminate the need to ask other mail services to configure mandatory TLS for your domain if the postal service already supports MTA-STS and / or DANE.
2. «» MTA-STS , MX TLS-. MTA-STS, , , . TLS STARTTLS.