From: Nico Kadel-Garcia
Sent: September 25, 2004 4:40 PM
----- Original Message -----
From: "John Glube" <jbglube(_at_)sympatico(_dot_)ca>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Friday, September 24, 2004 11:17 PM
Subject: RE: [spf-discuss] Disappointed, yet..not surprised
I can't speak to their present state of mind, but I would
concur in Anne's assessment that both Harry and Jim are
likely embarrassed with what has transpired.
John
John Glube
Toronto, Canada
Embarassed at the excessive claims of the patent itself,
embarassed because it seems to directly contradict claims
they made, or embararassed at getting caught? Which factor
embarasses them is important to dealing with them as human
beings.
None of the above. Embarrassed simply in the sense of being
unhappy with what had transpired when:
* Others characterized the IPR claims as applying beyond
that which had been represented by Harry Katz in good faith
to the MARID working group when making the IPR claims and
the specific representations made in response to a specific
question; and
* A press statement was made by someone else within
Microsoft which implicitly contradicted what Harry Katz had
said to the MARID working group.
As I said, from my personal inquiries, I believe that Harry
Katz and Jim Lyon acted honourably and in good faith in
their dealings with the MARID working group.
As to the scope of the patent applications, please note
that during the IETF open standards process, Harry Katz on
behalf of Microsoft only filed an IPR claim in relation to
the original Caller-ID draft protocol and subsequently in
relation to marid-core and marid-pra draft protocol
operating in combination.
The Marid-core protocol as presented by Jim Lyon
specifically excludes checking HELO/EHELO, MAILFROM or the
IP address.
At no time did Microsoft file an IPR claim in relation to
any of the other draft protocols, including the drafts
dealing with checking mailfrom or helo, helo/ehelo, or the
DomainKeys proposal.
Furthermore, Microsoft simply amended its IPR claim in
relation to marid-core and marid-pra draft to give notice
of the patent applications.
Despite the broad reach of the claims, I believe these
actions speak volumes.
In my view the representations made bar Microsoft from
endeavouring to apply for any patent beyond the marid-core
and marid-pra draft protocol operation in combination.
Of course, I am not an attorney, but in my view this is the
appropriate course given that Microsoft had agreed to
participate in an open standards process and is seeking a
patent claim in relation to one of the proposed open
standards.
If Microsoft was going to seek a patent claim on any of the
other proposed open standards which were put forward during
the MARID process and which may subsequently be blessed as
an IETF-experimental proposal and ultimately as a standard,
then it should have filed an IPR claim at the outset when
the particular draft was put forward.
Having not done so, while:
* Likely knowing all along that a great deal of work was
being done by the SPF community, the CSV folks and those
involved with DomainKeys;
* Specifically acknowledging in the marid-core and
marid-pra there was no interest in checking anything other
than the purported responsible address; and
* Having made specific representations the patent claims
did not apply to checking the mailfrom scope;
Means in my view Microsoft would be hard pressed to
subsequently pursue any infringement claim, even if the
patents were granted as presented.
http://www.cafezine.com/index_article.asp?deptId=4&id=291
The whole issue of the broad scope of the patent claims
came out after the claims were available for public
inspection. The alarm was raised by others.
(Please note, when the alarm was raised, it was suggested
MARID walk away from both SPF and Sender-ID.)
My personal concern arose when I read a press statement put
forward by an MS spokesperson other than Harry Katz or Jim
Lyon which implied that MS may have an IPR claim in
relation to checking the mailfrom and helo scopes under SPF
despite the representations made and all the events which
had transpired.
But it's pretty irrelevant to dealing with Microsoft's
behavior in SPF.
SenderID has proven itself to be IP encumbered, legally
tangled,
I agree it would be better not to have an open source
standard which is subject to a patent. Having said this,
the Open Software Alliance has put forward a model for any
license which is an appropriate compromise between
proprietary and open source.
Unfortunately, MS has not yet accepted this position.
Continued refusal will likely result in the MS proposal not
being widely deployed by network administrators, beyond
certain segments within the community.
and a software nightmare due to its requirement of XML
parsing by the MTA.
This was withdrawn in July.
All of this was predicted at the outset: by attempting to
get Microsoft to "buy-into" the SPF anti-forgery efforts in
the hopes of integrating it into their email servers and
larger services like hotmail.com, SPF has actually been set
back by at least six months in its approval as a new
standard, and perhaps set back even longer in implementing
new DNS changes to directly support it because now people
will associate SPF with Microsoft's SenderID system.
A decision was made to work with Microsoft. I appreciate
many people are upset with what happened and how events
unfolded.
At the same time, I suggest we need to look forward not
back, while learning from the mistakes.
Moreover, Microsoft has managed to claim a lot of credit in
trade magazines for the good work done by the SPF system
without acually contributing any useful code or development
to the effort.
Well, that is why the suggestion has been made by Anne
Mitchell that on a go forward basis there needs to be a
press/corporate person for the SPF community who is
knowledgeable and competent, so the mistakes made in the
past are not repeated.
Having said all of this, I need to make it clear from my
personal perspective the concern I have with checking SMTP
mailfrom for mail channel authentication as proposed is
that:
* It only allows for authentication based on the last hop.
* It involves breaking mail forwarding.
* Would checking SMTP mailfrom for mail channel
authentication create an excessive load on the DNS system?
* What about the shared MTA problem?
* With only last hop authentication, can this be used
reliably by reputation systems on large scale deployment?
I appreciate a great deal of effort has gone into resolving
these issues. However, I still have concerns with the
implications and whether these implications will thwart
large scale deployment.
(I continue to be concerned whether we may be coming at the
problem the wrong way. By this I mean would it be better to
use HELO/EHELO checking for mail channel authentication and
use SMTP mail from authentication for tagging the message
to prevent domain name spoofing. This does not preclude the
Sender Policy Framework, it simply means checking a
different scope. As to message authentication, through
checking the RFC 2822 FROM Header look to a light weight
cryptographic solution.)
As to checking the PRA under the present MS proposal for
message authentication, my concerns are that:
* The approach seems overly complex by introducing a new
parameter, which relies heavily on transport stage checks.
* What about the shared MTA problem?
* Will there be excessive demands put on the DNS system?
* It only allows for message authentication based on the
last hop.
* It involves breaking mail forwarding.
* It requires a resent header scheme which apparently
violates the Resent precept under RFC 2822.
* With only last hop authentication, can this be used
reliably by reputation systems on large scale deployment?
* As suggested by others, is there not a more effective and
efficient way to carry out message authentication?
* The proposed patent license is not compatible with open
standards and open source licensing based on the Open
Software Alliance model.
For these reasons, since the IESG has decided to move ahead
with IETF sponsored experimental standards, it was prudent
for the WG Chairs and Area Directors to decide to have the
draft proposals reviewed by a focused technical team to
ensure the proposals contain "no mechanisms that would have
deleterious effects on the overall email system," before
letting any specific proposal out of the gate.
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.766 / Virus Database: 513 - Release Date: 17/09/2004