spf-discuss
[Top] [All Lists]

RE: Why I think we should tolerate compatibility with PRA.

2004-10-02 22:00:44
From: Meng Weng Wong Sent: October 2, 2004 7:20 PM
 
<snip>

|After all that, if people feel that a policy of appeasement
|is misguided then please say so.  After all, appeasement
|has been known to fail in the past.

I personally don't like an appeasement policy. But neither
do I want to get into an all out standards war. 

The IESG or failing that group, the Federal Trade
Commission is the federal regulatory agency with the
authority to compel Microsoft to back off the draft patent
license, in the event of push versus shove.

From where I sit, PRA is a flawed technical approach to
solving the phishing problem.

It is a band aid at best and in my view may, if deployed on
a wide scale basis, even as an RFC experimental standard,
cause serious harm to the Internet Mail system.

At the same time, at any turning point there is always a
certain amount of leverage.

Option A:

Simply say no. I am not prepared to present the necessary
drafts to support PRA because the draft patent license is
not compatible with the Open Standards Alliance model.

Option B:

One presents the necessary drafts to support PRA but only
on terms.

The IESG asked the Area Directors to establish a
directorate to conduct a focused technical review of any
proposals put forward for approval as an RFC experimental
standard.

Present the drafts on terms and let the technical
directorate go ahead with its work.

Option C:

Simply present the drafts and let Microsoft proceed without
comment.

In taking this course, no feathers are ruffled. 

At the same time, there is no real assurance of Microsoft's
support.

Microsoft has already expressed its view that PRA checking
is superior to "mail from" checking. 

Therefore, during the course of any technical review,
should it get to the stage that "the chips are down" don't
be surprised:

* If Microsoft attacks SPF classic as being the inferior
approach which will in fact cause more harm if granted
approval as an RFC experimental standard; and,

* The technical directorate should therefore recommend
against SPF classic, while at the same time recommending in
favour of Sender ID without "mail from" checking.

I am not saying this will happen. I am simply saying don't
expect Microsoft to go to the wall for "mail from." It
won't.

Rather, expect Microsoft to:

* Tolerate "mail from" checking as part of the Sender ID
Framework, if that is the price it has to pay to get RFC
Experimental status for PRA checking; and,

* Denigrate "mail from" checking all the way through the
whole process.

This approach has already been made clear by the Spiezle
letter.

Spiezle's stance ultimately highlights for the prudent
buyer the underlying problems with both PRA checking and
mail from checking, being excessive load on the DNS system
and breaking mail forwarding.  

For this reason, as I have previously expressed, I believe
at day's end, the SPF community needs to squarely confront
these issues and take a radical change in course, rather
than get caught should the whole house come tumbling down.

However, that is a discussion for another day.

What do I suggest? Elect option B and write the following
note in response to the Spiezle letter:

|Dear Craig,
|
|I write further to your letter of September 24, 2004, copy
|posted to the spf-discuss list.
|
|Although there is some confusion as to what you meant by
|this letter, I take the letter as meaning:
|
|* Despite the broad scope of the patent applications,
|Microsoft Corporation in accordance with the
|representations made by its representative to the MARID
|list, is disclaiming any patent claims concerning
|techniques involving authentication of the SMTIP mail from,
|HELO/EHELO or IP address.
|
|Please confirm by reply correspondence that my
|understanding is correct so that I may proceed forward with
|the work on drafts, marid-protocol and marid-mailfrom to
|form part of the Sender ID Framework. 
|
|I thank you for your attention to these matters and look
|forward to receipt of your affirmative response at the
|earliest convenience.
|
|Yours truly,
|
|Meng Weng Wong
|
|P.S. As to Microsoft's draft patent license, there is a
|strong consensus within many parts of the Internet
|community that this license, although it may meet IETF
|requirements, is not suitable for use with an open
|standard, especially given the importance of email. 
|
|Therefore, for reasons which have been previously
|expressed, I urge Microsoft to reconsider its position and
|amend its draft patent license so that it is fully
|compatible with the Open Standard Alliance model, while
|protecting its own position.
|
|cc     Ted Hardie
|       Scott Hollenbeck
|       Andy Newton
|       Marshall Rose
|       SPF Discuss List

Why am I suggesting that you not take a harder position on
the draft patent license? 

Because, upon reflection I believe Microsoft's stance will
come back to haunt it. By urging Microsoft to reconsider,
while protecting the SPF community against any potential
patent claims which may interfere with existing or future
work, you have done your duty.

What is the potential response from Microsoft?

Option A:

Confirm the position and let the work proceed.

Option B:

Issue a letter which appears to comply, but leaves some
wiggle room.

Respond by pointing out the letter is ambiguous, point out
why and require clarification.

Option C:

Reject the position and insist the work proceed, or ignore
the letter and do the work themselves.

Should Microsoft take this stance, besides digging a
deeper hole for itself in the court of public opinion, then
you have the option of going to the IESG and asking for
guidance, while bringing Microsoft's position to the
attention of the Federal Trade Commission and releasing the
response to the media.

Personally, I believe Microsoft will elect Option A and get
on with life.

John

John Glube
Toronto, Canada


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