摘要

  • draft-ietf-emailcore-as-30 第 6.5 节要求 SMTP 接收实现能够接纳有无传输保密性的邮件，同时写明发送方或接收方在具体情形下如何行动，取决于本地策略。它仍处于 IESG 的「AD Followup」，不是已经公布的 RFC。
  • 第 29 版原先直接要求接收方不得要求发送方提供链路保密性。九月下旬的公开讨论正在质疑第 30 版的能力要求是否必要、是否会被误读为必须开放明文接收；讨论尚未构成最终标准决定。

设想一个只服务内部系统的邮件入口：管理员可以要求先协商 TLS，否则就拒绝连接。这是准入规则，而非对软件能力的完整描述。软件也许仍能在其他配置下处理未加密的 SMTP 会话。日常操作可以轻易区分这两层；但当标准草案在「接收」一词旁放上大写的 MUST，它约束的对象必须说清楚。

EMAILCORE 适用性声明第 30 版给了两个相邻但不同的要求。发送实现应在保密性可用、接收方接受时使用它；接收实现则必须具备接纳有或无保密性邮件的能力。紧接着，文本明确把某个具体场景中的行动交回本地策略。第 29 版对接收方的用语并非如此：它说接收方不得要求发送方提供线路上的保密性。草案变更记录指出第 6 节在 IESG 审议期间重写。这不是新的加密协议，而是规范性句子的对象与力度发生了变化。

文字改变不等于审议结束。Datatracker 仍将第 30 版列为活跃 Internet-Draft，IESG 状态为「AD Followup」；投票页面仍显示 DISCUSS 意见，其中部分针对上一版提出，涉及的问题也不全相同。9 月 18 日，编辑 John Klensin 在回复 Roman Danyliw 时说明，部分答复是个人意见，还未由工作组审阅。9 月 28 日，Eric Rescorla 认为，如果支持者说新要求并无额外效果，就应删除这项规范性要求；Rob Sayre 的回复则强调实现能力与运营选择的区分，并预期更多运营者会要求 TLS。这些是可归属的公开主张，不能写成 IETF 已达成一致。

既有 RFC 3207 还给这场争论划出另一条边界。它就 STARTTLS 规定：公开引用的 SMTP 服务器不得把 STARTTLS 作为本地投递的必要条件；未被公开引用的服务器则可以要求协商该机制。这是已有、具有适用范围的互操作规则。不能从中推出所有邮件服务都必须无条件接受明文，也不能把它直接等同于未来草案对所有接收软件的能力要求。

还有一种容易混淆的机制是 RFC 8689 的 REQUIRETLS。它允许单封邮件提出传输保密要求，在支持该机制的中继链路上宁可失败也不回退到明文。BTW 此前已从邮件本身的角度报道过这一选择。它不决定通用接收程序必须包含哪些接收路径。单封邮件的意愿、公开 MX 的既有规则、软件可实现的能力，以及某次连接的本地准入，分别位于四个不同的决策层。

这一区分的价值并非文字游戏。适用性声明会影响供应商的合规叙述、产品默认项与采购问答。如果有人把「软件必须能够」误听为「运营者必须允许」，本地安全边界就可能被错误地搬到标准名下。反过来，如果供应商为追求单一安全默认项而从产品中彻底去掉某种接收能力，日后处理特殊互操作场景可能不再是调整配置，而要等软件版本。现有资料既没有测量这两种成本，也没有证明草案已造成投递故障。真正待回答的是共同能力与本地策略的分界。

来源