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

That's a long list Julian has... I agree with most (but have different 
view of some details). Unfortunately don't have time to go through details,
but I'll try my best in 5-10 minutes I have right now.

First of all I think SPF should focus first on RFC2821 authorization methods,
i.e. those that can be performed during session and not requiring body.
That means MFROM, HELO, PTR and SUBMIT (without PRA) scopes go first.

Additional non-RFC2821 methods (like PGP) should be supported as policy 
modifiers or custom scopes with custom mechanisms but not as base mechanisms
in equation for determining if email should pass or not (so for PGP it 
could be something like
 v=spfX/pgp +ks:http://pgp.ai.mit.edu/htbin/pks-extract-key.pl?op=get&search=%s 
-all
which means if client system knows about PGP scope, it would be directed
to where PGP publ;ic key of the signer can be found and verified).

For those additional scopes we should be prepared that these will specify 
hosts, domains and URLs more then they do ip addresses, in fact it maybe
that in some distant future SPF is used more as "domain policy framework"
(and personally I think this is better organized approach even for MFROM
i.e. I prefer specifying hosts rather then ip addresses as was in RMX
and original Vixie's repudiating mail from drafts - this is better layered
approach as far as internet architecture). So we should make it easy to specify
domains and URLS and domains in SPF record if we come up with new syntax.

Finally, I think what we also need is general "sender site policy" scope 
that allows site to specify its preferences for use of multiple scopes
together and combining their results. I think introduction of new modifiers
(like +pgp for non header-from scope) directly is dangerous and would lead 
to misleading result, so instead this new general outbound policy would
specify how sender prefers to combine these results with specify operators
allowing to introduce new scopes and modifiers. I have some draft notes
on this and will certainly comment on it later.

Also regarding binary record, while I don't mind research and discussions
about it, I think text format would still be better overall.

On Sat, 11 Mar 2006, Julian Mehnle wrote:

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