Michael,
You write ...
|I would rather see pra as an allowable scope under spf2.0
|with a separate experimental draft put forward by Microsoft
|specifically for pra checking implementation. spf2.0 might
|also allow other scopes as well.
|
|This sidesteps the issues of licensing, provides a neutral
|playing field, allows people to choose which pieces they
|will (or will not implement) and in addition enables
|everyone to move forward at their own pace without the
|process breaking down as it did in the MARID group.
I respect your position, and to be honest, when this whole
situation came up at MARID, I thought this approach might
work.
Let me explain the problem. PRA checking to be of any value
requires wide spread deployment. Carl Hutzler in his
message makes this point.
The Apache Foundation and others have made it clear they
can't deploy PRA checking without a patent license that it
is compatible to the Open Standards Alliance model.
To date Microsoft has refused to accommodate the request.
We all understand that phishing is a major problem. No one
wants to stand in the way of a solution using the RFC 2822
From Header which could help to aid in dealing with this
issue, even though many feel RFC 2821 Mail From checking is
a better or at least an equivalent solution.
On the other hand, what is the point of going through the
whole hoopla of even considering supporting a technical
solution (which some argue is flawed and violates existing
RFC's) to address this problem, when we know up front the
draft patent license put forward by the proponent is going
to be an impediment to widespread implementation.
People have asked that SPF consider changing the draft
protocol for version 1 to allow these records to be used
for PRA checking.
But, we know this is potentially a technical boondoggle as
pointed out in the comments by you and others.
It is for these reasons, why I am saying:
* There is no point in having a technical discussion about
accommodating PRA either in version 1 (if that is possible)
or in version 2 (which is more likely) unless we know there
can be wide spread deployment.
* As long as Microsoft insists on having a draft patent
license which is not compatible with the Open Standards
Alliance model, since the vast majority of mail servers use
software which is open source and the license is not
compatible as made clear in the public statement of the
Apache Foundation, there can't be wide spread acceptance
and therefore PRA checking won't take off.
* So, what is the point of going through an exercise,
fraught with difficulty and upset, when we know in advance
it is likely going to be a wasted effort.
This is why I am responding to those wanting SPF to support
PRA checking, by saying first fix the license so everyone
in the community can consider using the specification.
Don't want to fix the license, fine. We will write up a
record called "sid" for you, which we will hold the RR for,
which supports PRA on its own and you go out and flog your
encumbered solution.
But understand we are not going to support PRA checking
through SPF due to your license, we will not assist in
coding your solution, you may not claim any open source
support for this approach because this is not the case, nor
may you claim your license is compatible with an open
standard, because it is not.
Also understand we are working on an alternative open
source solution which is not encumbered that will be
supported by SPF and that can be widely adopted.
The point being that today, the focus is on Microsoft. Fix
the license to allow for widespread adoption and that is
where the focus needs to stay.
Some want to change the focus and paint SPF as being
difficult. Forget it. The focus needs to remain on the
party which created the difficulty in the first place.
In the meantime, until Microsoft comes to the table with
the appropriate form of draft patent license, along with
confirming the representations made during MARID, without
the "on the one hand this, on the other hand that
statements," the SPF community can simultaneously:
* Work on a protocol for sid (which shows our good faith to
the process);
* Work on spf v2, which can provide an end to end solution
without the need for sender rewriting or submitter schemes,
and depending on whether it makes sense include a truly
open source solution to the problem of RFC 2822 From checks
as a plug in.
I appreciate the hardest thing to do is to say no. But,
just as the IESG shut down MARID due to lack of consensus,
let's politely say, we would be glad to talk, when you can
show us you can achieve wide spread deployment.
To date, you can not do this because your license is not
compatible with the Open Standards Alliance model.
In this regard, see in part the public statements of the
Apache Foundation and its counsel, Lawrence Rosen.
Since we are a group of volunteers, our time is precious.
We need to focus our energies on those areas where we can
get the most effective results.
When Microsoft is ready and can come to the table with a
license which is fully compatible with the Open Standards
Alliance model, along with the appropriate disclaimers as
to its patent application as unequivocally made during
MARID, we will be glad to see how we can accommodate your
needs.
In the interim, our response is as outlined above.
I apologize for going on at length, but it is important
people understand, by everyone in the open source community
saying no at the beginning and holding firm, I am of the
view at days end Microsoft will "see the light" and this
will save everyone much heart ache and wasted effort.
And if they don't, fine - off you go MS with sid and you
can deal with all the issues surrounding your proposal and
license, but don't look for cover, comfort or succour from
us, because we can't help. Our time is simply too valuable.
Trusting this helps.
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.776 / Virus Database: 523 - Release Date: 12/10/2004