Julian Mehnle wrote:
I also noted that I didn't believe that MS actually was in a
position to dictate Sender-ID and the patent-encumbered PRA
onto the e-mail world.
With a senderid-core RfC to point to and some handwaving about
"forget version 1, that's old", where's the problem ? These
are the last days of SPF unless somebody appeals the decision
to publish incompatible experimental RfCs.
To that, some didn't agree, in particular Doug and Meng.
I also disagree, maybe for different reasons.
perhaps the MAAWG could play an arbitrating role in achieving
an amicable agreement between the SPF project and MS to
commonly agree on and promote a new, post-v=spf1 record
format that would be feature-compatible to both SPF and S-ID.
They don't want a "feature-compatible" record format, they have
it already, spf2.0/pra is PRA, spf2.0/mfrom is MFROM, and
spf2.0/pra.mfrom (or spf2.0/mfrom,pra) is PRA plus MFROM.
They really want to steal the installed v=spf1 based for PRA,
that's not some obscure misunderstanding. They also don't want
an op=pra for the very same reasons.
In theory it's possible to define spf2.0/mfrom as _identical_
to v=spf1 (i.e. add the HELO-identity), and then it's 100%
"feature compatible" adding only positional modifiers. It's
also possible to do this with a new spf2.0/mfrom,helo. They
don't want this. They want v=spf1, no workarounds.
They have the approved RfC, no reasons for an "arbitration by
the MAAWG", that's just another delaying game to get over the
period for appeals.
I could very well see this as a possible solution, even if
that format would support the PRA -- as long as MS stopped to
re-use v=spf1 for non-RFC2821 identities.
I *really* don't believe it. This is a delaying game. Did you
ever read Andy's "spf-considerations", do you know who worked
together to shut down MARID, do you have an idea who promoted
to study PRA aka 2822 before 2821 aka CSV trying to get rid of
v=spf1 ? Why do you think that Mr. Hardie tried to delete the
critical NOT RECOMMENDED in v=spf1 not touching the opposite
SHOULD in SID ?
They know exactly that an appeal is the last chance for v=spf1.
And if that doesn't come or doesn't work they win.
I offered to incite discussion about this within the project.
See above. You (Council) could decide to submit the "op=pra"
draft as an I-D, but where's the point if they don't change the
incompatible SHOULD in lyon-senderid-core-01 ?
we hacked for a few hours and found a number of vaguenesses
and ambiguities in the draft-schlitt-spf-classic-02
specification, most notably the IPv4/IPv6 address handling
(I'm going to expand on that, too, later).
That sounds very interesting. I dare say that you were tired
and that the spec. is fine wrt IPv4/IPv6 address handling. ;-)
I think that with the help of some of the MAAWG members
and/or Andy Newton, a resolution for the SPF/S-ID problem
can actually be found with MS, if we want to engange in that
direction.
Guess: They'll be affirmative, but just don't meet any dead
line until - oops - the appeal period is over, and that will
be the moment when they lose any interest. Compare the MARID
history, co-chair Andy Newton with AD Mr. Hardie. BTW, did
you meet the famous M. Olson of the "Olson objection" ?
Thanks for the report, bye, Frank