Re: Enough RE: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]