On Sat, Oct 02, 2004 at 09:31:56AM +0200, jpinkerton wrote:
|
| Mark has said that he is a "shepherd" and that is a very comforting attitude
| from us sheep's point of view ;-) , and Meng is baffled by us needing
| permission to do things, which is probably because he doesn't realise just
| how much of a leader he is seen as by M$, IESG, the press, etc, etc.
My leadership seems to derive mainly from good service to
good ideas. So I will write down some of the ideas that are
now in my head. If people agree with those ideas, perhaps
they will also agree with the course of action which I
suggest.
| > publish Experimental RFCs for Sender ID to make Microsoft
| > happy,
|
| 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?
| Please don't read that question as abrasive, I agree with John Glube when he
| says that all individuals are free to act as they wish, but there are a
| *lot* of people on this list who want nothing to do with M$'s work.
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.
To my uneducated eye, there seems to be an important pattern
in both politics and systems architecture. I want to talk
about this pattern because it appears relevant to the
current question of "what to do about Microsoft and PRA".
The pattern identifies two principles: on the one hand, we
have inclusiveness; on the other, control and dominance.
This pattern shows up all over the place. Local politics
today, no matter where you live, can be read in those terms.
During the Cold War, when Ronald Reagan called the Soviet
Union an "Evil Empire" he saw democracy as liberal/inclusive
and communism as controlling/totalitarian. Going farther
back, three thousand years ago the Taoists had yin and yang.
If there is an arrow of human destiny, I would like to think
it points in the direction of inclusiveness. Take Canada,
with an English-speaking majority and a Francophone
minority. Throughout most of human history, forced
assimilation would have been the norm: the minority forced
to abandon their French roots and learn only English in
schools. Yet Canada is bilingual. All official
communications are expressed in both languages. In
English-speaking provinces, this is arguably wasteful. But
we recognize that bilingualism is more enlightened than
genocide.
Canadian bilingualism is an example Alexis de Tocqueville
would have admired. He distinguished between freedom and
equality, and that distinction is important. Canada could
have achieved equality: citizens could have been equally
free to speak English. Instead it chose freedom: citizens
are free to speak different languages with equal fluency.
The great irony to which we must be sensitive is this:
Suppose we have a minority ideology accustomed to the weaker
position. To resist oppression that ideology may clothe
itself in the strategies of inclusiveness; but once it gains
the upper hand, it may adopt the tools of control. When
that happens, the people who subscribed to that ideology
must ask themselves a hard question: do they care more about
the principles to which the ideology had been allied, or
about the ideology itself which may now operate in contempt
of the rules by which it won the previous round?
As computer scientists trained in recursion we should be
particularly sensitive to these kinds of ironies. For
example, at the federal level, in Canada, communications are
bilingual to protect the French-speaking minority. But in
recent years the government of Quebec has tried to make
French the only official language in the province, at the
expense of the English-speaking minority.
Another example: American campuses in the 1990s. For
decades the First Amendment had been used as a tool by
minority, "oppressed" ideologies such as feminism; then,
when in the 90s those ideologies gained the upper hand,
extremists within those camps immediately switched
techniques: to strengthen their position they worked to
censor ideas which they found politically incorrect.
It is hard to resist this kind of switch; it is easy fruit.
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.
It is most gracious when those who have already won the game
are prepared to change the rules, even if they suffer as a
result. In the legend of King Arthur, a monarch by divine
right and absolute ruler chooses the rule of law for the
good of his court --- and by that rule must execute his
wife. Gorbachev, General Secretary of the Communist Party
at the height of his powers, introduces glasnost and ends
the Cold War, at the cost of house arrest and the loss of
his presidency.
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.
So we observe a natural connection between SPF Classic, the
return-path, opensource, and MTAs. We observe an equally
natural connection between Sender ID, the PRA, Microsoft,
and MUAs. Of course there are exceptions: plenty of
commercial MTAs and opensource MUAs exist, and where do you
put SpamAssassin? But it is telling that the MTA vendors
have generally added support for SPF first and Sender ID
second if at all --- and that is simply because of the
natural connections.
It is an interesting question for fans of alternate
histories to ask whether, in a parallel universe where MUAs
were overwhelmingly opensource and MTAs were overwhelmingly
commercial, Microsoft would have been a proponent of SPF.
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. 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.
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.
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.
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.
| 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.
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.
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.
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.
Part of the fallout from that standards war would be delayed
adoption of SPF (both Classic and Unified) in the market,
and possibly a reversal of their decision that SPF Classic
is not covered by their patent. None of these things would
be in the public interest.
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.
Originally SPF Classic was about the mail-from, and used
HELO as a fallback only when the return path was null.
In January, Hector Santos argued to elevate the HELO scope
to first-class status. Since January receivers have been
free to interpret an SPF record in HELO and MAIL-FROM scopes
equally, and publishers have been admonished to ensure
compatibility with both scopes.
When Harry Katz, Jim Lyon, and Bob Atkinson discussed Sender
ID in May, we agreed that v=spf1 records could also be
interpreted in PRA context without risk. Margaret Olson and
others in the IETF later objected that different scopes
required disambiguation. This objection led to the creation
of the sp2.0 prefix.
To satisfy all of the above views, I would like to pursue
the following approach with Sender ID:
v=spf1 originally applied to mail-from.
v=spf1 now applies to helo as well.
v=spf1 will in future apply to PRA also.
Senders whose PRA and mail-from configurations are
identical need only publish v=spf1. This describes the
vast majority of senders, particularly those with control
over the Sender header.
Senders whose PRA and mail-from configurations are
different can override using an spf2.0 record.
Receivers who interpret PRA scope MUST read spf2.0
records.
Receivers who do not see an spf2.0/pra scope MAY
substitute with a v=spf1 record.
Senders who do not believe that PRA is useful at all can
ignore spf2.0. If their mail is rejected because their
v=spf1 record is interpreted according to PRA rules, they
should set up an spf2.0/pra record containing only ?all.
The above is pragmatic because it allows spf1 records to be
used by the Sender ID / Microsoft / PRA camp; it also allows
spf1 records to be used by SPF Classic; and it removes the
need to fight a battle over whose is bigger. I mean,
better. Avoiding a standards war is in everybody's
interest. Getting Microsoft to tell people to publish
v=spf1 records would also have been in our interest.
Unfortunately, the purists won that round, and I expect
Microsoft to spend considerable resources telling people to
publish spf2.0/pra records only. However, if the
specifications leave room for other scopes, I hope and
expect that third-party advisories will present a more
balanced view.
If we bundle mail-from into Sender ID, and if Microsoft
backs Sender ID, then Microsoft won't want to kill
mail-from.
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.
Folks who think that Microsoft should abandon PRA entirely
are welcome to take that up with them directly. Asking them
to abandon PRA is like asking them to not sell a billion
dollars of the next release of Outlook.
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.
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 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.