Meng Weng Wong in
<20041002231943(_dot_)GB1135(_at_)dumbo(_dot_)pobox(_dot_)com>:
My leadership seems to derive mainly from good service to
good ideas.
Thanks for sharing your thoughts.
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.
It makes sense because it confers practical benefits and is
simple to implement, no other reasons.
Microsoft has shown strong support for the PRA in
the headers. And that makes sense, because headers are the
natural domain of the MUA.
The headers in m$ mua (and mta) are a shambles; I don't
anticipate the introduction of pra improving matters.
But this is not relevant; the important question is what
position the SPF Community should take on the PRA
Fwiw, it's worthless, imo.
and on working with Microsoft.
If you've achieved nothing else, you've succeeded magnificently
in demonstrating the problems of trying to work with m$.
I entertain no illusions that in the
event of a lawsuit the opensource community would come to my
rescue.
Oh, come on. Let's not pretend that you can't get fleas from
lying down with dogs - we've heard them barking from day one.
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.
Isn't it more gracious still to permit them to have full control
over the destiny of their own ideas? From what I can tell,
reading between the lines, you've been trying to put them right
since day one and they won't listen. Why not bow out graciously
and let them get on with it?
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.
I don't hate m$, I just think they write shitty client/server
software which disadvantages the entire Internet community. If m$
want to work actively with the ietf, I'd encourage them in that.
Personally, I don't think their ideas, or their patents, display
much clue but they should have the opportunity to convince the
Internet community of their worth. I wouldn't dream of disrupting
that process - nor should you, imo.
Microsoft is committed to Sender ID
The terms of their patent suggest otherwise. They've chosen a
path which makes it impossible for many to implement.
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.
Still does.
v=spf1 now applies to helo as well.
Not here it doesn't.
v=spf1 will in future apply to PRA also.
That's for m$ to decide, isn't it?
I think you're irrationally concerned about m$. What have they
introduced into the Internet mail system which has been widely
accepted and adopted? For all their supposed might, they still
haven't managed to develop a client which can post text/plain
messages properly. They're a joke, not a threat.
Senders whose PRA and mail-from configurations are
identical need only publish v=spf1.
Pra is included in m$ patent licence, yes?
If so, I don't have an m$ patent licence and I don't intend to
apply for one. Without it, I can't calculate pra legally so I
won't know whether it matches my reverse path.
Senders whose PRA and mail-from configurations are
different can override using an spf2.0 record.
Publishing spf2.0 records serves no valid purpose for me.
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.
Doesn't bother me. Anyone who doesn't want my mail is welcome to
refuse it on any grounds of their choosing.
The above is pragmatic because it allows spf1 records to be
used by the Sender ID / Microsoft / PRA camp;
I'm not much bothered by that either. If m$ stay true to past
form, their spfv1 interpreter will be fatally flawed in any
number of respects and they won't ever fix it. We might well be
better off if they don't include spfv1 in sender-id.
and it removes the need to fight a battle over whose is bigger.
I mean, better.
What battle? The ietf introduces competing specifications all the
time. Why not let the implementors decide?
I expect vendors to do "all of the above" anyway, so asking
them to exclude one technology isn't realistic.
The m$ patent licence excludes itself for many.
Folks who think that Microsoft should abandon PRA entirely
are welcome to take that up with them directly.
I think m$ pra will be a resounding flop. Rather than abandon it,
I'd prefer them to stake their entire future on it.
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.
Relax a little and look at the bright side. When m$ publish the
names of organisations who have been granted patent licences,
we'll have a handy list of companies to avoid at all costs. Most
of them will probably be mainsleaze anyway.
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.
I think the lesson is a lot more mundane than that, don't expect
large corporates to operate with the same morality as normal
human beings.
From my perspective, way out on the sidelines, you were largely
responsible for the original impetus of spf but, once you started
playing cowboys and indians with m$ and ietf, you've also been
largely responsible for its subsequent loss of impetus. That's
not intended to be criticism, you were simply doing what you
thought was in everyone's best interests.
I think it's time that you recognised the futility of lying in
front of tanks in foreign countries. Stay at home, you're
appreciated here and we need you.
--