按发送方策略状态定义第一个连接
MTA-STS 无法保证对域的每次初始交付都提供保护。其最强的降级阻力取决于支持发送者已经持有需要执行的有效策略。因此，“第一次连接”最好被理解为一个政策国家问题，而不是一个人发送的第一条消息。另一台机器、清除的缓存或过期的策略都可以更改启动条件。
此解释使用虚构的状态比较，而不是实时降级实验。没有流量被拦截、 DNS响应被更改或发送系统被测试。演示特定实现的行为需要经过批准的隔离测试，并提供其初始缓存、发现结果、策略模式和交付决策的证据。
解释为什么发现是脆弱的一步
接收域通过DNS通告MTA-STS TXT记录 并通过 HTTPS 提供其策略。经过身份验证的 HTTPS 获取会建立策略的内容，但可以阻止成功的初始发现的攻击者可以阻止发件人了解这些内容。 RFC 8461明确描述了这种发现预防风险。安全托管策略对未获得该策略的发件人没有帮助。 RFC 8461第 3 节和 10.2 节
如果存在有效的发现记录但 HTTPS 检索失败，该规范要求没有有效缓存策略的发件人继续执行，就像未实现MTA-STS一样。它还允许策略获取在其示例控制流中异步发生。发布强制策略并不能确定每个支持的发件人在下一次传送之前都已获取该策略。 RFC 8461第 3.3 和 5.1 节
区分普通TLS和强制策略
SMTP STARTTLS 提供了一种在连接上协商TLS的方法。扩展本身并不能建立接收域的MTA-STS要求。 RFC 3207讨论了当TLS无法协商或身份验证时机会主义操作的局限性以及本地策略的重要性。避免将STARTTLS广告等同于保证发件人将拒绝所有不安全的回退。 RFC 3207第 5 节和第 6 节
一旦支持发件人应用了有效的强制策略，它就不得向未通过所需MX匹配或证书验证或缺少STARTTLS候选者发送邮件。测试模式不同：尽管MTA-STS验证失败，消息仍可传送，并在实施时报告。因此，缓存策略与其模式一起重要；仅仅拥有一个缓存条目并不等同于强制执行。 RFC 8461第 5 节
比较三个虚构的发件人
假设虚构的example.com发布了mx1.example.com的强制策略。发件人 Alder 没有有效的缓存策略，无法检索策略。发件人 Birch 拥有之前获得的有效、未过期的强制策略。发件人 Cedar 只有过期的策略，无法刷新。这些是用于解释的构造状态，而不是命名产品的测量。
采集失败后，Alder 在没有MTA-STS保护的情况下继续运行。即使当前发现或检索不可用，Birch 也必须继续应用其缓存的强制策略。 Cedar 无法将其过期条目视为此保护规则所需的有效缓存策略。这些陈述均不排除由 DANE 或当地的交通要求。该示例将MTA-STS的贡献与发件人的整个安全状况区分开来。 RFC 8461第 3.3 和 5.1 节
现在假设所联系的SMTP主机未通过证书验证。 Birch 无法在强制模式下交付给失败的候选者，并且应该遵循指定的重试和更新策略检查。仅凭缺失的MTA-STS政策无法预测 Alder 的结果：其其他政策和SMTP实施仍然很重要。将所有三个结果称为“加密”或“阻止”将隐藏决定性的证据。 RFC 8461第 4-5 节
描述缓存的哪些改进以及哪些过期
策略 max_age 限制获取的策略保持可用的时间。 RFC 8461预计生命周期通常以周或更长时间来衡量，以减少刷新时间暴露，并建议在到期前主动刷新。这就产生了一个权衡：寿命较长的策略可以在临时发现失败时保留保护，但在更改MX基础设施时需要小心。不可用的旧MX不会仅仅因为需要新配置而变得可接受。 RFC 8461第 3.2–3.3 节和 8.1 节
删除发现记录不会立即删除发件人已缓存的策略。记录的选择退出使用有效模式无策略、新的发现 ID 以及足够的时间，以便先前提供的策略在删除端点之前过期。操作回滚必须考虑这些远程状态。本地DNS更改无法追溯证明每个远程发件人都已放弃其缓存。 RFC 8461第 8.3 节
定位DANE并准确报告
SMTP的DANE使用经过 DNSSEC 验证的 TLSA 信息为验证TLS提供不同的基础。 RFC 8461将MTA-STS作为补充，并声明它不得覆盖失败的DANE验证。 DANE的适用性取决于其经过验证的DNS链、可用记录和发送实现；它不应显示为本文已配置或测试的交换机。 RFC 8461第 2 节 RFC 7672
TLS-RPT 帮助参与的发件人描述传输和策略故障，但报告不是执行。报告涵盖了记者的观察结果，可以在活动结束后到达。丢失的报告不能证明发现成功、缓存存在或所有路径都受到保护。将报告与发送者状态和连接证据一起使用，而不是替代它们。 RFC 8460第 1 节和第 4 节
提出可辩护的保护主张
有用的声明可确定支持的发件人、有效的策略获取、强制模式、适用的MX范围以及剩余的首次获取风险。避免“所有传入的电子邮件都是防降级的”。经批准的评估应展示空缓存、有效缓存和过期缓存行为，同时保持预期场景不变。这里没有实际的实现、踪迹和结果。目前的 RFC 勘误表已经过检查，但没有报告的提案已提升为新的保护保证。 RFC 8461勘误表