ietf-mxcomp
[Top] [All Lists]

Re: Work plan for Sender ID

2004-09-14 00:00:57


On Mon, 13 Sep 2004, Andrew Newton wrote:

First, the PRA document is not being dropped.  Instead, we are 
proceeding with a document set that includes a non-encumbered (as far 
as we know) scope, "mailfrom", in addition to the "pra" scope. 

Dont you think its more appropraite per IETF practice (and based on opinions
expressed by the majority of participants of this WG) to say and do the 
other way around, that should proceed on the non-encumbered scopes first 
and in addition may consider "encumbered" scopes if they bring enough 
benefits to make it worth deploying and if there are no non-encumbered 
alternatives that can achieve similar results?

As we  stated before, the objection to PRA is based on questions of 
deployment caused by incompatibilities with open source licenses.  

There have been significant number of objections to PRA on the technical
ground as well and most of these have not been answered. But IPR issues
caused so much more discussions that technical problems were not being
noticed. But to say that IPR issues with deployment is the only objection
to SenderID/PRA in its correction form is simply incorrect.

However, there were also a significant number for responses from 
participants stating that they had no such deployment issues.

I would point out that majority of those expressing support were large 
companies who are actually "end-users" that are willing to enter dns 
records for their domains. This is significantly less important then 
issues of software writers that have to implement capabilities to check 
these records.

Unless I'm mistaken opensource mail servers account for > 60% of deployed
email servers on the internet. You simply can not discount that majority
of them will not be implementing SenderID (because their email server
software package would not be implementing it).

Second, it does not make sense to discuss alternatives to PRA if those 
alternatives may be reasonably inferred to be covered by the patent 
I disagree. I do not believe we can reasomably infer if the aleternative
is convered by IPR unless that alternative is allowed to be presented.

There is also exist a very "interesting" way of finding out if alternative
is covered by IPR or not. One may send a draft as individual submission
and if Microsoft is aware of the draft being published, it will have to 
disclose that it has IPR claims on what is presented there if their
patent seems to apply for it. If they don't disclose it, we can assume
that the draft had no IPR claims and may then proceed working on it in WG.

application (though not necessarily the license) since this working 
group does not wish to discount Microsoft's patent application. 
There has not been clear consensus of WG wants or does not want to
discount Microsoft patent application, but the number of people on 
this WG arguing to ignore the patent claims were actually highier
then number of people that argued against it.

And since we do not know the specific claims of the patent application, 
construction of such an alternative would need to take into account a 
few things we do know:
    1. The patent application covers at least -core and -pra in 
combination.  There is no reason to think that Microsoft's application 
is limited to the technology in these two drafts.

Actually there are good reasons to believe that. Microsoft people have 
specifically commented that their IPR claims do not extend to any of the 
documents alone. This seems to imply that IPR issue is very specific to 
combination of those two documents and does not likely extend further.

    2. It does not cover MAIL FROM because this question has been 
specifically asked of Microsoft.
Good.

    3. The algorithm in -pra has changed through multiple revisions of 
the draft(s).
The changes were minor to account for cases of bad or incomplete header 
data. Order of headers in PRA algorithm has not changed.

This would seem to at least exclude any scopes that use 2822 headers to 
identify the party most recently responsible for injecting the message.

I completely reject this conclusion as not being based on the facts
presented so far to this WG.

Unless you know something of specifics of their patent that we dont I dont
see any base to believe that IPR claims is so widespread to cover ANY 
2822 headers that we may come up with.

Furthermore the "party responsible for injecting the message" is not the
only alternative available to us when working on algorithm that cover
previous hop in the email transaction. And I have alredy given an 
alternative that is not based on it, but based on "party responsible
for transmission of the message on its email network".
 
---
William Leibzon, Elan Networks:
 mailto: william(_at_)elan(_dot_)net
Anti-Spam Research Worksite:
 http://www.elan.net/~william/asrg/