spf-discuss
[Top] [All Lists]

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

2004-10-03 02:50:26
From: "Meng Weng Wong" <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com>

First off - - I'd  like to say that I am *very* grateful to Meng for taking
the time to open his mind to us.  This paves the way to a much greater
understanding of motives.


I have no formal training in political theory, but I have
studied systems architecture, which is about designing
systems that work for many stakeholders whose interests are
generally compatible but can sometimes conflict.  By that
definition systems architecture and legislative politics
have a lot in common.

This is fatally flawed - Systems architecture doesn't have egos - politics
deals with little else.  History is riddled with examples of good political
decisions *not* being made because of the in-fighting of the egos involved.


The pattern identifies two principles: on the one hand, we
have inclusiveness; on the other, control and dominance.

Whilst you define the extremes, it behoves us to remember that there are
many shades of grey between the black and the white.  The truly great path
is to include only those things which are beneficial to some, but harm none;
to have sufficient (but no more) control so that what is included will harm
none;  and to have sufficient (but no more) domination to ensure that no-one
else can dominate.

< I am a great believer in the old adage that those who ignore history are
doomed to repeat it, but I have snipped the historical political examples
here. >


But recognizing the dignity of people who are different from
you is a strategy that tends to win out in the long run.  It
is, in a word, gracious.  It is the modus operandi of an
open society.

That's a given in any truly civilised society - but they are *very* thin on
the ground, both amongst nations of the world, and amongst the internet
society.  To establish such high-minded principles is to set a very high
bar.


What does this have to do with Microsoft?  The SPF community
has shown strong support for the envelope sender.  And this
makes sense, because the envelope is the natural domain of
the MTA.  Microsoft has shown strong support for the PRA in
the headers.  And that makes sense, because headers are the
natural domain of the MUA.  Coincidentally, the opensource
world dominates the MTA market, and the commercial world,
notably Microsoft, dominates the MUA market.

Well - I am glad you are aware of the reasons for M$'s actions  -- they want
to change that coincidence.  They are self-confessed and proven predators,
with a divide and conquer policy which they openly promote.


But this is not relevant; the important question is what
position the SPF Community should take on the PRA and on
working with Microsoft.  I know that among the opensource
commuity, who have been burned many times, and, with the
patent application, continue to be burned, the natural
instinct is to say that cooperating with Microsoft in any
way is beyond the pale.

I *have* to pick you up on this one -

The "Pale" was the huge defensive fence/wall built around Dublin by the
English "conquerors" to stop the locals from trying to reclaim their own
land.  The expression "beyond the pale" is a reference made by a conqueror
to the "misguided" and "backward" locals whom they think they have
conquered, but obviously not well enough to not need a Pale.

So where does that put the Open Source community?  I suggest we are outside
and trying to reclaim what was and should be ours,  so we are already, by
definition "beyond the Pale" :-)


And the same community has said
that on a purely technical level the PRA is simply
unworkable, and will be exploited the day it comes out, and
that while sendership can be verified by IP-based channel
methods, authorship can only be verified with cryptography.

We must distinguish between these two positions.  One is to
say that you would rather speak English than French; the
other says that French people are bad.

The two "positions" are totally compatible - one is political (we don't want
to work with M$) and the other is technical (PRA won't work).



I believe in the importance of protecting mail-from.  In
August, I made a special trip to Redmond to try to convince
Microsoft to reserve a role for the return-path in Sender
ID.  I was pretty much shown the door.  It took the IETF to
make that point.

That's not really surprising - and it's what the IETF is for.



I also believe in being inclusive.  We now have the option
of submitting drafts to the IETF which do not give PRA any
role at all.  Or we can submit drafts which give the market
a choice of scopes, including mail-from, helo, PRA, and
possibly others.

Inclusive-ness must *not* harm anyone - either now or in the future. So
while we *could* include PRA, we must *not* hurt SPF.



I believe that a single syntax which can apply to multiple
identities is more gracious than a syntax which excludes one
of them by design.

Agreed.



| By doing this you give M$ the same advantage of "first-there" as SPF
| classic.
| You're either playing politics or you're in league with M$ - which is
it?

I am certainly not in league with MS: I have not taken any
money from them, and in fact I half expect them to sue me
just to shut me up.  I entertain no illusions that in the
event of a lawsuit the opensource community would come to my
rescue.  The SPF donation link typically sees a $2
contribution three times a week, and I don't expect a legal
defense fund would do any better.

Thank you for your honesty in this.


I am arguing for PRA support not because I think PRA is
technically right, but because giving Microsoft what it has
asked for is gracious.  And if Microsoft is going to take it
even if we don't give it to them, then it is not only
gracious; it is pragmatic.

I think there is a qualification needed here  - about the *level* of support
for PRA.



So, to answer the question, in part I am doing it because it
seems to be the right thing to do, and in part I am playing
politics.

Well - on both counts I think you are on extremely dangerous ground.

First - we are not here to "do the right thing" for anything other than Open
Source generally and SPF in particular.
Second - you are asking us to get into M$'s favourite arena and play hard
ball with them, and I believe that this is where you will fail.



The extremists in the SPF community who hate Microsoft can
do two things: they can deride the PRA, or they can actively
try to suppress it from the standards.  If they tried to
suppress it, I have no doubt that we would quickly see a
full-blown standards war.  Microsoft is committed to Sender
ID and already has more money and manpower dedicated to
implementing and evangelizing it than the entire SPF
community combined.  Going head to head is not a viable
strategy.  If we refused to allow PRA at all, I am sure
Microsoft would publish Sender ID as a standard anyway and
say goodbye to the IETF.

If you do not believe that PRA will work, you are free not
to use it, and you are free to convince people of its flaws.
Think for yourselves and let others enjoy the privilege to
do so too.  But attempts at censorship are rarely productive.

Absolutely - and I would suggest that to refuse to allow PRA would be
counter-productive, but I also suggest that the degree of inclusiveness is
critical.  Perhaps we should declare a policy of "non-denial" - ie. we allow
PRA (and any other technologies which may come in the future) to use spf1
(and later versions), but we do not bend over backwards to make it happen
for them.


If we bundle mail-from into Sender ID, and if Microsoft
backs Sender ID, then Microsoft won't want to kill
mail-from.

Don't be too sure. If they get Sender-ID to work, even badly, and can live
without mail-from: they will almost certainly try to kill it so that they
will get more market share.




I expect vendors to do "all of the above" anyway, so asking
them to exclude one technology isn't realistic.  That works
in Microsoft's favour, because that means PRA will have a
future; and it also works in the SPF community's favour,
because it ensures survival for mail-from.

Vendors will also do what is commercially expedient, which is sometimes
*not* what is technically best :-(


So, even if nobody here likes Microsoft and nobody here
likes PRA, those are the reasons I think we should specify
spf1 to include PRA, and we should specify spf2.0 to allow
explicit PRA scoping.

This is the *real* nub of the issue -

In what form exactly do you want to include PRA in spf1?  The most crucial
thing is that whatever inclusiveness is incorporated it must *not* be in
*any* way detrimental to the efficient working of spf1.



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.

Ermmm....   Can anyone point to a policy of appeasement that has succeeded?



| I am *very* grateful to Mark and Meng for their sterling work thus far,
but
| it is probably appropriate to move forward with a more formal working
group.
| I suggest that a larger body is formed with a slightly more formal
| "constitution" for the developement of SPF, so that the invitation to
| publish RFC's, the representation of the SPF community, and other
aspects of
| this work can be handled in a more democratic manner.

I think the lesson we can take from MARID is this: above a
certain level of organization, formal bodies are inherently
subject to denial of service attacks eg. filibusters.  These
kinds of attacks are moves in a game which operates at a
lower layer in the stack.  If we do not organize at such a
high level, we can counter those moves more directly.

Whilst I am no fan of beaurocracy, I would disagree totally here.  The
*only* thing that allows a slightly more formal body to suffer DoS by
filibustering, is weak chairmanship.


Slainte,

JohnP.
johnp(_at_)idimo(_dot_)com
ICQ 313355492