摘要

  • Apache 2004 年 9 月 2 日的公开信表示，Microsoft 当时的 Sender ID 专利许可妨碍其 SpamAssassin 和 JAMES 项目实现或部署该方案。Apache 争论的是下游复制、改名和再分发的权利，而非版税金额。
  • IETF 2006 年的实验性 RFC记录了 Sender ID 与 SPF 缺乏技术共识，还警告合法邮件可能因 DNS 记录被错误解释而丢失。2012 年复盘发现 SPF 广泛部署、Sender ID 使用有限；2020 年 Sender ID 的三份 RFC 转入 Historic。

邮件到底代表哪个域名

一封邮件有好几个可以被叫作“发件人”的位置。读者看到的是信头里的 From；邮件服务器交谈时使用 MAIL FROM，还会在 EHLO 里报出一个名字。转发让这些名字进一步分离。域名所有者把允许发信的机器写进 DNS 之后，收件服务器必须先决定：这条授权究竟对应哪一个域名？

IETF 的 MARID 工作组章程把选择身份列为第一项工作，明确摆出 From、Sender、MAIL FROM 和 EHLO。Sender ID 的 PRA 算法从邮件信头寻找“表面负责地址”；SPF 检查 SMTP 过程中的身份。两者都能利用 DNS 发布授权信息，却不一定在检查同一个对象。如果收件方把为 SPF 写的记录用于 Sender ID 的判断，授权的对象就被悄悄换掉了。

零版税协议里仍有一道闸门

2004 年 9 月 2 日，Apache 软件基金会给 MARID 邮件列表写信，说 Microsoft 当时的免版税 Sender ID 专利协议与 Apache License 2.0 不兼容。它代表 SpamAssassin 与 JAMES 两个项目表示：按现有条款，不实现，也不部署。

信里列出的障碍很具体。Apache 认为，专利许可不能顺畅地随软件向下游转授；想换品牌或再分发的人还得联系 Microsoft。开源软件的日常路径恰好就是被复制、修改、重新打包、继续传递。让每一个环节回到专利持有人那里办理手续，等于把一个私人审批台放在公开代码的流通途中。

Apache 能决定自己项目采用什么条款，不能替所有邮件软件作决定。它的公开信也没有裁定 Sender ID 算法的技术优劣。它展示的是另一种权力边界：规格书可以公开，实施规格书所需的专利许可却可能让重要的实现者无法把代码交到用户手里。

IETF 把分歧写进 RFC

2006 年 4 月，IETF 没有宣布胜者，而是把 Sender ID 和 SPF 同时发表为实验性 RFC。IESG 的附注说，技术上没有普遍共识，调和两条路线的尝试已经失败。附注紧接着警告：Sender ID 可能读取原本为 SPF 发布的 DNS 记录，用错身份规则，导致有效邮件无法投递；自动转发和 Resent-* 信头还有另一组互操作问题。

这不是标准组织内部的措辞之争。一条记录被两套规则解释，实际动作是收件服务器接受、拒绝或丢弃一封邮件。标准编号能保存方案，却不能让两种解释自动变成同一种解释。

IETF 2012 年的实验复盘将代码供给与实际使用分开考察。SPF 已广泛部署；Sender ID 的 PRA 和 SUBMITTER 没有形成强大的使用群体。报告指出，两套方案都有可用软件，软件缺位不是市场选择的门槛。它评估的是部署记录，并未给两种算法判一个抽象的“正确性”冠军。2014 年 SPF 进入标准轨道；2020 年 Sender ID 的 RFC 4405、4406、4407 被改列为 Historic。

Apache 在 2004 年关闭的是自身项目的一条实现路径。后来邮件运营者的选择决定了更大的部署格局。两份记录之间，2006 年的警告一直刺眼：如果发布者、实现者和接收者对“哪一个发件人”没有共同答案，错误最终会落在一封本该送达的邮件上。