Subject: RE: consensus call on pra/mailfrom deployment and versioning/scope

From: "Harry Katz" <[email-masked]>
Date: Fri, 10 Sep 2004 15:17:11 -0700

On September 10, 2004 1:03 PM, John Glube [mailto:[email-masked]]
wrote:

> Harry,
> 
> I appreciate the point that:
> 
> >Microsoft's IPR disclosure clearly states that our IPR 
> claims relate to 
> >the maird-core and marid-pra specs used in combination.  We are not 
> >aware of any IPR claims on marid-core used in combination with some 
> >other specification.
> 
> I acknowledge that:
> 
> >... Administrators or any other end users of licensed Sender ID 
> >implementations do not require a license from Microsoft.  This is 
> >clearly stated in section 2.2 of the Sender ID license.
> 
> Perhaps I did not make my point clearly in my earlier note. 

Perhaps I misunderstood.  At any rate, thank you for taking the time to
clarify.

> So, let me give a specific example.
> 
> Let's say I am a software developer. 
> 
> A protocol is adopted which allows MTA's to do mailfrom 
> and/or pra checks. The specification includes 
> draft-marid-core (modified to include reference to mailfrom 
> checks as well as pra checks), draft-marid-pra and 
> draft-marid-mailfrom.
> 
> (This is somewhat speculative on my part, but we need a set 
> of facts for the sake of discussion.)

This is my understanding of the co-chairs proposal too.

> Microsoft has an IPR claim on using draft-marid-pra in 
> combination with draft-marid-core.
> 
> (I make this statement based on Microsoft's existing
> claims.)

Correct.

> I want to write a program which allows an MTA to run mailfrom 
> and/or pra checks using these specifications and then 
> distribute this program to end users.
> 
> The program will be a plug in, or filter which is designed to 
> work with any of the existing MTA's on the market.
> 
> The draft patent license contains the following:
> 
> Microsoft ... hereby grant You a perpetual ...worldwide 
> license under Microsoft's Necessary Claims to use ...
> object code versions of Licensed Implementations only as 
> incorporated into Licensed Products and solely for the 
> purpose of conforming with the Sender ID Specification.
> 
> (See section 2.1 of the draft Patent License.)
> 
> I appreciate that as long as I include the requisite notice:
> 
> You also have ... a ... license to distribute or otherwise 
> disclose source code copies of such Licensed Implementation ...
> 
> (See section 2.2 of the draft Patent License.)
> 
> The question is whether I can incorporate mailfrom checks in 
> my program, so that an end user can do both mailfrom and/or 
> pra checks using my software program?

Yes, you can.  We are not aware of any Microsoft IPR claim related to
spoof checking of MAIL FROM.  Therefore, the Sender ID license is
irrelevent for checking MAIL FROM.  

> My concern is with the last restriction in the draft patent 
> license which reads:
> 
> ... "and solely for the purpose of conforming with the Sender 
> ID Specification." 
> 
> I take this to mean "object code versions of Licensed 
> Implementations only as incorporated into Licensed Products" 
> can only be used to "conform with the Sender ID Specification."
> 
> (The Sender ID Specification being defined as the combination 
> of draft-marid-pra with draft-marid-core.)
> 
> On this point, please also note the following Q & A from 
> Microsoft's FAQ:
> 
> Q8: What if I want to use the Sender ID technology in some 
> other context, still related to email but perhaps not related 
> to Sender ID? Will Microsoft sue me? 
> 
> A8: Microsoft is committed to working with companies in a 
> collaborative way to license our Intellectual Property (see 
> http://www.microsoft.com/mscorp/ip/). If Microsoft is granted 
> patent rights that cover the Sender ID specification 
> (currently pending) it will make those rights available at no 
> cost for anyone to implement and use the Sender ID 
> specification. Microsoft will need to see what patent rights 
> are granted by the US Patent and Trademark Office to even 
> know for sure what rights it has to offer.
> Since it is impossible to contemplate every possible use of 
> it Sender ID patent rights we cannot make a commitment up 
> front to specific license terms. We invite anyone interested 
> in using Microsoft's IP to innovate and compete in the 
> marketplace to come talk to us. 
> 
> I want to use the Sender ID technology in a software program 
> which allows network administrators to run both mailfrom 
> and/or pra checks on incoming email to the network, or 
> outgoing email from the network she is administrating.
> 
> Can I do this under the license terms, or do I as per Q8 and 
> A8 need a separate license from Microsoft?

As I stated above, we are not aware of any Microsoft IPR claims on MAIL
FROM checking, so our license is not relevent.  So, to be as clear as I
can, if you're implementing spoof checks of both PRA and MAIL FROM under
the framework described in Core (and our patent application is granted)
then you would need a license for the PRA check but not the MAIL FROM
check.  If you are implementing spoof checking of MAIL FROM and _not_
PRA, we have no IPR claims, and no license to offer. 

> If I need a separate license then as I note in my earlier
> email:
> 
> As such, the restriction contained in the draft patent 
> Sender-ID license would preclude network administrators from 
> incorporating both mailfrom and pra checks without obtaining 
> separate permission from Microsoft.
> 
> To be totally clear, the concern should have read:
> 
> As such, the restriction contained in the draft patent 
> Sender-ID license would preclude network administrators from 
> incorporating both mailfrom and pra checks without the 
> distributor of any such Licensed Implementation obtaining 
> separate permission from Microsoft.
> 
> I trust this helps to clarify the issue raised in my earlier note.

Thanks.  Likewise, I hope I've answered your question.

---

From: "John Glube" <[email-masked]>
Date: Fri, 10 Sep 2004 23:14:01 -0400

Harry,

I appreciate the clarification as noted below:

As I stated above, we are not aware of any Microsoft IPR
claims on MAIL FROM checking, so our license is not
relevant.  So, to be as clear as I can, if you're
implementing spoof checks of both PRA and MAIL FROM under
the framework described in Core (and our patent application
is granted) then you would need a license for the PRA check
but not the MAIL FROM check.  If you are implementing spoof
checking of MAIL FROM and _not_PRA, we have no IPR claims,
and no license to offer. 

One comment:

* Depending on whether the WG does proceed further with the
consensus call as put forward by the co-chairs, I suggest
you may wish to amend the FAQ to reflect your answers.

John

John Glube
Toronto, Canada

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

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.752 / Virus Database: 503 - Release Date: 03/09/2004

---

From: "John Glube" <[email-masked]>
Date: Fri, 10 Sep 2004 23:27:12 -0400

Andy,

Thank you for facilitating an answer to my concern.

As Harry noted in his response:

>relevent.  So, to be as clear as I can, if you're
>checking of MAIL FROM and _not_ PRA, we have no IPR claims,
>and no license to offer. 

This answer clearly sets out the issue. The question
remains as to whether it resolves the problem.

A number of comments:

* Unfortunately, based on my read of the most recent
version of the FAQ, along with posts made to this mailing
list, there continues to be a fundamental issue surrounding
the lack of compatibility between Microsoft's draft patent
license with the GPL. 

From where I sit, this problem requires resolution for
smooth implementation of the consensus call. Why? One of
the driving forces behind pra is the expressed need of the
financial sector to control phishing attacks, along with
the general desire of all domain owners to thwart spoofing
and phishing attacks to retain brand integrity.

Without resolution between Microsoft and the open source
community this means pra checking will not be as widely
implemented, so diminishing the effectiveness of this part
of the layered defence for the benefit of those who need it
most.

As such this remains an underlying stumbling block which I
suggest the WG chairs must consider in deciding how best to
proceed with the consensus call.

* The other concern I have revolves around the lack of an
operational and security review by greybeards of both pra
and mailfrom checking. This is not a new issue.

Sender authentication, without implementation of reputation
and accreditation services along the Aspen model will not
achieve the ultimate objective of providing a reliable
methodology for UBE volume control.

(Please note, I do not believe we will ever be able to stop
abusive behaviour online. The best we can hope for is to
bring the problem under control.)

There has been much discussion on this list about the merit
or lack of merit of the two proposed "scopes" as
underpinnings for use in developing reliable reputation
models.

I strongly believe such a peer review would help to flush
out and resolve these issues, along with any underlying
operational and security issues. If nothing else, it would
certainly give added comfort to those who have to implement
all of this.

Until these two concerns are resolved, it remains my view
that this WG can only proceed with "pra and mailfrom" as
experimental protocols.

I find this position somewhat awkward. I want sender
authentication to succeed. I acknowledge there is a
dramatic sense of urgency. Email is broken and needs
fixing. I appreciate and support the vision. I acknowledge
a number of large organizations have stepped forward and
expressed a willingness to back "pra and mailfrom."

Yet, I am reluctant to proceed full steam ahead when I can
see cracks in the foundation which I believe will come back
and bite us all at the end of the day.

Thank you again for taking the time to listen to my
concerns.

John

John Glube
Toronto, Canada

---