Hallam-Baker, Phillip wrote:
I note that the W3C policy is distributed under a creative
commons license. I suggest that future WGs adopt it as is
when they make their charter proposals. Otherwise they are
likely to find themselves in the same position that MARID
did.
FWIW, I looked into the W3C policy once, and "think" it's fine.
IANAL, but hope that the IPR WG uses CC among others as input.
Most SPF and PRA issues are and were _technical_ from my POV.
Your chances to find any statement from me saying something
else are slim: The idea to "patent" PRA is just bogus.
Given all (2)822 header fields as they are, ignoring the trace
header fields, the PRA algorithm is the only possible way to
divine a "purported responsible address" from this zoo. It's
not new, it's "read and understand RFC 822 as published 1982".
After that's clear removing most "legal" problems with PRA the
rest is purely technical:
1: For PRA to work 2476bis 8.1 "MAY add Sender" isn't good
enough, PRA requires at least a SHOULD. That's known, it
was dicussed in MARID about 16 months ago.
2: William's appeal demonstrated that senderid-core violates
a MUST in 2822. IIRC also not new and discussed in MARID.
As far as I'm concered it's okay to remove this MUST in a
2822bis. I have no problem with new uses for the Resent-*
header fields. In fact I never saw one Resent-* in about a
decade. MIME is much better for the original purposes of
Resent-*. If PRA offers new purposes for Resent-*, fine,
let them get it right (= fix 2822 + 2476bis).
3: William's appeal helped me to find a blatant hole in this
"hack", 2476bis 8.1 does not discuss Resent-* at all. It's
incomplete. I checked it again and again for op=pra and
op=auth, but I missed this d****d hole in 8.1 until it was
far too late for the submit-bis draft.
4. While you and others claim that SPF vs. PRA is only some
irrelevant legal battle about patents this is obviously not
the case: SPF (v=spf1 and spf2.0/mfrom) is pure SMTP, a
receiver can do this after DATA / BDAT / BURL / what else,
but he can also check it before without even looking into
the mail data.
5: PRA offers an accelerator for its check - worldwide upgrade
to SUBMIT, any volunteers - but in essence it's based on
2822 header fields. Unlike DKIM it doesn't invent a new
header field for its purposes, but uses the PRA algorithm.
6: These are independent and completely different aproaches:
There's no rule that PRA and Return-Path match, it doesn't
pass a giggle test. Nevertheless the PRA-spec. claims that
sender policies designed for the Return-Path are generally
identical with sender policies designed for PRA. Including
the more than 500,000 v=spf1 policies published long before
the mere acronym PRA was "invented".
Including all v=spf1 policies published before an obviously
bogus chapter 3.4 in senderid-core-00 claimed that PRA and
Return-Path are generally identical. This is just wrong and
makes no technical sense at all. Ask any experts what they
think about "assume PRA == Return-Path worldwide", and you
get a RIDIKULUS.
7: Disrupting v=spf1 at this point also spells doom for SMTP.
What we'll now get is SMPT-3, a new SMTP without most NDNs.
Only a few pockets of resistance with an SPF sender policy
will still say that NDNs are good IFF you reject SPF FAILs.
Bye, Frank
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf