Two prominent open-source software groups have rejected a proposed technology standard backed by Microsoft Corp. that would close a loophole used to send unsolicited commercial (“spam”) e-mail, citing unresolved patent and licensing issues with the standard known as Sender ID.
In recent days both the Apache Software Foundation and the Debian Project said that they will not be able to support the Sender ID e-mail authentication standard in their products. The statements bring into public view a debate that has been roiling for months within the open-source software and Internet standards communities as Microsoft tries to garner support for its nascent standard, while also protecting its intellectual property rights.
As currently proposed, the Sender ID license does not meet the standards that each group holds for software distributed with their products, making it incompatible with open-source products, the groups said. Other open-source groups, including the Free Software Foundation, have also voiced reservations about the Sender ID patents, according to those familiar with the dispute. Microsoft was unable to immediately comment for this story.
Sender ID is a technology standard that closes loopholes in the current system for sending and receiving e-mail that allow senders, including spammers, to fake, or “spoof,” a message’s origin. Organizations publish a list of their approved e-mail servers in the DNS (domain name system). That record, referred to as the sender policy framework (SPF) record, is then used to verify the sender of e-mail messages sent to other Internet domains using Sender ID.
Tens of thousands of Internet domains have published SPF records since the standard was introduced by Meng Weng Wong of Pobox.com. In May, Microsoft and Meng reached an agreement to merge SPF with a Microsoft-developed standard called Caller ID to form the new Sender ID standard, which Microsoft submitted to the Internet Engineering Task Force in June for approval.
At the heart of the dispute between Microsoft and the open-source community is language in the Royalty-Free Sender ID Patent License Agreement, which Microsoft requires those using Sender ID technology to sign, according to John Levine, a member of the Internet Research Task Force’s Anti-Spam Research Group.
Open-source software advocates are uncomfortable with a prohibition against transferring or “sublicensing” Sender ID licenses to others in the open-source community, and with a requirement that all licensee’s contact Microsoft directly to receive a copy of the license, Levine said.
The right to transfer and sublicense technology is common within the open-source community and is perceived as a key component , which relies on the contributions of labor and expertise from thousands of developers, who in exchange have unencumbered access to and use of open-source software. In contrast, Microsoft’s license for Sender ID treats recipients of the license like “end users” who have limited rights, according to a copy of an e-mail to Microsoft from Lawrence Rosen, general counsel of the Open Source Initiative, that was posted by the Apache Software Foundation on its Web site Friday.
In a statement issued to the Internet Engineering Task Force (IETF) and published online Saturday, the Debian Project said that the inability to freely distribute, modify and use the Sender ID technology violates the Debian Free Software Guidelines, preventing that group from distributing Sender ID with any Debian software, or even supporting Sender ID.
Beyond the dispute about sublicensing, open-source software groups are also suspicious of Microsoft’s refusal to say what pending patents the company has around the Sender ID technology. Without information on what technology Microsoft is claiming patents on, open-source groups are wary about implementing Sender ID for fear that Microsoft’s patents, when finally disclosed and then granted, will be broad, according to the Apache Software Foundation.
The concerns over patent language in Sender ID are not new. Legal and technology experts raised similar questions about a licensing agreement for the Caller ID authentication standard when it was unveiled by Microsoft in March. Despite those concerns, Microsoft essentially used the same language for its Sender ID technology when it announced that merged standard in May, Levine said.
The IETF’s MTA Authorization Records in DNS (MARID) group, which is reviewing sender authentication proposals, including Sender ID, declined to comment on the dispute over Sender ID, citing the sensitive nature of the group’s work, according to an e-mail statement from Andrew Newton, co-chair of MARID.
However, the breakdown between leading open-source groups and Microsoft may slow the momentum behind Sender ID adoption, which Microsoft has been aggressively pushing in recent months at company-sponsored meetings with leading Internet service providers and e-mail technology vendors.
Patent disagreements aside, the Sender ID technology has not proven to be as popular or as effective at stopping spam as some had hoped, Levine said.
A recent survey conducted by e-mail security company CipherTrust Inc. found that only about 5 percent of inbound e-mail comes from domains that have published SPF records, a component of the Sender ID system. Of the 3 percent to 5 percent of mail that does come from an e-mail domain with a valid SPF record, more is spam than legitimate e-mail, CipherTrust’s survey showed.
With only middling performance in spotting spam and a host of legal concerns surrounding it, Sender ID may fall by the wayside, as companies look with increasing interest at competing standards, such as DomainKeys, a sender authentication standard backed by Yahoo Inc., Levine said.
“People are saying why jump through hoops and sell our soul to Microsoft for technology that’s not that great, even when it is deployed,” he said.