Julian Mehnle wrote:
No, it breaks only those policies where PRA != MAIL FROM cases are
"legit" as defined by the publisher of the policy. That's nowhere
near to "most", quite the contrary.
No, actually it would break _all_ the v=spf1 records whose owners
weren't or aren't aware that there is a PRA interpretation for
v=spf1.
I think we're in violent agreement. It would break for all policies
if a legit user happens to post on a say Sympa mailing-list (i.e. any
list not supporting the Resent / Sender magic required by SenderID),
and where the domain owner agrees that this is permitted.
Otherwise the domain owner is either in need of medical help, or
should arrange op=pra and/or copy v=spf1 to spf2.0/pra a.s.a.p.
Standards track RFCs don't "update" experimental ones, do they?
Not sure, obsoletes should be okay. Updates would be rare if it
results in a normative "downref" (tons of rules, with loopholes
for the loopholes like a "variance" procedure, and of course it's
also possible to fix the damned rules.)
My idea to get rid of PRA by explaining why it's mostly pointless
in an I-D is independent of 4408bis. It could be a IANA registry
of SPF version tags, seeded with the five existing tags.
I think any attempts to get "v=spf1" to "Standard" status are a
waste of time. What is there to be gained?
A proper standard, what I always wanted since day one when I saw
this messy list with its moving target v=spf1, one day adding odd
mechanisms, another day unifying itself with Caller-ID, wild and
wonderful scopes, modifiers, and more cruft.
What survived from all these discussions ? Tiny minorities of
users consider op=auth and op=pra as good idea. And tolerate
op=helo and op=nohelo for educational purposes, documenting two
"roads not followed" proving that nobody needs a helo-scope.
Our understanding of modifiers is certainly better than in 2004.
We'd know how to do say op=dkim if there ever is an SSP for DKIM.
Our understanding of the IETF standards process is also better.
And if you think that SPF is _necessary_ to save SMTP from the
forces of evil, then that's no "experiment".
What is there to be gained by turning
<http://www.openspf.org/SPF_vs_Sender_ID> into an I-D?
Ordinary admins will never find it, they've no clue what the
differences between PRA and v=spf1 really are. Gullible folks
might find the Wikipedia articles and believe it, and that's it.
Publishing I-Ds offering new insights (the appeal didn't discuss
the relationship of version tags) is another way to "promote SPF".
The appeals were for obvious reasons confrontational. The I-D
would be the next obvious step, assimilation: "PRA was a nice
idea unfortunately unrelated to reality, let's talk about SMTP."
<target-name>
Yes, not specifying it was a mistake (I think I said that a long
time ago). However, shit happens and we cannot change the v=spf1
specification to such an extent now.
That's nonsense. Fixing bugs and mistakes is always allowed, one
popular way to fix bugs is to document them as "features". While
it's almost hopelessly old, if you have more time again take a
look into RFC 2026. Or start with the TAO of IETF (RFC 4677), it
is more up to date, Paul (and Brian) did a very nice job with it,
it's where I started when Bruce started to torture USEFOR (2004).
Frank
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735