简而言之，MTA-STS是一种在邮件服务器之间传输电子邮件时额外保护电子邮件免遭拦截（即中间攻击者又称为MitM）的方法。它部分解决了电子邮件协议的继承体系结构问题，并在相对较新的RFC 8461标准中进行了描述Mail.ru Mail是俄罗斯Internet上第一个实施此标准的主要邮政服务。更详细地说，它已经被削减了。

MTA-STS解决什么问题？

从历史上看，电子邮件协议（SMTP，POP3，IMAP）以明文方式传输信息，例如，在访问通信通道时，它可以被截获。

从一个用户向另一个用户发送一封信的机制是什么样的：

从历史上看，MitM攻击可能在所有邮件到达的地方发生。

RFC 8314要求在用户的邮件程序（MUA）和邮件服务器之间强制使用TLS。如果您的服务器和所使用的邮件应用程序符合RFC 8314标准，则（很大程度上）消除了用户与邮件服务器之间的中间人攻击的可能性。

遵循常规做法（由RFC 8314标准化）消除了近用户攻击：

Mail.ru邮件服务器甚至在该标准被采用之前就已经符合RFC 8314的要求，实际上，它只是捕获了已被接受的做法，因此我们无需进行任何其他配置。但是，如果您的邮件服务器仍然允许用户通过不安全的协议，请确保实施此标准的建议，因为即使您支持邮件，最有可能至少有一些用户使用未加密的邮件。

邮件客户端始终与同一组织的同一邮件服务器一起使用。而且，您可以强制所有用户以安全的方式进行连接，然后使从技术上讲不可能进行不安全的连接（这正是RFC 8314所要求的）。有时很困难，但可以实现。邮件服务器之间的通信仍然更加复杂。这些服务器属于不同的组织，并且通常以“设置并忘记”模式使用，这使得不可能在不中断连接的情况下立即切换到安全协议。 SMTP长期以来一直提供STARTTLS扩展名，该扩展名允许支持加密的服务器切换到TLS。但是有能力影响流量的攻击者可以“剪切”有关此命令支持的信息，并强制服务器使用纯文本协议进行通信（所谓的降级攻击-降级协议版本的攻击）。出于相同的原因，对于STARTTLS，通常不检查证书的符合性（不可信的证书可以防止被动攻击，这不比发送明文电子邮件更糟糕）。因此，STARTTLS仅可防止被动窃听。

当攻击者能够主动影响流量时，MTA-STS可以部分消除在邮件服务器之间拦截邮件的问题。如果收件人的域发布了MTA-STS策略，并且发件人的服务器支持MTA-STS，则它将仅通过TLS连接发送电子邮件，仅发送给策略定义的服务器，并且仅通过验证的服务器证书。

为什么要部分？MTA-STS仅在双方都已认真执行此标准的情况下才起作用，并且MTA-STS不能防止攻击者有机会在其中一个公共CA中获得有效域证书的情况。

MTA-STS如何工作

接受者

使用邮件服务器上的有效证书配置对STARTTLS的支持。
通过HTTPS发布MTA-STS策略，例如，使用特殊的mta-sts域和特殊的知名路径https://mta-sts.mail.ru/.well-known/mta-sts.txt。该策略包含有权接收该域的邮件的邮件服务器（mx）的列表。
使用策略版本在DNS中发布特殊的_mta-sts TXT记录。策略更改时，必须更新此记录（这指示发送方重新请求策略）。例如，_mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

发送

方发送方请求_mta-sts DNS记录（如果可用），通过HTTPS（验证证书）发出策略请求。结果策略将被缓存（以防攻击者阻止对该策略的访问或更改DNS记录）。

发送邮件时，检查以下内容：

邮件发送到的服务器在策略中；
服务器使用TLS（STARTTLS）接受邮件并具有有效的证书。

MTA-STS的好处

MTA-STS使用大多数组织已实现的技术（SMTP + STARTTLS，HTTPS，DNS）。为了在接收方实现，不需要为该标准提供特殊的软件支持。

MTA-STS的缺点

有必要监视Web和邮件服务器证书的有效性，名称的对应关系以及及时更新。证书出现问题将无法传递邮件。

在发送方，需要支持MTA-STS策略的MTA，当前MTA中不支持开箱即用的MTA-STS。

MTA-STS使用受信任的根CA的列表。

MTA-STS无法抵御攻击者使用有效证书的攻击。在大多数情况下，服务器附近的MitM意味着可以颁发证书。可以通过证书透明性检测到这种攻击。因此，通常，MTA-STS可以缓解但不能完全消除流量拦截的可能性。

最后两点使MTA-STS的安全性不及SMTP的竞争DANE标准（RFC 7672），但在技术上更安全，即对于MTA-STS，由于实施该标准引起的技术问题，极有可能无法寄信。

竞争标准-DANE

DANE使用DNSSEC来发布证书信息，并且不需要信任外部CA，这更加安全。但是，如果我们依靠使用数年的统计数据，则使用DNSSEC可能更容易导致技术故障（尽管DNSSEC及其技术支持的可靠性通常呈积极趋势）。为了在接收方的SMTP中实现DANE，DNS区域中必须存在DNSSEC，而对于DANE，对NSEC / NSEC3的正确支持是必不可少的，DNSSEC存在系统性问题。

如果DNSSEC配置有错误，即使发送方支持DANE，即使接收方一无所知，它也可能导致拒绝邮件传递。因此，尽管DANE是一个较旧且更安全的标准，并且已经在发送方方面已在某些服务器软件中得到支持，但实际上其渗透率仍然微不足道，许多组织由于需要实施DNSSEC而尚未准备好实施，这大大减慢了DANE的实施速度该标准已经存在的所有年份。

DANE和MTA-STS彼此不冲突，可以一起使用。

Mail.ru Mail中的MTA-STS支持是什么

Mail.ru已经发布所有主要域的MTA-STS政策已有一段时间了。我们目前正在实施该标准的客户端。在撰写本文时，策略以非阻止模式应用（如果传递被策略阻止，则信件将通过“备份”服务器传递而不应用策略），然后强制将强制模式用于一小部分传出SMTP流量，逐渐用于100％的流量支持策略执行。

还有谁支持该标准

到目前为止，MTA-STS策略发布了约0.05％的活动域，但是，它们已经在保护大量邮件流量，因为该标准得到主要参与者的支持-Google，Comcast和部分Verizon（AOL，Yahoo）。许多其他邮政服务宣布将在不久的将来实现对该标准的支持。

这将如何影响我？

如果您的域未发布MTA-STS政策，则什么也没有。如果发布策略，将更好地保护发给邮件服务器用户的邮件免遭拦截。

如何实施MTA-STS？

收件人端的MTA-STS支持

足以通过HTTPS和DNS记录发布策略，为MTA中的STARTTLS配置来自受信任的CA之一的有效证书（让我们加密）（所有现代MTA支持STARTTLS），不需要MTA的特殊支持...

逐步，它看起来像这样：

在您正在使用的MTA中配置STARTTLS（后缀，exim，sendmail，Microsoft Exchange等）。
, ( CA, , MX-, ).
TLS-RPT , ( TLS). ( example.com):
```
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:tlsrpt@example.com»
```
TLS SMTP tlsrpt@exmple.com.

, .
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).
将TXT记录发布到DNS：
```
_mta-sts.example.com. TXT “v=STSv1; id=someid;”
```
在id字段中，您可以使用任意标识符（例如时间戳），在更改策略时，它应该更改，这使发件人了解他们需要重新请求缓存的策略（如果标识符与缓存的标识符不同）。

发送方对MTA-STS的支持

虽然很糟糕，但因为标准是新鲜的。

进出口-没有内置支持，有第三方脚本https://github.com/Bobberty/MTASTS-EXIM-PERL
Postfix-没有内置支持，有一个第三方脚本，在Habréhttps : //habr.com/en/post/424961/上有详细描述

作为“强制性TLS”的后记

监管机构最近一直在关注邮件安全（这是一件好事）。例如，DMARC对美国所有政府机构都是强制性的，并且在金融部门中的要求越来越高；在受监管的地区，该标准的普及率达到90％。现在，一些监管机构要求使用单独的域来实施“强制性TLS”，但是同时，也没有定义确保“强制性TLS”的机制，实际上，这种设置的实施方式甚至不能最小化地抵御诸如此类机制中已经提供的真实攻击DANE或MTA-STS。

如果监管机构要求对单独的域实施“强制性TLS”，我们建议将MTA-STS或它的部分等同物视为最合适的机制，这样就无需分别为每个域进行安全设置。如果您在实现MTA-STS的客户端方面遇到困难（直到该协议获得了广泛的支持，很可能是这样），您可以推荐以下方法：

发布MTA-STS策略和/或DANE记录（仅在已经为您的域启用DNSSEC的情况下添加DANE，并且无论如何都应添加MTA-STS才有意义），这将保护您的通信，并且无需要求其他邮件服务配置强制性TLS如果您的网域的邮政服务已经支持MTA-STS和/或DANE。
«» MTA-STS , MX TLS-. MTA-STS, , , . TLS STARTTLS.

Mail.ru邮件开始在测试模式下应用MTA-STS策略