Scott Kitterman wrote:
I like NOT RECOMMENDED, but not at the expense of having an
RFC.
Actually this ought to be checked with MarkL and Ted Hardie.
My best guess is that it's the usual FUD of the Sender-ID
faction. Maybe plus a confession of Meng that he broke his
word given in an earlier Council meeting about this issue.
And a confirmation of William's analysis that there are only
three persons who were in the position to add this obscure
"RfC editor note" to draft -00: Meng, Wayne, and Ted.
I very much doubt that Ted did this alone on his own account.
And I'd bet that it wasn't Wayne. So that leaves Meng, maybe
it was before he gave his word in the SPF Council. Maybe not.
| 21:58 <freeside> it's not really necessary to say that
Hogwash. It's one of the reasons why MARID was closed, because
"they" didn't get away with stealing v=spf1 for their business
plans. It's the very reason why we elected the SPF Council.
It's also the reason why I wanted an RfC since the days when
Meng announced his "CYA strategy" twisting SPF into unified
rubbish. Apparently we now agree on this, it's time to freeze
the spec. as is. From my POV one year later than necessary,
but better late than never.
| if the SPF spec remains silent on that point, then it really
| increases the likelihood that we'll get an RFC out of it.
Really hogwash. It would never survive a "last call" without
this NOT RECOMMENDED clause, because I among some others would
kill it in public. This is strictly non-negotiable territory.
Now I have no idea if Meng's right or wrong
I have. Meng belongs to a small club of big players supporting
MS Sender-ID, and because this club has no base without v=spf1
they try to steal it. With all tricks, like the MARID stunts
or the "RfC editor note". It's devastating for the reputation
of these people, could you work with Jim in good faith ? Would
you join an IETF WG where Andy is the chair ? How do you feel
about the IETF in general ? This was a disaster, for Andy's
POV hear http://podcast.resource.org/rf-rfc/index.html#item0003
no matter what our RFC says, it isn't going to stop people
doing what they want with v=spf1 records.
That's Phil's line. Of course you can abuse SPF for whatever
you like, e.g. block all senders without sender policy.
If NOT RECOMMENDED will keep us from getting an RFC, should
we change it?
No. Ex falso quodlibet.
"If other identities are checked against SPF version 1
[...]
records, then that check MUST produce the same result as
checks described in this draft."
This MUST is stronger than the NOT RECOMMENDED. And as we
know for certain in the case of a PRA it's _impossible_ to
guarantee this. It's King Canute on the Seashore.
I can envision some caveats that MS could put in their
draft about when PRA should be checked that would meet
this requirement.
Here's what the expired draft-lyon-senderid-core-00 said:
| Sender ID implementations SHOULD interpret the version
| prefix "v=spf1" as equivalent to "spf2.0/mfrom,pra",
| provided no record starting with "spf2.0" exists.
Bye, Frank