Chronicles, Press, and Commentary

• [September 22, 2004] Internet Engineering Steering Group (IESG) Announces Closure of IETF MARID Working Group. From the 2004-09-22 announcement:

  The MTA Authorization Records in DNS (MARID) working group in the Applications Area has concluded. After an assessment of the current state of the MARID working group, its charter, and its milestones, the working group chairs and Area Advisor concluded that the MARID working group should be terminated...

  The group was originally chartered with a very tight time frame, with the expectation that a focused group of engineers would be able to produce in relatively short order a standard in the area of DNS-stored policies related to and accessible by MTAs. The group has had no lack of energy. From the outset, however, the working group participants have had fundamental disagreements on the nature of the record to be provided and the mechanism by which it would be checked. Technical discussion of the merits of these mechanisms has not swayed their proponents, and what data is available on existing deployments has not made one choice obviously superior. Each represents trade-offs, and the working group has not succeeded in establishing which trade-offs are the most appropriate for this purpose. These assessments have been difficult in part because they have been moved out of the realm of pure engineering by the need to evaluate IPR and licensing related to at least one proposal in the light of a variety of licenses associated with the deployed base of MTAs.

  Efforts to reach consensus by compromise and by inclusion have been attempted on multiple occasions. Despite early hopes of success after each such attempt, post-facto recycling of technical issues which these efforts should have closed has shown that the group remains divided on very basic issues...

  Concluding a group without it having achieved its goals is never a pleasant prospect, and it is always tempting to believe that just a small amount of additional time and energy will cause consensus to emerge. After careful consideration, however, the working group chairs and area advisor have concluded that such energy would be better spent on gathering deployment experience..."

  References:

  • Comments from members of the SPF and MARID (Sender ID) working parties; see postings from September 22, 2004 and following
    • SPF mailing list
    • MARID WG mailing list
  • "MARID Working Group to Close." Posted by Ted Hardie (IETF co-Area Director, Applications). September 22, 2004.
  • "Article on Microsoft Patents and Caller ID." By Meng Weng Wong.
  • "Catastrophic Loss for Unencumbered Standards." By David Berlind From ZDNet News (September 24, 2004).
  • "Microsoft-Backed Antispam Spec Gets Filtered Out." By Stefanie Olsen. In CNET News.com (September 23, 2004).
  • "IETF Shutters E-Mail Working Group." By Jim Wagner. From InternetNews.com (September 22, 2004).
  • "IETF Shuts Down Anti-Spam Working Group." By Larry Seltzer. In eWEEK (September 22, 2004).
  • "MARID is Dead." By Yakov Shafranovich. From CircleID (September 22, 2004).
  • "Anti-spam Standard Body Dismantled. Row Over Microsoft's Sender ID Leads to Disbanding of IETF Working Group." By Matthew Broersma. In InfoWorld (September 23, 2004).

• [September 16, 2004] Microsoft Patent Application[s] Relative to Sender ID. Reducing Unwanted and Unsolicited Electronic Messages by Preventing Connection Hijacking and Domain Spoofing. United States Patent Application #20040181571. Application publication date: September 16, 2004. Application Serial Number: 684020. Series Code: 10. Date filed: October 10, 2003. The "Invention": attributed to Atkinson, Robert George; (Woodinville, WA); Goodman, Joshua T.; (Redmond, WA); Lyon, James M.; (Redmond, WA); Williams, Roy; (Woodinville, WA); Ahmed, Khaja E.; (Bellevue, WA); Katz, Harry Simon; (Bellevue, WA); Rounthwaite, Robert L.; (Fall City, WA).

  According to a posting from Harry Katz, "Microsoft is aware of the existence of US, EP; JP; CN; KR; and IN patent applications that are likely to include claims that would necessarily be infringed when implementing the combination of the specifications entitled 'Purported Responsible Address in E-mail Messages', file name draft-ietf-marid-pra-00.txt, and located at the following link on August 23, 2004, url: http://www.ietf.org/internet-drafts/draft-ietf-marid-pra-00.txt and the specification entitled "Sender ID: Authenticating E-mail", file name: draft-ietf-marid-core-03.txt, url: http://www.ietf.org/internet-drafts/draft-ietf-marid-core-03.txt..." US Title: "Reducing Unwanted And Unsolicited Electronic Messages By Preventing Connection Hijacking And Domain Spoofing", Serial no. 10/684020. Title for other jurisdictions is "Coordinated Reduction of Unwanted and Unsolicited Electronic Mail Messages". EP Serial no. 04005644.2; JP Serial no. 2004-71769; CN Serial no. 200410028682.3; KR Serial no. 10-2004-16409; IN Serial no. 298/DEL/2004.

  Abstract: The present invention provides for generating inputs that can be provided to a message classification module to facilitate more reliable classification of electronic messages, such as, for example, as unwanted and/or unsolicited. In one embodiment, a sending messaging server provides an appropriate response to address verification data thereby indicating a reduced likelihood of the sending messaging server using a forged network address. In another embodiment, it is determined if a messaging server is authorized to send electronic messages for a domain. In yet another embodiment, electronic message transmission policies adhered to by a domain are identified. In yet a further embodiment, a sending computer system expends computational resources to solve a computational puzzle and includes an answer document in an electronic message. A receiving computer system receives the electronic message and verifies the answer document.

  See also the Microsoft patent application (with identical abstract) which addresses a network connectable receiving domain (rather than a sending computer system), and an act of receiving an electronic mail message (rather than an act of sending Transmission Control Protocol connection initiation data. "Reducing Unwanted and Unsolicited Electronic Messages by Exchanging Electronic Message Transmission Policies and Solving and Verifying Solutions to Computational Puzzles." United States Patent Application #20040181585. Patent application publication date: September 16, 2004. Patent application serial number: 683624. Filed: October 10, 2003. "Invention" attributed to: Atkinson, Robert George; (Woodinville, WA); Goodman, Joshua T.; (Redwood, WA); Lyon, James M.; (Redwood, WA); Williams, Roy; (Woodinville, WA); Ahmed, Khaja E.; (Bellevue, WA); Katz, Harry Simon; (Bellevue, WA); Rounthwaite, Robert L.; (Fall City, WA); Goldberg, Andrew V.; (Redwood City, WA); Dwork, Cynthia; (San Francisco, CA).

  Abstract: "The present invention provides for generating inputs that can be provided to a message classification module to facilitate more reliable classification of electronic messages, such as, for example, as unwanted and/or unsolicited. In one embodiment, a sending messaging server provides an appropriate response to address verification data thereby indicating a reduced likelihood of the sending messaging server using a forged network address. In another embodiment, it is determined if a messaging server is authorized to send electronic messages for a domain. In yet another embodiment, electronic message transmission policies adhered to by a domain are identified. In yet a further embodiment, a sending computer system expends computational resources to solve a computational puzzle and includes an answer document in an electronic message. A receiving computer system receives the electronic message and verifies the answer document."

  Comment and (legal) commentary on the Microsoft patent applications:

  • Analysis of Microsoft Patent Applications Pertaining to Sender ID. By John Levine. Posted to the IETF MARID WG mailing list 'ietf-mxcomp@imc.org'. September 17, 2004. See also published by CirdleID.
  • "Exposed Sender ID Patents Up Debate." By Jim Wagner. From InternetNews.com (September 20, 2004). Yakov Shafranovich doubts that the "invention," if any is embodied in the Microsoft patent, is the invention of Microsoft: "... A former co-chair of the ASRG [Anti-Spam Research Group], Yakov Shafranovich, questioned whether the patents actually reflected Microsoft inventions. In an e-mail to internetnews.com Shafranovich claimed that Microsoft had been tracking the progress of e-mail authentication schemes as far back as March 2003 on the Internet Research Task Force (IRTF) e-mail discussion lists, five months before filing for the two patents on Oct. 10, 2003. 'It was very clear to me as a former co-chair of ASRG that Microsoft simply took a developing standard in the IRTF, added a patent to it, and brought it back to the IETF,' he said in the e-mail. He contended that Microsoft's patents are based on ideas brought forward by the IRTF and that their applications could be invalidated on the grounds that prior art on the invention existed before the patent application..." [also from WinPlanet]
  • "Microsoft Patent Could Hamper E-Mail Authentication Group." By Matt Hicks. In eWEEK (September 17, 2004).

• [September 15, 2004] AOL Moves Forward With SPF. According to AOL spokesperson Nicholas Graham, as communicated by InternetNews.com, "AOL has decided to move forward with SPF." From the article "AOL Dumps Sender ID," by Jim Wagner:

  "AOL has withdrawn its support for Microsoft's controversial Sender ID technology and is falling back on Sender Policy Framework (SPF), internetnews.com has learned. Given recent concerns expressed by the Internet Engineering Task Force (IETF), coupled with the tepid support for Sender ID in the open source community, AOL has decided to move forward with SPF [Sender Policy Framework],' Nicholas Graham, AOL spokesperson, told internetnews.com via e-mail. Microsoft was not available for comment at press time. Despite the bombshell decision, the world's top ISP isn't completely severing its ties to Sender ID: The company still will publish Sender ID files so its users' e-mails are compliant with Sender ID-enabled servers and applications. But it's enough of a vote of no confidence in Microsoft's e-mail authentication strategy to warrant concern for Sender ID proponents. The Redmond giant has been steadfast in its refusal to disclose specifics on patents surrounding the Sender ID technology, saying only that the claims involve Sender ID and the Purported Responsible Address (PRA) algorithm used in conjunction with it. Microsoft also is requiring Sender ID implementers to sign a license agreement to protect those unspecified patents, the terms of which have the open source community up in arms. It's the second setback for Microsoft in a week: Over the weekend, the MTA Authentication for DNS (MARID) working group missed its deadline for moving the Sender ID specification onto the next step in the IETF standards process, the Internet Engineering Steering Group, and is currently working on re-drafting certain aspects of the technology to assuage critics..."

  References:

  • "AOL on Sender I.D." Posted by Carl Hutzler, AOL (Director, AntiSpam Operations, America Online Mail Operations). September 16, 2004.
  • "AOL Drops Microsoft's Sender ID." By Gregg Keizer. From InternetWeek.com (September 16, 2004).
  • "AOL Drops Microsoft Antispam Technology." By Jim Hu. From CNET News.com (September 16, 2004).
  • "AOL Dumps Microsoft's Sender ID. America Online is Taking On the Sender Policy Framework in Favour of Microsoft's Sender ID Approach." By Dan Ilett. From ZDNet News UK (September 17, 2004).
  • "AOL Dumps Sender ID." By Jim Wagner. From InternetNews.com (September 15, 2004).

• [September 11, 2004] IETF MARID WG Co-Chair Judgment of Consensus on Sender ID Last Call. On September 11, 2004 Andrew Newton posted an opinion of the co-chairs "relating to consensus within the MARID working group during the last call period of 23-August-2004 through 10-September-2004." With respect to Microsoft's patent claims and license agreement, the co-chairs ruled

  On the issue of ignoring patent claims, the working group has at least rough consensus that the patent claims should not be ignored. Additionally, there is at least rough consensus that the participants of the working group cannot accurately describe the specific claims of the patent application. This stems from the fact that the patent application is not publicly available. Given this, it is the opinion of the co-chairs that MARID should not undertake work on alternate algorithms reasonably thought to be covered by the patent application. We do feel that future changes regarding the patent claim or its associated license could significantly change the consensus of the working group, and at such a time it would be appropriate to consider new work of this type.

  Newton also wrote: "... it is also the opinion of the co-chairs that any attempt by the MARID working group to define any new scopes other than 'mailfrom' and 'pra' for the SPF syntax will at this time result in failure to find consensus within the working group. The document authors have agreed to producing new drafts intended to meet the chartered work item, and a consensus call on them or the appropriate diffs will be forthcoming. This work plan does not include scopes outside of 'mail from' and 'pra', and it is our opinion that no new work items of this type should be considered until MARID has successfully produced a first specification..." This reasoning and its language proved so clever, subtle, and convoluted that not all WG members understood what the ruling about the work plan meant, and not all press journalists were led to entirely correct conclusions about the co-chairs' ruling on what would happen next:

  • "Sender ID in Limbo." By Jim Wagner. From InternetNews.com (September 13, 2004).
  • "Microsoft E-Mail Proposal Dealt Setback." By Robert Lemos. From CNET News.com (September 13, 2004).
  • "Marid Working Group Moves to Reject Microsoft Sender ID." ByteEnable in LinuxElectrons (September 13, 2004).
  • "Sender ID Found Knocked Out, Sleeping In Ditch." By Ken Fisher. From Arstechnica.com. (September 13, 2004).
  • "MS Anti-Spam Proposal Returned to Sender." By Andrew Orlowski. From The Register (September 13, 2004).
  • "The Rumors of Sender ID's Demise Are Exaggerated." By Yakov Shafranovich. From CircleID (September 13, 2004).
  • "IETF Deals Microsoft's E-Mail Proposal a Setback. Intellectual Property Issues Could Plague Sender ID Standard." By Paul Roberts. In InfoWorld (September 14, 2004).
  • "Microsoft's Spam Plan Rejected." From BBC News (September 14, 2004).
  • "Email Sender ID: It's Not Dead Yet." By Joe Barr. From NewsForge (September 14, 2004).
  • "IETF Nixes Microsoft Sender ID Approach." By Keith Regan. In E-Commerce Times (September 14, 2004).
  • "IETF Shoots Down Microsoft Email Proposal." By Paul Thurrott. In WindowsITPro (September 14, 1004).
  • "Standards Group Rejects Microsoft's E-Mail Authentication Plan. The Internet Engineering Task Force Has Nixed Microsoft's Sender ID Proposal Because of Patent Concerns." By Thomas Claburn. In InformationWeek (September 14, 2004).
  • "Anti-spoofing Initiative Sender ID Grinds to a Halt." By Matt Whipp. In PC Pro (September 14, 2004).
  • Microsoft's Anti-Spam Proposal Rejected. Standards Group Cites Concerns Over Patent Claims." The Associated Press. From MSNBC News (September 15, 2004).

• [September 06, 2004] Debian Project Rejects Microsoft's Sender ID License Agreement Terms. On September 4, 2004 the Debian Project According to the mesage from Martin Michlmayr (Debian Project Leader): "This message summarises the position of the Debian project, producer of the universal operating system: Debian GNU/Linux. The Debian project abides by a social contract to our users that specifies all software included in the operating system will be Free Software, meaning that it can be freely redistributed, modified, used, etc. as defined under the Debian Free Software Guidelines (DFSG)... We believe the current license and resulting encumbrances are incompatible with the DFSG, unlike other Internet standards that Debian is able to support. Therefore, we cannot implement or deploy Sender ID under the current license terms. Indeed, we would be forced to remove SenderID support from software we ship that does support Sender ID upstream according to the terms of our social contract... We are also concerned that no company should be permitted intellectual property rights (IPR) over core Internet infrastructure. We believe the IETF needs to revamp its IPR policies to ensure that the core Internet infrastructure remain unencumbered..." See the posting to the ietf-mxcomp list and the copy on the Debian Project web site.

• [September 04, 2004] Earthlink Will Not Deploy Sender-ID. A message from Tripp Cox (based upon advice from Earthlink counsel) declared that the Sender-ID would not be deployed at EarthLink. Under the subject "Insufficient Microsoft IPR disclosure," the Earthlink statement cites "Timing of the disclosure" and "Substance of Grant and Lack of Disclosure" as two of the areas of concern for EarthLink. (1) Timing: "The IPR for the IETF requires timely disclosure of all relevant licensing terms. As stated in Section 6.2 of Intellectual Property Rights in IETF Technology: 'Timely IPR disclosure is important because working group need to have as much information as they can while they are evaluating alternative solutions'." (2) Disclosure of terms: "Microsoft's proposed license does not meet the requirements of the IPR. While Microsoft states that it is willing to license all of its potential IPR to implement the standard on a royalty-free basis, Microsoft must also disclose any other terms and conditions in connection with this license. The disclosure by Microsoft fails to indicate these terms and conditions. As a result, we are not able to determine whether the license granted by Microsoft will fully enable the full use of Sender ID within a proposed standard and if there are any other impacts to integrally related areas that may not explicitly be included in the standard but may be necessary to fully exploit the standard..." See details in the posting.

Technical Experts, Lawyers, Business Models, and Social Concerns

The controversy on the IETF MARID Working Group list about Microsoft's IPR licensing terms provides witness to a critical process question showing up with increasing frequency in standards development — especially in working groups where patent owners seek to have discussion about IPR issues declared off limits for the working group technical list: [to what extent] will the working group members be allowed to discuss IPR issues in connection with technical work?

• Position One

  • Engineering design within standards bodies is about science and technology, representing an expert domain and set of concerns entirely independent from legal, economic, and social domains
  • Design choices (viz., selecting technology solutions from among a set of competing alternatives) should be made independent of the legal, economic, and social implications, and especially, independent of concerns about licensing, so long as declared IP is offered on the minimal [RAND ++/--] terms as required by the sponsoring SSO/SDO
  • If you are an engineer serving on a working group or technical committee and you have questions about intellectual property and licensing claims made in connection with technology being incorporated into the draft standard, ask your company lawyers to contact the legal team of the company/companies making IPR declarations claims and setting licensing terms
  • If the license terms announced for IPR being incorporated into the draft standard are incompatible with the business model in your company, have your business managers discuss the issues with the business managers of the company/companies making IPR declarations claims and setting licensing terms
  • If you have concerns about the IPR being incorporated into the draft standard because of a perceived negative impact upon key segments of society, ask relevant consumer advocacy groups, legal clinics, and civil rights groups to study the issues and address them on behalf of the parties affected
  • If you have questions or objections to patent claims and licensing terms, do not introduce these into technical discussions of the working group; the various company representatives are engineers, not legal experts or product managers. Realize that the discussion list moderator is empowered by the SSO/SDO operational guidelines to remove you from the working group if you do not comply with this instruction [IEEE].
  • If you believe the IPR policy of the SSO/SDO hosting the standards work does not adequately support the concerns you have about patent disclosures in a particular case, appeal to the SSO/SDO IPR Committee, but do not detail your concerns in view of the working group

• Position Two

  • Engineering design in connection with public standards does not represent a set of concerns entirely independent from legal, economic, and social concerns; this convenient fiction serves the financial interests of companies having large patent portfolios and those seeking to dominate markets by incorporating their patented technology into standards
  • Informed selection of technology solutions from among a set of competing technical alternatives must allow all participant stakeholders to take into consideration a range of concerns beyond mere technical excellence: business models and social consequences of technology selection are two key factors that often merit open discussion
  • Members of a working group must be provided sufficient information about proprietary technology and licensing terms to help determine whether they wish to incorporate patented technology or whether they wish to consider alternative technical designs that are not thusly IPR-encumbered; sensitive weighing of the technical alternatives cannot be done optimally outside the technical committee process where qualified experts can discuss the feasibility of end-run solutions around patent roadblocks
  • Most companies cannot assess the risks and benefits of allocating technical (human) and financial resources to a standards effort without knowing what parts of the technology are proprietary and how the resulting standard will be licensed in terms of declared IP; general statements like "on reasonable, non-discriminatory and other [unspecified] terms governing unpublished pending patents" are inadequate
  • It is unrealistic and unreasonable to demand that considerations about business models and social impact of IPR-encumbered standards be ignored by members of a working group — on the assumption that other ad hoc private venues and SSO/SDO IPR (Meta-level) Committees are constituted and empowered to address these concerns independent of particular patents and particular design efforts

See the MARID WG archives on this point, e.g., "not salient for this list" (Ted Hardie, IETF Applications Area Advisor); "without regard to the IPR issue" (Andrew Newton and Marshall T. Rose, IETF MARID WG co-chairs); "this is not a technical issue" (Phillip Hallam-Baker).

About the Apache Software Foundation

"The Apache Software Foundation provides organizational, legal, and financial support for a broad range of open source software projects. The Foundation provides an established framework for intellectual property and financial contributions that simultaneously limits contributors potential legal exposure. Through a collaborative and meritocratic development process, Apache projects deliver enterprise-grade, freely available software products that attract large communities of users. The pragmatic Apache License makes it easy for all users, commercial and individual, to deploy Apache products.

Formerly known as the Apache Group, the Foundation has been incorporated as a membership-based, not-for-profit corporation in order to ensure that the Apache projects continue to exist beyond the participation of individual volunteers. Individuals who have demonstrated a commitment to collaborative open-source software development, through sustained participation and contributions within the Foundation's projects, are eligible for membership in the ASF. An individual is awarded membership after nomination and approval by a majority of the existing ASF members. Thus, the ASF is governed by the community it most directly serves — the people collaborating within its projects..."

Apache projects include, for example:

• Apache HTTP Server Project (commonly known as Apache httpd)
• Apache Ant Project (Java-based build tool)
• Apache Cocoon Project (Web development framework: separation of concerns, component-based)
• Apache Jakarta (server-side Java)
• Apache James Project (Java Apache Mail Enterprise Server)
• Apache SpamAssassin Project
• Apache Perl Project
• Apache Struts Project
• Apache Web Services Project
• Apache XMLBeans Project

Principal References

• "ASF Position Regarding Sender ID: Apache Projects Unable to Deploy Sender ID." Open letter to the IETF MARID Working Group, posted by Greg Stein (Chairman, Apache Software Foundation).
• Copy of ASF Position statement
• Microsoft Royalty-Free Sender ID for E-Mail Specification License Agreement [cache]
• Microsoft's Statement about IPR claimed in draft-ietf-marid-core-03 and draft-ietf-marid-pra-00. August 24, 2004.
• Earlier declaration: Microsoft's Statement about IPR Claimed in draft-atkinson-callerid
• Microsoft Standards Licensing Programs
• IETF MARID WG Sender ID specification:
  • "Sender ID: Authenticating E-Mail." By Jim Lyon (Microsoft Corporation) and Meng Weng Wong (pobox.com, Singapore). IETF MARID Working Group. Internet Draft. Reference: 'draft-ietf-marid-core-03.txt'. August 2004, expires February 2005. 12 pages.
  • Purported Responsible Address in E-Mail Messages." By Jim Lyon (Microsoft Corporation). IETF MARID Working Group. Internet Draft. Reference: 'draft-ietf-marid-pra-00.txt'. August 2004, expires February 2005. 6 pages.
• Press and commentary:
  • IETF MARID WG Co-Chair Judgment of Consensus on Sender ID Last Call (2004-09-11)
  • "MARID Floats Sender ID Compromise." By Jim Wagner. From InternetNews.com (September 8, 2004).
  • "MARID Dumps Microsoft." By Larry Seltzer. In eWEEK (September 10, 2004).
  • "Sender ID: A Tale of Open Standards and Corporate Greed? - Part II." By Yakov Shafranovich. From CircleID. (September 02, 2004). Yakov Shafranovich is software architect with SolidMatrix Technologies, Inc., and former co-chair of the Anti-Spam Research Group (ASRG) of the Internet Research Task Force (IRTF). See also Part I.
  • "Sender ID Loses Supporters." By Robert Lemos. From ZDNet News.
  • "Debian Refuses to Add Microsoft Anti-Spam Technology. Sender ID Licensing Terms Not Acceptable Says Open-Source Organisation. By Matthew Broersma. From Techworld (September 06, 2004).
  • "Motion to Abandon Sender ID." Posted to the MARID WG by Jonathan Gardner. September 01, 2004.
  • "Sender-ID or SPF Classic." Posted to the MARID WG by Chuck Mead . September 01, 2004.
  • "Conversation with MSFT Regarding License." Posted to the MARID WG by Matt Sergeant (MessageLabs). Report on Sender-ID meeting hosted by Microsoft on August 31, 2004. "... Ultimately I put it to him [Craig Spietzle, Microsoft] that the license would have to change should open source implementations of Sender-ID be a requirement for adoption. I pressed him: 'Will you fix the license?'. I never really got a confirmed yes or no, but my feeling was 'no' when we ended the conversation. I suggested that they give their IP to the IETF (such as I believe there is precedence of — I know that IBM has committed patents to the public domain before in a similar act of openness), to which I was told that Craig believed this was a reasonable idea, but that Bill Gates himself had vetoed that idea because of the current focus on patent gathering..."
  • "Sender-ID and Free Software." Posted by Richard Stallman to the IETF MARID WG list. July 24, 2004. "Microsoft's Sender-ID license is directly incompatible with free software regardless of which free software license is used. Free software means users are free to run it, study and modify the source, and to redistribute it with or without changes. Free to do so means there is no requirement to ask or tell anyone that you are doing so..."
  • "Sender ID Finds Followers Ahead of Approval." By Jim Wagner. From InternetNews.com (September 2, 2004).
  • "I Come to Bury Sender ID, Not to Praise It." By Larry Seltzer. In eWEEK (August 26, 2004).
  • "Open-Source Community Skeptical About Microsoft's Sender ID License." By Steven J. Vaughan-Nichols. In eWEEK (August 25, 2004).
  • "Spammers Using Sender Authentication Too, CipherTrust Study Says. Sender ID Technology May not be Effective at Stopping Spam, Survey Finds." By Paul Roberts. In InfoWorld (August 31, 2004).
  • "Keeping How The Net Works Open To All." By Bill Thompson. From BBC News (September 03, 2004).
• Apache references:
  • Apache Software Foundation web site
  • Apache Software Foundation Projects
  • Apache FAQ document
  • Apache James Project
  • Apache SpamAssassin Project
• Microsoft references:
  • Sender ID Framework - Microsoft
  • "Bill Gates Outlines Technology Vision to Help Stop Spam."
  • Sender ID Framework Solutions
• IETF references:
  • IETF MTA Authorization Records in DNS (MARID) Working Group Charter
  • MARID WG mailing list archive [ietf-mxcomp]. The ietf-mxcomp list is the mailing list for IETF's MARID Working Group. The purpose of the list is to discuss the creation of a mechanism to identify authorized senders for email from a domain, as a complement to the use of the MX RR.
  • IETF Page of Intellectual Property Rights Notices
  • IRTF Anti Spam Research Group (ASRG) Charter. On April 8, 2004 the IESG announced the approval of the MARID WG, chartered to continue work on the designated sender proposals discussed in the ASRG.
  • ASRG Home Page: Anti-Spam Research Group (ASRG) of the Internet Research Task Force (IRTF)
  • ASRG Status Page
  • ASRG FAQ document
• General:
  • "IETF Releases Anti-Spam Sender ID Internet Draft Specification." News story 2004-06-25.
  • "Email Spoofing Targeted in IETF Draft on MTA Authentication Records in DNS." News story 2004-06-02.
  • "Patents and Open Standards" - Main reference page.