On Sat, 2004-10-02 at 18:19, Meng Weng Wong wrote:
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?
This is all an excellent point, Meng. But exactly which party is
holding the "minority ideology and is accustomed to the weaker
position"? The SPF community is many, Microsoft is one. The SPF
community may be accustomed to the weaker position, but from what I've
been reading on this list and mxcomp, SPF is not the minority ideology.
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.
I agree that it is morally superior to always "take the high road",
though it may not always be rational. Unfortunately, your example ends
up being like an Iterative Prisoners' Dilemma/Tit for Tat. Let's take
the high road and recognize the other party's dignity. Except the SPF
community already did that during the first round. How many more rounds
does the SPF community have to suffer through before the strategy is
changed? I becomes difficult to even know what to change your strategy
to (and working WITH Microsoft is a change some people are having
trouble making) when the other side is going to do what ever they want
anyway, no matter how you try to engineer the situation so that you
think you can predict what will happen.
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.
So this why Microsoft is viewed as gracious!
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 see no reason why multiple drafts can not be submitted and each can be
viewed on their own merits. Each party is welcome to work to their own
ends. I don't think anyone is suggesting that a SenderID draft not be
submitted or that it can not be based on SPF. In fact, for those who
have not already decided that PRA is busted, it seems the feeling is
"bring it on!". If it will help SenderID adoption to ride on the
coat-tails of SPF drafts (by specifying record-reuse and alternative
modifiers, and new version strings), so be it. But that doesn't mean
that SPF needs to recognize alternative uses for its data. Recognizing
alternative uses for SPF are, rightly, the job of the alternative uses,
the things to come after SPF that will learn from 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.
I agree. While SPF doesn't need to recognize alternative uses, it does
help that it allows for that kind of expansion, through both modifiers
and the version string. I don't think anyone would think that these
were not well thought out, worthy additions.
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.
"I am telling this child to run with scissors not because I think
running with scissors is right, but because running with scissors is
what the child wants to do". My intention is not to suggest that
Microsoft is a child, but rather that sometimes being pragmatic means
doing what is correct (my understanding is that the jury is still out on
the actual effectiveness of PRA in the MUA), not what is wanted. It is
important to have the techies provide options to the market because it
is important to let the market decide, no debate there. But does this
mean that the techies should include an option they feel/know is wrong
(I suppose this could be used to see if the market is paying attention)
for the sole purpose of giving the market a choice? That's a lot of
risk for the techies to take on.
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.
This last paragraph is not compatible with the one first. How is one
supposed to convince people of the uselessness of PRA with the amount of
manpower and money Microsoft has already and will dedicate to SenderID?
In addition, why is trying to convince people of this later better than
trying to convince them of this now (which one could say is what people
who don't like PRA are doing)? I don't really see how suggesting that
PRA _not be included_ in SPF and that SPF remain true to its original
form is different than "deride the PRA". Suggesting that SPF not
include mention of PRA is completely different from suggesting that SPF
_explictly_ not allow PRA. Personally, I'm for the former, I'm not for
the latter.
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.
This is something for a SenderID specific document to describe, not an
SPF document. If SPF says "document your policy like so and interpret
records like so for Envelope", and SenderID says "use SPF records and
interpret like so for PRA", then everyone wins. SPF could include
arguments as to why not using the SPF record for other purposes is a
good idea, and it is then the SenderID document's job to refute those
and provide compelling reasons to use the record for alternative
purposes.
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.
This is something SenderID should specify, not SPF.
If we bundle mail-from into Sender ID, and if Microsoft
backs Sender ID, then Microsoft won't want to kill
mail-from.
One could argue, using the patent contents, that Microsoft is already
attempting 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.
Sure, if the newer MUA supports PRA, then everyone will have to
upgrade. But can't Microsoft encourage everyone to upgrade without
there being actual reason to? This falls in the domain of marketing,
not technology. Is the Microsoft marketing department suddenly having
trouble getting to sleep at night?
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.
To reiterate my above point, I think it's better to not explicitly
disallow it than to explicitly allow it.
Andy Bakun
abakun(_at_)thwartedefforts(_dot_)org
spf(_at_)leave-it-to-grace(_dot_)com