STARTTLS 是一种将SMTP连接升级到TLS的机制。它本身并没有说明是否需要TLS 、对等方是否经过身份验证或者失败的协商是否可以回退到明文。这些是政策问题。有用的运输评估将每个单独记录，而不是将它们简化为单个绿色挂锁。
按顺序阅读谈判内容
参考： RFC 3207 §4.
SMTP客户端建立连接，发送 EHLO 并读取服务器的扩展。 STARTTLS广告提供升级。当客户端请求并收到就绪响应时， TLS协商开始。握手后， SMTP状态重置，客户端应再次发出EHLO ；在TLS之前学到的功能并不能简单地继承。 RFC 3207第 4 节.
包含STARTTLS一词的文字记录是不够的。识别服务器响应、握手结果和协商协议。成功的握手会在该连接上建立加密，但其身份验证强度取决于证书验证和策略。记录发送者接受对等点的原因，而不仅仅是协商哪个密码。
了解机会主义行为
参考： RFC 3207 §6.
机会性TLS在可用时尝试加密，而无需为每个目标都要求经过身份验证的TLS 。本地发件人策略可能更严格，因此避免假设所有系统在发生故障时的行为方式相同。由于缺乏通用执行规则，裸露的STARTTLS功能成为有限的安全声明。
特别是，主动攻击者可能会在未经身份验证的路径上抑制STARTTLS广告。如果发送方对TLS没有独立要求，则丢失的广告可能会导致未加密的传送。现代加密算法无法修复永远无法达到TLS协商。请参阅中的攻击讨论 RFC 3207第 6 节.
添加经过身份验证的策略决策
参考： RFC 8461 §4, RFC 8461 §5, RFC 7672 §2.2.
具有适用执行力的支持发件人 MTA-STS 策略会检查接收MX和证书要求，并且不得违反该策略进行交付。测试模式不需要因MTA-STS验证失败而扣留交付；故障报告取决于 TLS-RPT 由发送域和接收域实现。 SMTP DANE 使用安全 TLSA 发现及其证书使用规则来建立传输要求。不要仅仅因为接收域发布了发送者从未评估过的内容而将任一控件称为活动控件。
综合决策模型使用具有三个输入的一条路由：通告STARTTLS 、握手成功以及根据适用策略接受对等点。它记录机会加密连接与符合策略的连接分开。负面情况会在强制执行处于活动状态时删除STARTTLS ，并且预计不会在该路由上进行传递。该装置是一个决策说明，而不是SMTP实现或数据包捕获。
准确报告并重新测试失败
为了进行真正的检查，请保留发送者、目标IP、时间戳、路由选择、策略状态和验证结果。 OpenSSL STARTTLS探针可以检查选定的端点，但它不会自动重现发送 MTA's DNSSEC 发现、 MTA-STS缓存或故障转移策略。遵循受控的发送方测试，并使用日志来建立实际决策。
使用诸如观察加密连接、经过身份验证的对等验证或强制发件人拒绝不合规路由等措辞。不要因为一次连接成功而声称每条消息都受到保护。审查包现在包括保留的 2026 年 11 月 7 日环回记录。成功的控制记录了 TLS 前的EHLO 、 STARTTLS准备情况和 TLS 后的EHLO 。一项配置的信任测试提供证书 B，而客户端信任 A 并记录自签名证书验证失败；其A控制成功。必需的 TLS 客户端拒绝没有STARTTLS服务器。这些是历史控制的 Python 客户端决策，而不是生产 MTA 或完整的MTA-STS / DANE实现。特别是，配置的信任和关联输入不会建立DNSSEC链、实时策略发现、每个所需的证书配置文件约束或真实的发件人缓存。不 邮件来自、 RCPT TO 或 DATA 命令被发送。对捕获进行了检查，而不是作为本次审查的网络测试重新运行。新的离线装置仅检查其明确定义的决策模型。