摘要

  • 1982 年的 SMTP 允许接收邮件的服务器承接下一段转发；一旦接下这份工作，它就成为下一段的发送方。
  • 1999 年的 RFC 2505 要求邮件传输代理能拒绝未经授权的中继；容易伪造的 HELO 和 MAIL FROM 不能替陌生人买车票。

把邮件服务器想成一支小车队。有人敲门，报了个响亮的名字，递来一袋写着远方地址的信，要求车队继续送。油钱、路费和被投诉的名声都算在车队老板头上。到 1999 年，互联网终于对这套“我说我是谁，你就替我跑腿”的生意说了重话。

起初，替邮件跑下一段路是 SMTP 的正经工作。1982 年 8 月的 RFC 821 规定，接收方 SMTP 可以接受或拒绝把邮件中继给另一台服务器。接受后，它自己成为下一段的发送方。规范还区分最终邮箱地址和经过哪些主机的路线。互联网由不同系统拼起来，邮件需要中途交接；这项能力曾是跨网络通信的基础安排。

变化出在谁有权要求交接。1999 年 2 月的 RFC 2505 被列为 Best Current Practice 30，把未经授权使用中继称为占用主机资源、损害运营者信誉的行为。它要求邮件传输代理必须具备控制和拒绝这类中继的能力。规范没有拆掉车队，而是要求调度室认清客户、目的地和自己的服务边界。

文件把一次 SMTP 对话里的四种信息排在不同的信任等级上。HELO 是来访者自报的主机名，MAIL FROM 是自报的发件地址；两者都容易伪造。RCPT TO 指向预期收件人，服务器还能看到连接者的源地址。仅凭前两个字段批准转发，就像乘客在纸上写了“我是老板”，调度员便把车钥匙交出去。

RFC 2505 提出的关口很具体：收件域名若属于本站或本站受托代转的域名，可以收；连接者若按源 IP 或可信的主机名获得授权，可以代转；其余请求拒绝中继。这条规则把决定权留给承担机器成本和信誉风险的一方。内容是否讨喜是另一回事；眼前的问题是谁能命令这台服务器替自己再跑一程。

邮路却有历史包袱。RFC 2505 专门提醒 @a,@b: 源路由、% 写法和 UUCP 的 ! 路径会把真正的目的地藏在复杂地址里。只看表面域名的检查可能以为邮件会留在本地，实际却让它继续去远方。另一方面，合法网关也会使用异形地址。关门前要盘点真实的路由算法，否则坏客人会从侧门溜进来，老客户却被挡在门口。

同年六月的 RFC 2635《DON'T SPEW》 把镜头转向接入服务商。它主张别让邮件服务器对陌生人开放中继，写明可接受使用规则，在处置账号前核实滥用，并让 abuse、postmaster 邮箱有人读。软件中的拒绝规则是大门；投诉、人手和合同是门后的管理。服务器能识别一条交易，组织还得处理受害者的来信和误判。

2008 年的 RFC 5321 记录了尚在的矛盾：电子邮件长期承诺能送就送，送不了便退；大量不受欢迎的邮件又迫使运营者筛掉某些信息。无声丢弃会伤害用户对邮件能否到达的信任。1999 年的中继授权门槛解决的是“谁能借这台车”；一封信后来走到哪儿、失败如何告知，仍有独立的责任。

中继没有从互联网消失。它继续替有关系的域名和获准的客户运送邮件。变化在于车队不再把来客自己写的姓名当作付款凭证。HELO 仍然可以打招呼，但打招呼的人不能顺手替车队签合同。