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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 19 Dec 2005 12:54:24 -0800

> From: Keith Moore [mailto:[email-masked]] 

> However that doesn't mean that IETF should necessarily 
> endorse, or even
> document, any of these technologies.    Sometimes it's a disservice to
> the community to document a bad idea.

The protaganists in this matter have already conceeded the technical
issue. It was only when an issue was found with the IPR license on offer
that an objection arose.

I do not think that it is sensible for the IETF to lend credibility to
the idea of a GPL bit that ensures that the bits on the wire are only
processed be software that is in strict compliance with a particular
interpretation of the GPL.

Open software is a good idea, it is a good idea to require that
standards be implimentable using open technologies. It is not a good
idea to allow standards to be used to attempt to prohibit use of
technology because the licensing terms do not meet criteria which the
IETF is unwilling to define or to enforce as a universal standard.

I think it would be a good idea for the IETF to either pick an IPR
standard or to require WGs to specify what their IPR standard will be
when they begin a WG. I would be quite happy for the IETF to adopt the
same IPR policy as W3C and require all standards to meet that standard
of being open and unencumbered.

What is not a good idea is to attempt to achieve consensus on this issue
after the WG charter has been agreed.

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.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Mon, 19 Dec 2005 16:07:07 -0500

> issue. It was only when an issue was found with the IPR license on offer

That doesn't mean that there weren't other objections, only that some
people found the whole MARID exercise pointless and chose to spend
their energies in ways that they found more productive.  IPR concerns
or no IPR concerns, MARID would never have gained community
consensus.   Like an opportunistic infection that deals the final blow
to a terminally ill patient, IPR issues were not the cause of MARID's
demise, but merely a symptom.

Keith

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 19 Dec 2005 23:28:39 +0100

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

---

From: Douglas Otis <[email-masked]>
Date: Mon, 19 Dec 2005 18:14:31 -0800

On Dec 19, 2005, at 2:28 PM, Frank Ellermann wrote:

> 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.

Perhaps not.

Return-paths with a unique tag could mitigate a too common DSN  
exploit used to evade source filtering.  Ensuring an auto-response  
adopts consistent conventions where return-paths use either "MAILER- 
DAEMON@*" or "<>" addresses, and where return-path tag removal  
happens at the MDA when delivered (or published into on-line  
archives) would improve upon the success of this strategy.  Part of  
this tag may carry tracking information that could be used to locate  
sources of replay abuse.  (DKIM will suffer similar problems.)

Rather than hoping for critical mass or strategies to coerce adoption  
by a substantial portion of email domain owners, the domain  
implementing the return-path tagging reaps benefits immediately,  
allowing incremental adoption.  Tagging does not demand an inordinate  
overhead be imposed upon the recipient which could deter valid DSNs.   
Even checking the "authorization" address lists will often be found  
open-ended.  Authorization may also unfairly shift the burdens  
created by open-ended gaps onto the email address domain owner,  
rather than the actual sender.

With respect to offering more discriminate source identification,  
ensuring EHLO verification by a single DNS lookup could resolve much  
of the collateral issues associated with the use of the remote IP  
address as the source identifier.  A lightweight name-based  
reputation check may also leverage the granularity offered by DKIM.

(Who knows, perhaps the same public-key used to sign the message  
could also sign a portion of the domain name and the /29 of the IP  
address.  Only a single lookup would then be needed for both.) : )

-Doug

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Dec 2005 14:25:41 +0100

...
> after the WG charter has been agreed.

An even worse idea is to start a WG with a restricted IPR regime such
that relevant patent owners decline to contribute and thereby escape
the obligation to disclose their patents, IMHO. This is the very real
danger that the IETF method avoids.

     Brian

---

From: Keith Moore <[email-masked]>
Date: Tue, 20 Dec 2005 12:39:01 -0500

> not new, it's "read and understand RFC 822 as published 1982".

actually, no.  It's a perversion of RFC 822 which contradicts both the 
intent and the way it has been used in practice.  PRA is a failure not 
because it's patented but because it has irrepairable technical flaws.

Keith

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 21 Dec 2005 01:52:28 +0100

Keith Moore wrote:
 
> It's a perversion of RFC 822 which contradicts both the
> intent and the way it has been used in practice.

It's probably clear that I hate PRA, because it's a kind of
FUSSP (worldwide "add Resent-Sender" at places where that
was never before required), because it claims erroneously
to be normally (default) "compatible" with Return-Paths
covered by a v=spf1 policy, and because it does not even
_reference_ 2476bis, let alone discusss 2476bis 8.1 details.

But I don't see where it's a "perversion of 822", IIRC the
author was present when it was evaluated in a MARID chat -
more than a year that I read the jabber log, I'm not sure.

If I get a mail Resent-From: C, Sender: B, From: A+B, then
822 tells me that A+B were the authors, B was the sender,
somehow C got it and resent it to me.

And if I then want to ask "why did you send this to me?",
I'd send that question to C.  I don't need any "license" or
draft-lyon-senderid-pra for that task, but C is the "PRA",
the address claiming to be the sender.

So far no problem in _that_ draft.  It could be a PS, if
they'd add some considerations for say mailing-lists.  But
they say that mailing-lists and other redistributors MUST
also use that Resent-scheme in draft-lyon-senderid-core,
that's the point where senderid degenerates into a FUSSP.

But the "algorithm" itself to find an address of the last
entity claiming to be the sender of a mail (excluding all
"mediators" like mailing-lists on behalf of the receiver)
is sound.  The recommendation that MUAs should display
that address is IMHO also okay (and maybe stuff for a PS).

Otherwise this PRA "algorithm" is only "informational",
it could as well be published as one of many answers in a
mail header FAQ.  Nothing in draft-lyon-senderid-pra is
"experimental".  It just reflects what (2)822 say about
Resent-From, Resent-Sender, Sender, and From.

So yes, the authors read and understood (2)822, and while
they were at it they published a summary of their findings
as draft-lyon-senderid-pra.
                             Bye, Frank