摘要

  • RFC 5383 指出，酒店等公共接入网络曾经会无视用户指定的主机而截获 25 端口连接，使敏感通信可能进入未知且不受信任的第三方服务器，而用户通常并不知情。
  • 587 端口把“用户提交邮件”与“服务器间转递邮件”分成两个可治理的服务面，但端口号不是身份证明。目标选择、TLS 身份、账号授权、队列接收、后续转递和收件结果都要各自留据。

隐藏变化的不是路径，而是交易对手

设想一名旅客在酒店发送公司邮件。客户端按配置解析域名，TCP 三次握手完成，对端给出 SMTP 欢迎语，界面显示连接正常。从传统可用性指标看，所有步骤都成功了。

RFC 5383 第 3 节保留了另一种事实：部分酒店和公共网络会拦截所有指向 25 端口的连接，不论原本的目的主机是谁。于是，用户以为自己把消息交给公司邮件系统，实际应答者却可能是网络路径上的第三方。

这份 2008 年的 BCP 没有证明今天仍有多大比例的网络这样做，也没有指认某个酒店、运营商或泄露事件。它证明的是机制：传输连通可以与目标忠实度同时背离。连接越顺利，错误的信任反而越不容易被发现。

当接入网决定由谁接收应用数据时，它已不再只是运输层参与者。它获得了选择服务、接触凭据和内容的控制权，却可能没有承担服务提供者本应承担的身份披露、审计和补救责任。

为什么必须把提交从转递中拆出来

互联网邮件并不是一次动作。用户代理生成并提交消息；提交服务验证账号、执行政策、接受或拒绝保管；邮件传输代理继续转递；目的系统写入邮箱；读者最后才可能看到。

RFC 2476 首次把 Message Submission 定义为独立服务，RFC 4409 随后修订，当前后继是 RFC 6409。587 端口对应用户向邮件处理系统交件的入口，25 端口则主要保留给邮件传输。RFC 5383 因而要求移动邮件客户端能够访问 587，并建议默认使用它。

这里真正重要的不是换了一个数字，而是责任边界变清楚。提交服务可以声明它支持的认证方式、扩展、速率限制和接收凭据；防火墙可以明确放行这个服务，而不必把所有 SMTP 流量视为同一种关系。

但 587 只是协调标签，不是服务器证书。任何进程都可能在这个端口监听。端口告诉客户端“预期是什么服务”，不能回答“究竟是谁在提供服务”。

不要让一个绿色状态吞掉七层证据

可审计的链条至少包含七件事：客户端配置了哪个主机名；DNS 返回了什么；实际 TCP 对端是谁；TLS 是否建立并验证了正确的参考身份；SMTP 认证确认了哪个主体；提交服务是否接受消息；后续转递和收件是否发生。

RFC 8314 后来建议邮件访问与提交使用 TLS，并记录了 465 端口的 submissions 服务，同时承认 587 上既有的 STARTTLS 路径。这一后续演进恰好说明，不能把 RFC 5383 的 587 建议写成加密保证。只有客户端真实协商保护信道、验证证书与参考身份，并在错误时停止，身份才形成可用证据。

因此，日志不能只写“已连接”。它应保留预期主机名、DNS 结果、实际对端、端口、TLS 模式、证书链、身份验证结果、SMTP 欢迎语与能力、认证机制与主体、响应码、队列编号和时间戳。少一个字段，就可能把服务替换误诊成普通延迟。

明确拒绝比隐蔽成功更诚实

运营商限制 25 端口可能有正当理由，例如控制垃圾邮件、阻止受感染主机直接外发。RFC 5383 并不是取消网络安全政策。关键区别在于，网络是明确拒绝，还是偷偷替换。

拒绝会暴露政策冲突。客户端可以改用规定的提交服务，用户可以求助，组织可以谈判。截获却制造了虚假连续性：界面显示成功，内容与凭据可能已进入未选择的系统，而原服务商看不到任何对应记录。

应用层防火墙若只理解一部分 SMTP 扩展，还可能让一端看到协商、另一端却收到被删改的能力，最终在更晚阶段失败。本文不重复 BTW 已有的 RFC 2979 防火墙透明性文章，也不接管 RFC 3093 的 HTTP 隧道命题。这里关注的是更窄的证据问题：谁实际成为了邮件提交的对手方。

接收响应不是送达证明

即便连接了正确且经过认证的提交服务器，成功响应也只能证明该服务在当时政策下接收了事务。它不能证明每一次后续转递、邮箱落盘、界面展示或人的阅读。

事故调查应连接而不是合并这些凭据：目标选择、信道身份、认证账号、信封与内容接受、队列保管、转递尝试、目的响应、邮箱状态。若最初发生截获，队列编号可能属于错误的管理域。编号再精确，也不能自动与用户原本选择的服务建立关系。

最低限度的验证应从企业、移动、住宅和访客网络访问受控提交服务，比较配置目的地和真实对端，并主动制造错误证书、缺失 STARTTLS、能力变化、异常欢迎语和明确封锁。合格客户端要么验证正确服务，要么给出可归因的失败；不能为了维持“可用”而悄悄降低身份要求。

来源