[spf-discuss] SPFv2.1: whether, why, and what?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all.

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.

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.

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.

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.

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.

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!
      * 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?
        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?
      * 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEEj7swL7PKlBZWjsRAqV8AKC254Qu8aetZ0BF3OcUVc89RVig9ACbBesW
EdJF7cK2nYz6uueVgc9dzX8=
=BYKB
-----END PGP SIGNATURE-----

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