Sender ID, Will Microsoft Own E-Mail?

Straight Talk - An Open Letter To You

For The Record, Will Microsoft Own Email?

by John Glube, © 2004, all rights reserved of
Head's Up - A Copywriter's Journal

The sender authentication saga continues. The question for the day? Will Microsoft own email? Not possible you say. Then listen up and pay attention.

In the early spring of this year, the IETF set up a working group called MTA Authorization Records in DNS (MARID) to look into a proposed standard for sender authentication.

Despite a lot of hard work, it was ultimately decided to shut down this working group.

MARID Closes

Why? Well the notice announcing the closure tells parts of the story.

However, even though the group was closed, according to the notice, work would continue:

"Rather than spin in place, the working group chairs and Area Advisor believe that the best way forward is experimentation with multiple proposals and a subsequent review of deployment experience. The working group chairs and Area Advisor intend to ask that the editors of existing working group drafts put forward their documents as non-working group submissions for Experimental RFC status. Given the importance of the world-wide email and DNS systems, it is critical that IETF-sponsored experimental proposals likely to see broad deployment contain no mechanisms that would have deleterious effects on the overall system. The Area Directors intend, therefore, to request that the experimental proposals be reviewed by a focused technology directorate. This review group has not yet been formed but, as with all directorates, its membership will be publicly listed at http://www.ietf.org/u/ietfchair/directorates.html once it has been constituted."

Microsoft's Patent Claims

Prior to the shut down of MARID, Microsoft filed an amended intellectual property rights (IPR) claim giving notice of publication of its patent applications.

Now, this is important. Microsoft in filing its IPR claims originally did so in relation to its Caller-ID specification.

Subsequently, when the drafts outlining the specifications for Microsoft's proposal were presented for last call before the MARID working group, (last call being when everyone can raise any concerns or objections) being the combination of the specs called "Purported Responsible Address in E-mail Messages", file name draft-ietf-marid-pra-00.txt, ("marid-pra") and "Sender ID: Authenticating E-mail", file name: draft-ietf-marid-core-03.txt, ("marid-core"):

* Microsoft filed an IPR claim concerning the operation of these specifications in combination;

* In response to direct questions, a Microsoft representative told MARID that its IPR claims did not apply to the protocol for Sender Policy Framework, marid-core operating alone, meaning Microsoft was not making an IPR claim against sender authentication methods involving SMTP mailfrom, EHELO/HELO or the IP address, and further confirmed that the draft patent license did not have to be signed by software developers who were seeking to implement mailfrom checking as the patent claims did not apply to mailfrom checking, commonly called Sender Policy Framework, or SPF for short;

* When Microsoft gave notice of publication of its patent applications, filing an amendment to its IPR claim, it did so only in relation to the operation of "marid-core" and "marid-pra" in combination.

The significance of these facts? Though the patent claims are quite broad and seemingly extend far behind the original Caller-ID specification or the operation of "marid-core" and "marid-pra" in combination, by only giving notice of the IPR claims as stated, along with the specific representations as made during last call, it is my understanding, by reason of these representations the relevant part of the claims are limited to the original Caller-ID specification and the subsequent specifications of marid-pra and marid-core operating in combination.

The Press Release

However, on September 21, 2004 (one day before MARID was closed by the IESG), John Levine, chair of the Anti-Spam Research Group and author of the Internet for Dummies, published an article in "CircleID" titled "An Analysis of Microsoft's MARID Patent Applications".

On the same day, in response to an inquiry from an Internetnews reporter about Microsoft's intent, due to the broad patent claims, the following statement was made:

"Microsoft would not comment on specifics of the patent application but a spokesperson sent an e-mail stating:

The SPF technical alternative is just now becoming a real focus for the IETF. It is premature for the standards participants to disclose any IP they may own related to SPF. If SPF continues to work its way through the process, there will likely be a point where Microsoft and others will [be] asked to identify any essential IP claims and Microsoft will follow the IETF guidelines for disclosure at that time."

Talk about dropping a bomb shell. Having told everyone at MARID we only have an IPR claim concerning the Caller-ID specification and the operation of "maid-core" and "marid-pra" in combination, Microsoft was now apparently saying, well yes ... we may have an IPR claim concerning SPF.

(For the record, the reader must understand that to the best of my knowledge, the Microsoft representative who was responsible for filing the IPR notices and making the referenced representations to the MARID working group was at all times acting honourably and in good faith.)

The Spiezle Letter

In an effort to clear the air about its plans, Microsoft released a letter by email late Friday afternoon, (24.09.04). A copy was posted to the MARID mailing list:

"Subject: Sender ID Update & Plans

Dear [ ],

Over the past few months there have been several developments with the IETF and the status of the Sender ID Framework. The following mail is intended to provide clarify to the status and Microsoft's implementation plans.

After discussion with the IETF MARID chairs, we jointly agreed to move forward with a proposal that provides implementers the choice of utilizing PRA or MAIL FROM for the Sender ID check mechanism. While the working group has recently shut down, we continue to work with the chairs and key stakeholders to move forward. Based on these recent discussions we have agreed to insure backward compatibility to SPF1 records. We believe this will help accelerate adoption for the early adapters and insure the majority of e-mail senders do not have to make any record changes. We anticipate these revised Sender ID specs will be published within the next week and posted at www.microsoft.com/senderid.

While we would have preferred a single technical mechanism as the standard, we believe the specification to allow multiple scopes in the protocol is a reasonable approach, providing choice and flexibility. For Microsoft's implementation, we continue to move forward to utilize the PRA check because it examines header information in email, which we believe, provides a more reliable method to detect forged mail and phishing attempts. We also believe it will be easier for forwarders and other email intermediaries to adapt their practices and software to Sender ID. Later this fall Microsoft plans to publish both records for our customers, but will only be utilizing the PRA check for our customers.

I would also like to clarify several misstatements pertaining to our license and patents. From the onset, Microsoft has confirmed that any potential patent rights that Microsoft may eventually be granted will be provided to all users, implementers and distributors of the Sender ID specification under Microsoft's royalty free license. Microsoft will not revoke its offer to extend this license to anyone now and in perpetuity. The information disclosed by Microsoft regarding its patent applications and its license terms meet and exceed the IETF requirements for such disclosure.

Moving forward, Microsoft will continue to invest in research to combat spam and phishing. Innovation and investments in these technologies are paramount to insure the reliability and deliverability of e-mail, confidence in online commence and to protect the brand and reputations of businesses throughout the world.

In summary, I want to assure you that Microsoft remains committed to Sender ID. We look forward to continuing our collaboration with [ ] to help move this important authentication protocol forward.

If you have any questions or concerns, please don't hesitate to call.

Craig Spiezle
Microsoft Corporation
Director, Safety Technology and Strategy Group"

The Response

Hmm ... sounds great.

(Even though the working group was closed, the mailing list remains active to allow for posting of notices and the like)

Well, not so fast. Earlier this morning, after spending the weekend reading and thinking, I sent the following note to the MARID mailing list, with a copy to Craig Spiezle:

"Thank you for posting the Speizle letter.

Although the Microsoft patent applications are quite broad, I took solace from the good faith representations made in the IPR filings and to the MARID list as to the actual scope of these claims.

On September 21, 2004, a press spokesperson for Microsoft is reported to have sent an email to Internetnews which read:

"The SPF technical alternative is just now becoming a real focus for the IETF. It is premature for the standards participants to disclose any IP they may own related to SPF. If SPF continues to work its way through the process, there will likely be a point where Microsoft and others will [be] asked to identify any essential IP claims and Microsoft will follow the IETF guidelines for disclosure at that time."

http://www.internetnews.com/dev-news/article.php/3409971

This reported statement was cause for concern upon my part.

I had hoped that Microsoft would clarify matters and simply confirm the previous good faith representations.

Unfortunately, I remain concerned. Let me explain.

In the letter, Craig Speizle writes:

"I would also like to clarify several misstatements pertaining to our license and patents. From the onset, Microsoft has confirmed that any potential patent rights that Microsoft may eventually be granted will be provided to all users, implementers and distributors of the Sender ID specification under Microsoft's royalty free license. Microsoft will not revoke its offer to extend this license to anyone now and in perpetuity."

The phrase "the Sender ID specification," is not defined in this paragraph, except by reference to "Microsoft's royalty free license."

In the second paragraph of the letter, Craig Speizle writes:

"After discussion with the IETF MARID chairs, we jointly agreed to move forward with a proposal that provides implementers the choice of utilizing PRA or MAIL FROM for the Sender ID check mechanism."

And in the third paragraph of the letter, Craig Speizle writes:

"While we would have preferred a single technical mechanism as the standard, we believe the specification to allow multiple scopes in the protocol is a reasonable approach, providing choice and flexibility."

The patent applications are quite broad in scope. Even though the term "Sender ID specification" is presently defined in "Microsoft's royalty free license," there is nothing in the letter to preclude Microsoft from amending this definition to fit with any patent rights which Microsoft may subsequently be granted.

We are therefore left with two possible interpretations of the meaning of the phrase "Sender ID specifications" in the letter:

1. "Sender ID specification" means: (i) the original caller-id specification; (ii) the marid-core and marid-pra specification as defined in Microsoft's draft patent license; (iii) any amendments to the marid-core and marid-pra specifications or equivalent substitutions thereof, but which are not based on SMTP mailfrom, EHELO/HELO or the IP address, as may occur in obtaining IETF-experimental status and IETF-standard track for these specifications.

2. "Sender ID specification" means: (i) the original caller-id specification; (ii) the marid-core and marid-pra specification as defined in Microsoft's existing draft patent license; (iii) the marid-mailfrom specification; (iv) any IETF - experimental set of protocols involving either mailfrom or pra checking based on the existing or any amended specification; (iv) any IETF - standard set of protocols involving mailfrom or pra checking based on the existing or any amended specification; (v) any other method of sender authentication which falls within the scope of Microsoft's patent rights and forms part of the "Sender ID check mechanism."

I also note that:

* Microsoft's existing draft patent license is not compatible with the Open Standards Alliance model.

On what is meant by the Open Standards Alliance model, a conference was held Fairmont Scottsdale Princess resort in Arizona during September 13 - 14, 2004. The conference title:

"Open Source, Open Standards: Maximising Utility While Managing Exposure"

The conference was organized by the Open Standards Alliance.

http://www.openstandardsalliance.org/

At the conference, Larry Rosen gave a keynote speech on the issue of the compatibility of Open Standards with Open Source software licensing.

I quote from the official conference statement:

"Larry Rosen proposed five normative principles for open standards that are compatible with Open Source software licensing.

The five principles of open source software are:

1. Licensees are free to use open source software for any purpose whatsoever.

2. Licensees are free to make copies of open source software and to distribute them without payment of royalties to a licensor.

3. Licensees are free to create derivative works of open source software, and to distribute them without payment of royalties to a licensor.

4. Licensees are free to access and use the source code of open source software.

5. Licensees are free to combine open source and other software.

Compatible principles

Mr Rosen put forward compatible principles for Open Standards:

1. Everyone is free to copy and distribute the official specification for an open standard under an open source license.

2. Everyone is free to make or use embodiments of an open standard under unconditional licenses to patent claims necessary to practice that standard.

3. Everyone is free to distribute externally, sell, offer for sale, have made, or import embodiments of an open standard under patent licenses that may be conditioned only on reciprocal licenses to any of the licensee's patent claims necessary to practice that standard.

4. A patent license for an open standard may be terminated as to any licensee who sues the licensor or any other licensee for infringement of patent claims necessary to practice that standard.

5. All patent licenses necessary to practice an open standard are worldwide, royalty-free, non-exclusive, perpetual, and sub-licensable."

* I believe it is fundamental that open standards which are subject to patents and/or patent claims must be subject to actual or draft patent licenses which are compatible with open source licensing standards as set out in the Open Standards Alliance model to ensure the continued vibrancy of the Internet.

* Email is presently one of the core reasons people use the Internet.

* Based on what has already transpired, I suggest it is self evident that any proposal which supports PRA will run into trouble, during any public comment process prescribed by the IETF as long as Microsoft persists in requiring a patent license which is not compatible with the Open Standards Alliance model.

In the circumstances, I believe it is incumbent upon Microsoft to confirm that:

* "Sender ID specification" means: (i) the original caller-id specification; (ii) the marid-core and marid-pra specification as defined in Microsoft's draft patent license; and (iii) any amendments to the marid-core and marid-pra specifications or equivalent substitutions thereof, but which are not based on SMTP mailfrom, EHELO/HELO or the IP address, as may occur in obtaining IETF-experimental status and IETF-standard track for these specifications.

* "Microsoft's royalty free license" will be fully compatible with the Open Standards Alliance model.

Otherwise, it is highly likely there will be a hue and cry during the public comment process of any experimental proposal put forward by Microsoft as called for under sections 4.2.3 and 6.1.2 of RFC 2026.

But perhaps more importantly, without fully clarifying matters, in my opinion, based on what has transpired to date, Microsoft runs the risk of placing the IETF's credibility in jeopardy as a standards organization.

Having made these comments, I add that I have every reason to consider Craig Speizle is personally acting in good faith, based on legal guidance and in what is perceived as Microsoft's best interest.

However, given the potentially contentious nature of this matter, along with the import to email as a viable means of communication and the risk to the IETF itself, I call upon Microsoft, as one of the leading software firms in the world, to fully clarify matters for the record beyond a shadow of a doubt.

John Glube
Toronto, Canada

The FTC Calls For Sender Authentication
http://www.learnsteps4profit.com/dne.html"

Why Is All This Important?

So, why is all this important? I mean why should the online business community care? Let me be as blunt as I can. Do you use email in your business?

Do you want Microsoft "owning" the sender authentication protocol for e-mail as ultimately approved by the IETF and so potentially controlling e-mail?

No? Then, stay tuned people, because what is going down will have a bearing on all our businesses.

What About Prior Art?

Yes, there has been a lot of discussion about the Microsoft patent applications not being granted, because of prior art.

Making a very long story short, in essence due to some rule changes in the United States Patent Trade Office made in the early 1980's to make it easier for people to obtain a patent, along with a subsequent lack of funding to deal with the flood of applications, the reality is most patent applications are granted.

Why? Examiners don't have the time to delve into every application. By default, the issue of patent validity is being left to subsequent court litigation during infringement actions. The upshot? A lot of patents are being granted on software applications which should simply not be granted.

For those who interested in digging deeper into the subject, read the article by Sabra Chartrand in the New York Times on 27.09.04 titled "Does the Patent System Need an Overhaul?"

Want to really want to get into the topic? The Federal Trade Commission did an excellent study on the subject called To Promote Innovation: The Proper Balance of Competition and Patent Law and Policy.

The Moral Of The Story

As business people, we can learn a number of things from this saga. First, be consistent in your message. Here Microsoft's technical representative in good faith sent one clear message, our patent claims only apply to marid-core and marid-pra operating in combination. The press spokesperson said another, implying Microsoft had an IPR claim against SPF, which had been previously disclaimed by Microsoft's technical representative. When the two collided, there was an explosion.

When there is a problem and there is a need to rectify an issue, leave no ambiguity. The sentence dealing with the patent claims is not crystal clear, being open to at least two interpretations. The relevant part of the letter:

The letter is not a legal document and some will argue, the phrase "the Sender ID specification under Microsoft's royalty free license" means the operation of marid-core and marid-pra in combination. However, those who were reading the letter understood these documents needed amendment. Under the IETF process, significant changes might occur. Also, we had the press statement, which implicitly contradicts the good faith representations made to the MARID list. Taken in context, by not stating "the Sender ID specification under Microsoft's Royalty Free License, it being clearly understood Microsoft disclaims any intellectual property interest in sender authentication methods based on SMTP mailfrom, EHELO/HELO or the IP address," the statement made is certainly ambiguous.

As to the compatibility of the draft patent license with open source software licenses, many people had told Microsoft well in advance there was a significant problem with there existing draft patent license and unless rectified, this would likely result in rejection of Microsoft's proposal. When putting forward a proposal, there is a need to take into consideration the interests of others. Especially when the proposal involves changing a matter of fundamental import for the community at large. For large corporations, with dominant market power, this becomes even more important.

Microsoft did make some changes to the original draft patent license. However, the record on the MARID list is clear. A decision was made at the highest levels to ignore the protests. Rather let the proposal die then accomodate the concerns. In the circumstances, pressing forward, without clearly indicating a willingness to continue to work on resolving the outstanding issues is either the height of hubris or pure folly. In fairness, the demand of the open source community representatives for a stronger warranty statement perhaps goes to far, as I appreciate Microsoft's need to disclaim liability.

However, a reasonable alternative license form was presented, but todate, this has been ignored. Having said this, the decision to proceed with putting forward experimental RFC IETF sponsored specifications, subject to a focused technical review to ensure no proposal will have deleterious affect on email through wide deployment, while still allowing for public comment, proceed with deployment experience and then work on one or more final standards makes eminent good sense.

The underlying question? As long as Microsoft fails to honour the earlier good faith representations, having placed these representations in doubt and failing to clearly disclaim any potential intellectual property claims on other forms of sender authentication, while refusing to budge on its draft patent license, should its proposal be allowed to proceed? The answer is clear.

An Update

Since first writing this article, a number of things have changed.

On October 22, the report from the 2nd OECD Workshop on Spam held in Busan, Korea on 8-9 September 2004 was completed, with the final draft being released on November 2, 2004.

Why is this report important? Because it provides a good overview of where things are really going with authentication. I recommend you read paragraphs 30 to 45 in particular.

Next up on the hit parade was the release on October 27, 2004, by Microsoft of its amended frequently asked questions concerning the draft patent license. The key change was the answer to question 5.

"Q5: Who needs to execute a license with Microsoft?

A: It’s important to note that the license is only relevant to those organizations (ISP, large enterprises)who will be checking e-mails using the PRA check alternative of the Sender ID Framework need to secure a license. Those simply publishing their Sender ID records do not need this license."

This statement confirms a key representation made to the MARID working group that Microsoft's patent application did not apply to MAIL FROM checking.

Is it possible my actions, along with those of many others had anything to do with this change in position? Don't know, but what it does tell me is that Microsoft will change its position if the proper steps are taken.

On November 1, 2004 the revised specifications for the Sender ID Framework were submitted to the IETF for review by the technical directorate to be created by the Area Directors. This is the next step in the process of SIDF considered as an IETF sponsored experimental proposal.

Next big announcement? On November 4, 2004 the Messaging Anti-Abuse Working Group announced its members, which include many of largest Internet Service Providers were going to evaluate both parts of the Sender ID Framework and Client SMTP Validation which forms part of Compatible Low-overhead Email Authentication and Responsibility (CLEAR) and recommend the appropriate authentication protocols.

Then in anticipation of the Email Authentication Summit was the delivery of a letter to the FTC and NIST by 30 corporations, groups and one individual, including Microsoft stating in part:

"A recommended strategy is to 1) adopt SIDF today and publish Sender Policy Framework (SPF) text records, and 2) as signature solutions mature, adopt them as well, thereby complementing SIDF to achieve a higher level of authentication."

While I heartily agree that we need to move ahead with authentication as the touch stone for accreditation (reputation) one has to wonder why the aggressive approach, especially when the IESG has yet to complete its focused technical review as mandated after the collapse of MARID.

What To Do?

Okay ... Do you believe that core parts of the Internet infrastructure like email should not be subject to potential control by one group?

Want email to continue to be a useful means of communication? Believe that in fighting online crooks and thieves a layered security approach is required?

An approach which does not break the existing infrastructure, while giving receivers useful information and allows legitimate senders to get their email delivered?

Concerned the aggressive stance being taken by Microsoft in pushing one scheme for IP/Domain based authentication that is subject to a draft patent licence which is not compatible with the Open Standards Alliance model raises more questions than it answers?

Feel like writing a letter? Or sending an email?

The Federal Trade Commission is holding (or depending on when you read this has held) a Sender Authentication Summit on November 9 - 10, 2004.

To aid you in your thought process, I have prepared an open letter to the Federal Trade Commission and National Institute of Science and Technology. Feel free to borrow some or all of this letter.

Here is what you have to do. Write a letter directly to Senator McCain who chairs the US Senate Committee on Commerce, Science & Transportation, or to the Committee itself expressing your concerns, with a request to have your concerns sent to the appropriate regulatory agency.

(I am suggesting this Senate Committee as it has oversight responsibility for the Federal Trade Commission.)

Why not tell the Senate Committee what you think? You can make it short by simply referencing this article.

Well ... that's it for now. Thank you for your time.

--------------------------------

John Glube, Publisher and Editor of Head's Up, A Copywriter's Journal. Not yet subscribed to the Journal? To get all the details Use This.

--------------------------------

First Published 27.09.04. Amended 28.09.04; 09.11.04