SMTP 为什么用 ETRN 取代 TURN

摘要

小型站点并不总有永久入站路径。它拨号连接服务商时，既要交出待发邮件，也希望收回离线期间积压的信件。若只等服务商的普通重试计时器，短暂的可达窗口可能白白过去。

RFC 821 提供了 TURN。呼叫方先作为 sender-SMTP，服务商作为 receiver-SMTP；收到 250 后，双方在同一传输通道上交换角色。原呼叫方成为接收方，重新发送服务就绪问候，服务商则开始向它发送队列。服务商可用 502 拒绝，命令本身也是可选项。

线路得以复用，但信任也被复用到了它从未证明过的范围。

服务器必须判断新接收方应得到哪个站点的积压邮件。早期 SMTP 并不认证对端宣称的主机名。恶意系统可以借用另一个站点的名字，请求 TURN，让服务器把后者的邮件沿当前线路送来。

这不是只在头部写错一行，而是可能改变整封邮件的保管关系。RFC 1985 后来明确称其为严重安全漏洞，并指出许多实现正因规范没有提供远端名称验证而拒绝实现 TURN。

问题在于一次状态转移过大：一条未经认证的声明同时决定了假定身份、双方角色、连接方向和积压邮件的目的地。

RFC 1985 保留了运营需求，同时缩小授权。服务器在 EHLO 后公布 ETRN；客户端给出节点名，请求开始处理相应队列。命令可在会话建立后使用，但不能插入 MAIL FROM 到 DATA 完成之间的邮件事务。

服务器检查范围并作本地管理决定。接受后，它启动重试队列，并通过另一条 SMTP 连接向指定站点发送。原呼叫方仍只是控制通道上的呼叫方，不会因为知道一个名字就收到任何积压信封。

新连接并非神奇的身份认证，而是独立证据边界。DNS、路由、连接建立和接收端 SMTP 事务将重新决定目的地及每封邮件是否被接受，不再完全依赖触发者口述的名字。

队列处理可能耗时不定。RFC 1985 不要求一定建立连接，也不规定连接必须在多久内发生，因此命令应迅速返回。

普通 250 只表示请求可接受并已开始队列处理。它不证明队列有邮件、出站连接成功或收件方接受了任何内容。可选的 251、252、253 提供更多本地队列信息，仍不是端到端交付证据。

若监控系统把 ETRN 250 记录为“已送达”，就消灭了协议刻意保留的不确定性。触发被接受、开始连接、完成 SMTP 转移和最终送达应是不同记录。

最简单的参数是完整节点名。@域名 可以启动该域及其子域的队列，#名称 可以选择本地定义的队列，例如 UUCP 队列。

这些快捷方式会放大范围。粗心接受 @com 可能启动海量工作并造成拥塞；# 名称没有全球字典，协议也不允许客户端枚举所有本地队列。服务器必须依照自己的存储模型，授权合理的调用者—范围组合。

IANA 协调 ETRN 这个词，并不授予队列访问权。

RFC 2821 弃用了 TURN，RFC 5321 延续这一判断：除非服务器能强认证要求交换角色的客户端，否则不应使用。只给线路加密仍不够；服务器还要判断该认证主体能否领取特定积压邮件。

RFC 5321 还给出更小的优化：收到某主机发来的邮件，可以成为提前重试发往该主机队列的本地线索。它只改变调度，不把队列交给提供线索的人。

当前 IANA 注册表保留 TURN 与 ETRN 的历史位置，同时标明二者不得用于邮件提交服务。在 587 端口提交邮件的用户，并不会因此获得启动 SMTP 交付队列的权力。

互联网邮件没有放弃间歇联网主机，而是拆开了三个决定：客户端建议工作，服务器授权和安排，独立连接验证交付。任何一步都不再冒充另外两步。