[apps-discuss] Proposed "spfbis" working group charter

[Murray S. Kucherawy]

If you have feedback about the charter, please submit it to me directly or to the apps-***@ietf.org mailing list.

-MSK



-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/6959934-50ec8f89
Modify Your Subscription: https://www.listbox.com/member/?member_id=6959934&id_secret=6959934-b7c4528d
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=6959934&id_secret=6959934-edadf31a&post_id=20111114004812:3BA5F1C6-0E84-11E1-992F-C1E34E3FB31B
Powered by Listbox: http://www.listbox.com

[Frank Ellermann]

that document proposes an extension to SPF called "scope", but
doesn't contain any scope definition for the proposed working
group.

IMHO one of the results of "the experiment" was that nobody needs
any SPF "scopes" or "options" in addition to its baroque features.

E.g., the fine print of a "pra scope" in spf2.0/pra vs. a different
"mfrom scope" in spf2.0/mfrom, which is in essence the same as
RFC 4408 v=spf1 excluding a hypothetical "helo scope" spf2.0/helo,
is just too confusing and not helpful for all involved parties.

I'd be willing to revive the "SPF options" draft with some caveats
wrt new modifiers, but actually I'd prefer to stay away from any
spf2.0/scope constructs. I'm not aware of new "scope" discussions
on SPF discuss for some years.

-Frank

[Murray S. Kucherawy]

-----Original Message-----
Sent: Sunday, November 13, 2011 11:36 PM
To: Murray S. Kucherawy
Cc: SPF discuss; Martin Duerst; Barry Leiba
Subject: Re: [apps-discuss] Proposed "spfbis" working group charter
IMHO one of the results of "the experiment" was that nobody needs any
SPF "scopes" or "options" in addition to its baroque features.
E.g., the fine print of a "pra scope" in spf2.0/pra vs. a different
"mfrom scope" in spf2.0/mfrom, which is in essence the same as RFC 4408
v=spf1 excluding a hypothetical "helo scope" spf2.0/helo, is just too
confusing and not helpful for all involved parties.

I believe (Scott or Julian can confirm or correct me) that this comes from the fact that there's a definite community that wants to be able to do SPF based on the RFC5322.From domain, but not drag in the whole PRA algorithm. That's what's going on here.

I'd be willing to revive the "SPF options" draft with some caveats wrt
new modifiers, but actually I'd prefer to stay away from any
spf2.0/scope constructs. I'm not aware of new "scope" discussions on
SPF discuss for some years.

I think adding the SPF options stuff in the initial charter is a non-starter. We're trying to keep this as tight as possible. But keep it in the wings when it comes time to re-charter.

-MSK

[Frank Ellermann]

On 14 November 2011 08:46, Murray S. Kucherawy wrote:

[spf2.0/author, apparently]

Post by Murray S. Kucherawy
I believe (Scott or Julian can confirm or correct me) that this comes from
the fact that there's a definite community that wants to be able to do SPF
based on the RFC5322.From domain, but not drag in the whole PRA algorithm.
 That's what's going on here.

That is a seriously dead draft written by Wayne Schlitt many many years ago:
draft-schlitt-marid-spf-from-hdr-00 (2005)

Inventing something "better than PRA" is doomed, PRA is as good as possible,
and as we know not good enough. We had similar troubles in the DKIM WG with
attempts to do "something interesting" with the From header... Until folks
started to grok the Resent-From: details, or the required Sender: if there
is more than one From: author.

This is a hopeless case, the only clean solution would be a "PRA", and nobody
wants the "PRA", notably 5322 and 4409bis do not really support the concept.

-Frank