|From: Seth Goodman Sent: October 20, 2004 6:22 PM
|
|An open letter to the SPF community, motivated by the
|following two postings to this list:
|
||From: Meng Weng Wong Sent: Monday, October 18, 2004 6:13 PM
||
||<..>
||
||The folks who asked me, back in January, to work with
||Microsoft to produce a single standard, would have to ask
||me to stop. Instead they have been emailing me directly
||saying "please keep going". They won't say it here,
||because we seem to have turned this mailing list into a
||cross between a kangaroo court and a witchhunt, but it's
||what I'm hearing. I think it is important to keep the
||domain owners in mind --- those millions of folks who will
||have to actually do the dirty work of publishing the
||records. Keeping things as simple as possible for them is,
||in my view, what will make all this a success --- not
||fighting over details that they will ultimately find
||irrelevant.
||
||From: Hallam-Baker, Phillip > Sent: Monday, October 18,
||2004 8:55 PM
||
||<...>
||
||In the real world a lot of decisions take place in what
||are now fortunately smoke free rooms but the principle is
||the same. In December last year there was a meeting at the
||Aspen institute where a number of Industry leaders and
||academics came together to work on the spam and net crime
||problems. Neither Meng nor Microsoft were present. Out of
||that meeting came an invitation only meeting at Harvard
||attended by all the major ISPs, the major email senders,
||the vendors, the proposers of the email authentication
||schemes. Each person present had been choosen specifically
||because they The overwhelming consensus in that room was
||that it would be better if there was one solution rather
||than SPF and SenderID The same sort of consensus has been
||present at every single email/spam conference Meng and I
||have attended over the past year - of which there have been
||many.
|
|I am grateful to Phillip and Meng for being honest as to
|where the decisions that have seemed so incongruous to the
|bulk of the SPF group have come from. It points to a
|fundamental disconnect between the people who have been
|laboring here for free on different aspects of SPF and
|those who attended those invitation-only meeting. Having
|worked in Engineering Management roles at large companies,
|I, too, have been in many meetings like the one Phillip
|described. While Phillip's statement that this is how a
|lot of things happen "in the real world" is certainly true,
|I can assure all of you that the open standards/open source
|world that we are working in is every bit as real as the
|one Phillip refers to. In our real world, however,
|decisions are made differently.
|
|This is an open standards group that works on consensus and
|builds open source software. Whatever goes on in private
|discussions does not and cannot represent the SPF group.
|While their wishes and desires are certainly of great
|interest to us, this is not their process, it is ours. If
|Phillip and Meng are acting on the wishes of a small
|private group against the positions clearly expressed by
|the majority on this list, both of them should immediately
|stop claiming to represent SPF in any way, shape or form
|and publicly dissociate themselves from the effort. They
|can certainly represent that private group at its pleasure,
|but not the people on this list.
|
|If that private group is indeed where Meng is taking his
|counsel, he is not representing our public SPF effort and
|has not been for some time. That cannot continue any
|longer and something has to change.
|
|I have nothing but admiration for all the hard work that
|you, Meng, have done to create the SPF community and you
|should be very proud of what has been accomplished. The
|fact that you took the advice of a small group of key
|industry figures and gambled on a merger with Microsoft was
|a calculated risk that unfortunately did not work out. We
|all knew it was risky and even though the majority did not
|agree, we trusted you to make that decision and take the
|risk on our behalf. At this point, that is all water under
|the bridge.
|
|Moving forward, however, it is abundantly clear that the
|majority here do not want to continue working with
|Microsoft and your contrary position has brought our work
|to a standstill. At this point, you can either continue to
|represent the small private group that you referred to, or
|you can represent the SPF group's wishes as expressed on
|this forum. You cannot do both. I am not encouraged by
|your characterization of the statements on this forum of
|hardworking volunteers as "a cross between a kangaroo court
|and a witchhunt". If the people who are privately advising
|you are afraid to air their views on this list, then they
|choose to disenfranchise themselves from the result. From
|my viewpoint, this is one of the more civil forums that I
|have taken part in and they have little to fear. Please
|make up your mind and let us know your decision so we can
|get on with this important work.
|
|--
|
|Seth Goodman
Seth,
Thank you for taking the time to put forward this open
letter to the SPF community.
I second your position.
Having said this, there are few matters, I wish to address.
* Mark was requested by this list to bring forward a draft
proposal for consideration by the IESG of what many call
SPF "classic." He did this. Everyone had an opportunity to
comment.
Unfortunately, after this proposal was submitted, Wayne
came forward with a "counter-draft." I must be honest and
say that I am disappointed with this approach.
There was no consensus to proceed in this direction.
Having said this, it appears Wayne has raised a number of
technical concerns. I will not comment on their merit.
The first additional question which needs to be raised is
whether it is appropriate to ask Mark to re-submit his
internet draft for further review by this group?
Should he agree, I would suggest:
* a statement of work be prepared;
* input documents be established;
* the discussion be moderated by a chair with the
assistance of a technical panel; and,
* prior to the submission of any revision, I urge this
group to consider using the services of the "graybeards" to
review the work.
I believe a systematic approach using these methods will
improve the ultimate work product.
As to a protocol for spf2, a couple of comments:
* Meng has stated he believes the best course is to develop
a protocol for spf2 which supports both SPF's mail from
checking and Microsoft's PRA checking.
* On the issue of "backward compatibility," Mark does not
support allowing the use of v=spf1 records for PRA
checking. Meng sees nothing wrong with allowing the use of
v=spf1 records for PRA checking.
The list consensus is that the community does not support a
protocol which allows the use of v=spf1 records for PRA
checking.
This is expressed in Mark's Internet draft for Sender
Policy Framework. See section 4.0. A third party may use a
different algorithm for the check host function, as long as
the result is the same. PRA checking will not give the same
result.
Some people have expressed support for PRA checking, but
the list consensus does not support a protocol for spf2
which specifically supports PRA checking.
Is there a way out of the problem of developing a protocol
for spf2, with Meng pulling in one direction and the
community at large pulling in a different direction?
It is self evident from recent discussions on this discuss
list that the community can put together an open source
protocol for mail envelope and message header
authentication for submission to the IESG.
An open source protocol which will allow:
* Most domain holders to publish a record without scopes,
it being understood a record without scopes can be used for
mail envelope and message header authentication; and
* Those domain holders with complex situations to publish
one or more records with scopes.
The real issue is whether Meng is prepared to allow this
work to proceed.
Unfortunately Meng can no longer can be or seen to be in
both the open source and Microsoft camp, if he wishes to
play a role in the development of spf2, given the list
consensus.
If Meng decides to continue to support Microsoft's approach
for message header authentication, then he has no choice.
However, I would go further and specifically ask that he
allow work to proceed on a spf2 protocol which does not
specifically support pra, but rather has a different name
for a scope for message header authentication, say mhc
(message header check, based on William's proposal) and
that he step aside from being involved.
Furthermore, if Meng allows work to proceed, I would
suggest:
* a statement of work be prepared;
* input documents be established;
* the discussion be moderated by a chair with the
assistance of a technical panel; and,
* prior to the submission of any drafts, I urge this group
to consider using the services of the "graybeards" to
review the work.
(I am building on Greg's analysis.)
Some may ask what about Microsoft's proposal for header
authentication?
If Microsoft wants to have a direct say in how spf2 is
written, come forward with the appropriate disclaimers and
a draft patent license which is compatible with the Open
Standard Alliance model.
If not, and Meng decides to continue to support Microsoft's
approach, Microsoft and Meng are free to use the protocol
for spf2 as developed and submit Internet drafts based on
this protocol, supporting Microsoft's proprietary solution
for message header authentication, subject to Microsoft's
"royalty free license."
However, the scope will not be called pra. Further, the risk
and responsibility of ensuring the proprietary algorithm
for the check host function generates the same result as
the open source algorithm will lie solely on Microsoft's
shoulders.
Otherwise, the proprietary solution is flawed and it is
wrong to use the domain owner's records in a "flawed"
protocol.
The IESG can then decide to move ahead with an experimental
proposal for spf2 which is encumbered or not encumbered.
Having said this, I appreciate that both Meng and Mark (as
the RFC editors) can say:
* We are not prepared to be bound by any further consensus
decisions on the spf-discuss list that precludes working
with Microsoft.
* We are going to prepare a protocol for spf2 that sets out
only the mail from and pra scopes.
* Those who wish to participate can continue to do so.
Those who are not prepared to participate can leave.
In which case, in my view, sadly this project as an open
source solution for dealing with spoofing and phishing will
likely come to an end.
I trust those who are writing to Meng privately will take
these comments into consideration in providing counsel.
Meng, I reiterate Seth's comments and second his position.
You can't have it both ways. As Seth said, either, you are
with the private group, or you are with the community at
large. Significant work is being held up. A decision is
required.
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