简而言之，MTA-STS 是一种进一步保护电子邮件在邮件服务器之间传输时免遭拦截（即中间人攻击，又名 MitM）的方法。 它部分解决了电子邮件协议的遗留架构问题，并在相对较新的标准 RFC 8461 中进行了描述。Mail.ru 是 RuNet 上第一个实现该标准的主要邮件服务。 并且在剪切下有更详细的描述。
MTA-STS 解决什么问题？
从历史上看，电子邮件协议（SMTP、POP3、IMAP）以明文形式传输信息，这使得在访问通信通道时等情况下可以拦截信息。
将信件从一个用户传递给另一个用户的机制是什么样的：
从历史上看，所有邮件流通的地方都可能发生中间人攻击。
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 中发布带有策略版本的特殊 TXT 记录 _mta-sts。 当策略更改时，必须更新此条目（这表明发送者重新查询策略）。 例如，
_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 发布证书信息，不需要信任外部证书颁发机构，安全得多。 但根据多年使用的统计数据，DNSSEC 的使用更经常导致技术故障（尽管 DNSSEC 的可靠性及其技术支持总体呈积极趋势）。 为了在接收方的 SMTP 中实现 DANE，DNS 区域的 DNSSEC 的存在是强制性的，并且对 NSEC/NSEC3 的正确支持对于 DANE 至关重要，这在 DNSSEC 中存在系统性问题。
如果 DNSSEC 配置不正确，如果发送方支持 DANE，即使接收方对此一无所知，也可能会导致邮件传送失败。 因此，尽管DANE是一个较旧且更安全的标准，并且已经在发送端的一些服务器软件中得到支持，但事实上它的渗透率仍然微不足道，许多组织由于需要实施DNSSEC而没有准备好实施它，在该标准存在的这些年里，这大大减慢了 DANE 的实施速度。
DANE和MTA-STS互不冲突，可以一起使用。
Mail.ru Mail 中的 MTA-STS 支持有什么用？
Mail.ru 为所有主要域发布 MTA-STS 策略已经有一段时间了。 我们目前正在实施该标准的客户端部分。 在撰写本文时，策略以非阻塞模式应用（如果投递被策略阻止，信件将通过“备用”服务器投递而不应用策略），然后一小部分将强制使用阻塞模式的传出 SMTP 流量，逐渐为 100% 的流量提供支持策略的执行。
还有谁支持该标准？
到目前为止，MTA-STS 策略发布了大约 0.05% 的活动域，但尽管如此，它们已经保护了大量的邮件流量，因为该标准得到了主要参与者的支持——谷歌、康卡斯特和部分威瑞森（AOL、雅虎）。 许多其他邮政服务已宣布将在不久的将来实施对该标准的支持。
这将如何影响我？
除非您的域发布了 MTA-STS 策略，否则不会。 如果您发布该策略，您的邮件服务器用户的电子邮件将得到更好的保护，免遭拦截。
如何实施 MTA-STS？
接收方的 MTA-STS 支持
通过 HTTPS 发布策略并在 DNS 中记录就足够了，为 MTA 中的 STARTTLS 配置来自受信任 CA 之一的有效证书（可以进行加密）（所有现代 MTA 都支持 STARTTLS），无需来自需要 MTA。
一步一步来看，它看起来像这样：
- 在您使用的 MTA（postfix、exim、sendmail、Microsoft Exchange 等）中配置 STARTTLS。
- 确保您使用有效的证书（由受信任的 CA 颁发，未过期，证书的主题与为您的域传送邮件的 MX 记录匹配）。
- 配置 TLS-RPT 记录，通过该记录传送策略应用程序报告（通过支持发送 TLS 报告的服务）。 示例条目（对于 example.com 域）：
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»此条目指示邮件发件人将 SMTP 中 TLS 使用情况的统计报告发送至
[email protected].监视报告几天以确保没有错误。
- 通过 HTTPS 发布 MTA-STS 策略。 该策略以文本文件形式发布，其中按位置包含 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版本字段包含策略的版本（当前
STSv1），Mode设置策略应用模式，testing——测试模式（策略不应用），enforce——“战斗”模式。 先以mode:testing方式发布策略，如果测试模式下策略没有问题，过一段时间就可以切换到mode:enforce。在 mx 中，指定了可以接受您的域的邮件的所有邮件服务器的列表（每个服务器必须配置与 mx 中指定的名称匹配的证书）。 Max_age 指定策略的缓存时间（一旦记住的策略将被应用，即使攻击者在缓存时间内阻止其传递或损坏 DNS 记录，您也可以通过更改 mta-sts DNS 来发出需要再次请求策略的信号记录）。
- 在 DNS 中发布 TXT 记录：
_mta-sts.example.com. TXT “v=STS1; id=someid;”id 字段中可以使用任意标识符（例如时间戳）；当策略更改时，它应该更改，这允许发送者了解他们需要重新请求缓存的策略（如果标识符与缓存的策略不同）缓存一个）。
发送方的 MTA-STS 支持
到目前为止，她的情况很糟糕，因为…… 新鲜的标准。
- Exim - 无内置支持，有第三方脚本
- Postfix - 没有内置支持，有一个第三方脚本，在 Habré 上有详细描述
作为“强制 TLS”的后记
最近，监管机构一直在关注电子邮件安全（这是一件好事）。 例如，DMARC 对美国所有政府机构都是强制性的，并且在金融领域的需求也越来越大，该标准在监管领域的渗透率达到 90%。 现在，一些监管机构要求对各个域实施“强制 TLS”，但确保“强制 TLS”的机制并没有定义，而且在实践中，这种设置的实施方式往往无法最低限度地防范已经发生的真实攻击。在 DANE 或 MTA-STS 等机制中提供。
如果监管机构要求在单独的域中实施“强制 TLS”，我们建议考虑 MTA-STS 或其部分类似机制作为最合适的机制，它无需为每个域单独进行安全设置。 如果您在实现 MTA-STS 的客户端部分时遇到困难（在协议获得广泛支持之前，他们很可能会这样做），我们可以推荐这种方法：
- 发布 MTA-STS 策略和/或 DANE 记录（仅当已为您的域启用 DNSSEC 且在任何情况下启用 MTA-STS 时，DANE 才有意义），这将保护您方向的流量并无需询问其他邮件服务如果邮件服务已支持 MTA-STS 和/或 DANE，请为您的域配置强制 TLS。
- 对于大型电子邮件服务，通过每个域的单独传输设置来实现 MTA-STS 的“模拟”，这将修复用于邮件中继的 MX，并需要对其进行 TLS 证书的强制验证。 如果域已经发布了 MTA-STS 策略，则这可能可以轻松完成。 从安全角度来看，在不修复中继并验证其证书的情况下为域启用强制 TLS 本身是无效的，并且不会向现有的 STARTTLS 机制添加任何内容。
来源： habr.com