Summary

  • On 2 September 2004, Apache said the then-current Microsoft royalty-free Sender ID patent terms kept its SpamAssassin and JAMES projects from implementing or deploying the design. Its objection concerned what downstream developers and distributors could do, not the price printed on the license.
  • The IETF's 2006 Experimental RFC recorded a separate technical split with SPF and a risk that Sender ID would apply its test to an SPF record and lose valid mail. The 2012 experiment review found SPF widely deployed and Sender ID weakly adopted; it said missing implementation software had not dictated the choice. Sender ID's RFCs became Historic in 2020.

Whose address was a domain authorizing?

An incoming email offers more than one answer to the question “who sent this?” The name a reader sees in a message header need not be the domain used during the SMTP conversation that carried it. Forwarding can make those identities diverge further. A DNS record saying which machines may send for a domain is useful only if sender and receiver agree which domain the record speaks for.

The IETF's MARID charter put that choice at the front of the job. It listed the message's From or Sender header, SMTP Mail-From and SMTP EHLO as possible identities, then directed the working group to select one before narrowing its technical work. This was a fight over the object of authorization. A receiver checking one identity against a record published for another could confidently reach the wrong verdict.

Sender ID and Sender Policy Framework, or SPF, emerged from that contest. Their shared habit of publishing mail-sending policy in DNS could make them look like two implementations of the same answer. They were not. Sender ID included a Purported Responsible Address calculation aimed at the message headers; SPF evaluated the SMTP identity. When the two approaches encountered the same published record, the disagreement could reach a real mailbox.

A license with a tollbooth even at zero dollars

Apache's open letter of 2 September 2004 addressed the MARID list in unusually operational terms: its SpamAssassin spam filter and JAMES mail server would not implement or deploy Sender ID under the current Microsoft royalty-free patent agreement. The Foundation called that agreement incompatible with the Apache License 2.0. “Royalty-free” answered the price question; it left the redistribution question open.

The letter set out the mechanics. Apache objected to patent rights that did not travel cleanly by sublicensing to downstream recipients. It also objected to a requirement, as Apache described it, that a party contact Microsoft to obtain a license for rebranding or redistribution. For software whose normal life is copying, modifying and passing on code, those terms put a separate institution between the first implementer and later users. A mail protocol may specify an algorithm in public while the terms for shipping an implementation send developers to a private desk.

Apache controlled its own projects and stated its own licensing judgment. It did not control all mail software, and its letter was no technical evaluation of the rival tests. Its veto showed a practical limit on a standards proposal: a specification's availability as text does not give an open-source project a workable route to package and distribute code under every attached patent term.

Two experiments, one hazardous DNS record

The IETF did not settle the argument by stamping one design “standard.” In April 2006, it published Sender ID and SPF documents simultaneously as Experimental RFCs. The IESG note said there was no general technical consensus and that reconciliation had failed. It left readers with both recorded approaches and an explicit warning about using them together.

The warning was concrete. A Sender ID receiver might encounter a DNS record written for SPF, apply Sender ID's identity logic to it and then decline a message that was legitimate under the publisher's intended test. The note also called out forwarding and Resent-* header interactions that could block valid mail. That makes the standards dispute more than a quarrel about committee procedure. Publishing two incompatible readings of one authorization signal can shift the cost of ambiguity to a sender whose message never arrives.

The 2012 IETF review gave the experiments a deployment verdict. SPF was widely implemented and used. Sender ID's PRA and SUBMITTER pieces had not attracted a strong community of use. The review found software for both approaches and concluded that unavailable implementations were not the gating factor in the choice. It measured adoption; it did not declare one algorithm mathematically superior. In 2014, SPF moved onto the Standards Track. The IETF moved Sender ID's three RFCs to Historic in February 2020.

Apache's 2004 refusal and Sender ID's later status belong in the same history, but they answer different questions. The first records what one major open-source institution would permit its projects to ship. The second records what the mail ecosystem adopted after two public experiments. In between, the IETF's own warning named a failure mode that neither a zero-dollar license nor a formal RFC number could dissolve: the same DNS words could authorize different identities in different receivers.