spf-discuss
[Top] [All Lists]

RE: Re: When did we lose control?

2004-10-22 14:57:15
From: Hallam-Baker, Phillip
Sent: Friday, October 22, 2004 2:22 PM



* Amend the protocol for v=spf1 with a modifier, as
requested by Rand, so that those who wish to state their
record can't be used for pra checking can do so; and,

In what alternative universe do you think that can be
enforced and under what theory of law?

Not this one.  But please, the hyperbole won't get your ideas heard.



If you send me mail I will decide how I analyze it, not you.
The premise here is that the sender might be a spammer and
spammers don't get to choose.

Your MTA, your rules.  That goes without saying and nothing will ever change
that.  A sensible recipient is also interested in what the sender's policy
is.  Why?  Because not all senders are spammers and some of the sender
policies are strict enough to meet your local policy requirements.  Since
sender authentication at this point in time does not consist of a single
technique, senders employ a variety of mechanisms, some of which give a
higher degree of authentication than others.  The recipient can look at the
sender policy and see if it is strict enough to meet their guidelines and if
the validation mechanism is acceptable to them.  If it is, it would make no
sense to use a validation mechanism incompatible with the authentication
scheme used by the sender.  An example is insisting that the incoming mail
pass a DK signature validation, even if it was S/MIME signed.  You can do
that, but it's a poor implementation choice.  While no one can force a
recipient to do anything, there is every reason to believe that they will
act in their own self-interest and look at reasonable sender policies.

If you want to apply every SPF record to the PRA scope, even though the
domain owners did not intend for them to be evaluated that way and it will
cause you to reject a fair amount of legitimate mail, that is your choice.
This makes me wonder what your actual goal is here.  Is it to use PRA at any
cost, despite its rejection by the larger technical community, or to
properly authenticate various identities for incoming mail?




PRA is already implemented and active.

It's a tiny fraction of the deployed SPF base.  Let's get real.  It is also
technically broken, IP encumbered and has virtually no support outside of
Microsoft.  To borrow a phrase from the MASS group, it's a non-starter.  I'm
sorry, but we can't make a silk purse out of a sow's ear.  If you and MS
would like to cooperate with us to come up with a technically reasonable
solution who's patent license does not preclude open source implementations,
you just might get a lot of help with this work.  We have worked in good
faith from the get-go.  The record is very clear on that.  Despite a lot of
recent anti-MS rants, if MS decided to act in good faith by dropping
requirements that everyone knows are unacceptable to the wider community,
they would still get cooperation.  The ball's in their court.


Nothing this or any other group can do will change that.

That is correct.  We cannot fix their broken algorithm, although we tried
our best to help.  We cannot fix their intentionally poisoned patent
license, though we tried to advise them of the likely effects of that.  They
were well-aware their terms were totally unacceptable to the open-source
community, which is likely why they insisted on them.  That tactic is widely
recognized as bad faith negotiating.  Offer something you know is
unacceptable and blame the other party for being uncooperative.  Add to that
a throw-away requirement that you know is unacceptable (XML) and drop at the
last moment to make it look like you are making concessions.  Ho-hum.

In contrast, we've operated in good faith and offered cooperation from day
one.  We spent lots of time debating the XML issue, even though it didn't
have the technical merit to warrant serious consideration.  We tried to
first find out what PRA was, and then having seen it, tried to help them
make it reasonable, all to no avail.  We told them early on that IP
encumbrances would be a major issue and that the open source community would
have to buy in to any ultimate solution.  The written record clearly shows
all of this.

As soon as MS decides to operate in good faith, good things can happen.
Until then, all we can do is continue with our work and hope that they
realize that working in good faith is in everyone's best interest.  Anyone
who looks at the record can't escape the clear appearance that Microsoft
never wanted a successful collaboration in the first place, though this is
evident only in retrospect.  We certainly wanted a successful collaboration
and acted accordingly.  After things broke down, there was a lot of anti-MS
sentiment on the list, but that is hardly surprising.  That's what happens
when you negotiate in bad faith, lead someone down the garden path and then
pull the rug out from under them at the last minute.

If MS wants to use that as evidence of lack of cooperation and
anti-corporate bias, I'm sorry to say that's just a continuation of their
bad faith approach.  Anyone with a reasonable amount of intelligence who
looks at the record will see what actually happened.  This is not
MS-bashing, it's simple statement of what occurred, fully documented in the
written record.  For the record, I would have much preferred to see a
reasonable compromise than the current situation.  I think I can take the
liberty of saying that represents the views of most of the people in the SPF
community, even though many people are now understandably very angry about
Microsoft's conduct and speak forcefully to that issue.



What you are trying to do here is to push a position that
means that I can only analyze MY incomming mail with
software that meets your choosen ideology. Tough, not
happening. Why waste bits arguing the point?

Rubbish, and you know it.  Nobody is telling you what to do and I'm shocked
that you mention ideology in this context.  SPF is an imperfect technical
solution to a difficult problem who's compromises were worked out through
thousands of hours of discussion among experts.  PRA is a proposal put
together by perhaps half a dozen people in isolation with no significant
public review and the result is not surprising.  Given the enormous amount
of technical scrutiny SPF has received compared to PRA, only someone with a
particular corporate agenda would support PRA.  It's quite incorrect of you
to assume that the SPF group has an ideology, and quite telling.

--

Seth Goodman