On 03/10/2006 22:07, Julian Mehnle wrote:
Hi all.
First, why 2.1 and not 3? I think jumping entirely past version 2 makes
sense.
There has recently been some debate on whether a new version of SPF is
useful or even just realistic. Some have considered it unlikely that
another version of SPF could gain enough momentum to take off. Some have
proposed that some sort of extension mechanism to the existing SPFv1 be
created so that the installed base wouldn't have to be upgraded.
That would be me. Not a problem. It's still worth trying to do. We'll have
to present an updated RFC when our "experiment" is over anyway.
Personally, I think that the development and deployment of SPFv1 has been a
highly fruitful learning experience and that SPFv1 is still serving as a
useful -- if quite basic -- real-world anti-forgery solution. However I am
also convinced that in the long run SPFv1 has too many warts,
deficiencies, and outright blind spots to fulfill the destiny it has set
out to fulfill, i.e. to enable domain owners to publicly specify their
mail sending policies for receiver-side verification.
Time will tell. For a sufficiently large definition of long, I agree. What I
suggest we do is figure out what we want to do for the next version and then
as we go along, naysayers like me can work on figuring out what of the new
stuff can legitimately be backfit into v=spf1 with modifiers. No need to let
that slow you down.
For one, SPFv1 only supports IP-based authen... uhh... authorization of the
envelope identites (HELO and MAIL FROM), but no other author... uhh...
authentication methods that, on a technical level, either have already
been established (PRA checking, PGP, S/MIME) or are in the process of
being established (most notably DKIM) and are likely to be deployed in the
future. SPF needs to support those or it will sooner or later vanish into
oblivion.
I'd say provide a linkage to those rather than support those (excepting PRA -
I think it's own limitations and DKIM doom it into oblivion). I would also
throw in SES and BATV and CSV for that matter.
Also, while I don't believe that such features can be bolted onto SPFv1 as
some sort of compatible extension, I do think that a new version of SPF
could provide better support for future extensions. And last but not
least, a new version of SPF (numbered >2.0) could provide a graceful way
out of the v=spf1/PRA ambiguity which undeniably exists.
Yes.
Believe me, I do fully appreciate the difficulties of getting a new version
of SPF adopted. But I also appreciate the many benefits a new version
could provide without losing the focus on "sender policies". So let's not
dismiss the idea just yet but discuss the possibilities first.
Good luck. You go left. I'll go right. We'll meet up on the far side.
Here is a sketch of my idea of SPFv2.1 (probably incomplete):
* Refocus the problem/solution model:
"Sender Policy Framework" -- not just IP-address authorization!
YES.
* in: scope, identity (domain), subject (sending IP address,
signature key ID, etc.; provided by callbacks/hooks)
out: result, flags/options
* dkim/pgp/smime/sig:<method> mechanisms[1]
* Internal (ip4, a, mx) vs. external (dkim etc.) evaluation?
Or generic hook architecture?
* "Unknown" vs. "unsupported" mechanisms, e.g. dkim might be defined
and known, but not locally supported (i.e. unevaluatable)
DNS-based registry of valid mechanisms/modifiers?
I think this will probably have to be an IANA kind of issue if we stay within
the IETF structure to manage this.
Ignore unknown/unsupported mechanisms?
"!" qualifier (throw PermError on unknown/unsupported mechanism
instead of ignoring it, e.g. "+!dkim")?
* "(v=)spf2.1 ..." (support both "v=spf2.1" and "spf2.1"!)
* Support both SPF (TYPE99) and TXT formats
* Binary (compressed) RR format?
* Backwards compatibility with SPFv1 and Sender ID:
* "v=spf1" == "v=spf2.1 s=mfrom,helo"
* "spf2.0/<scopes>" == "v=spf2.1 s=<scopes>"
* Implementation detail: transform the results obtained from legacy
SPF/S-ID parsers, or transform raw records into v=spf2.1 records
and process normally?
* Upwards compatibility to v=spf2.# (#>1)?
* Scopes as positional "s=" modifier,
e.g. "v=spf2.1 s=mfrom,helo ... s=helo ... s=pra ... s=from ..."
* Positional modifier quality depending on specific modifier definition,
i.e. every modifier can (must) be defined as positional or not
* Make "include:" more tolerant:
* Treat "include:domain-without-spf-record" as no-match instead of
error?
This will negatively affect deliverability. I think a better question is to
reopen the notion that a permerror should be rejected.
* Tolerate circular inclusions
(a.org: include:b.org, b.org: include:a.org)
* "op=" modifier (positional?) (Hi Frank!)
* Replace "~" qualifier by "testing" flag (op=testing) (so people don't
leave their testing records in "~all" state forever)?
* "Authentication-Results:" header (draft-kucherawy-sender-auth-header)
instead of "Received-SPF:" header,
or out-source results header into separate RFC altogether.
* Explicit support for specification of reputation/accreditation, e.g.
"s=helo repu:%{dr}(_at_)helo(_dot_)repdb(_dot_)org s=mfrom
repu:%{dr}(_at_)mfrom(_dot_)repdb(_dot_)org"
("repu:" mechanism vs. "repu=" modifier?)
Most ideas should be self-explanatory, but some probably need to be
discussed in depth. And please bring up your own ideas, too!
Now let's collect and discuss valuable ideas first and _then_ weight the
costs against the benefits. After all, the chances of a new SPF version
strongly depend on what it has to offer.
Julian.
References:
1.
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200603/0069.html
Sounds like a good start.
Scott K
-------
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/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com