Michael has written an excellent summary of the extensibility issue. I
won't repeat it, but I will quote some of his points which are important
enough to read twice :)
--"Michael R. Brumm" <me(_at_)michaelbrumm(_dot_)com> wrote:
A lot of debate lately has been around syntax: XML or SPF-syntax? I think
it's pretty clear that the vast majority of us don't want XML, but there
are some important points being brought up by the pro-XML faction.
Personally, I think XML debate isn't really about syntax, but about
extensibility. The XML *syntax* by its very definition is extensible. ...
However, if you took the most recent SPF RFC
(2004-04) and did a drop-in replacement of the SPF-syntax with an
equivalent XML syntax, SPF still would not be extensible. It would just
be ugly and cumbersome.
...
SPF is basically designed with a "frozen" mentality. This makes it
stable, easy to understand and implement, and uniformly practiced, but
requires a new version (v=spf2 instead of v=spf1) to add new features,
and is less flexible about dealing with ambiguous error situations.
If we want SPF to be extensible, we don't need XML, we need to change the
semantics of SPF to deal with and trap unrecognized mechanisms and errors.
...
Greg Connor recently went into great lengths about this, but it was
generally ignored during all the recent CID hoopla. I suggest everyone
re-read his posting:
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200405/0275.html
Thanks. Here is a quick summary if you don't want to go back and read the
full version.
Suppose the domain owner wants to say, "Use ptr and mx, and use domain keys
if available. If not available, return unknown. If no match to ptr, mx,
or domainkeys, return fail."
Sample extended record (current SPF treats this as an error)
v=spf1 +ptr +mx +domainkeys -all
0. Current SPF method:
v=spf1 +ptr +mx ?all
v=spf2 +ptr +mx +domainkeys -all
1. Add if/then syntax to the language (I doubt anyone would like this :)
2. Use modifiers to say what to do in case of unknown mechanisms.
v=spf1 +ptr +mx unsupported=? +domainkeys -all
The modifier "unsupported" tells what action to be taken when an unknown
feature is encountered. That action will probably be one of:
unsupported=? Stop processing and return "unknown" ("neutral")
unsupported=- Stop processing and return "Fail"
unsupported=+ Stop processing and return "Pass" (pretty unlikely ;)
unsupported=abort Stop processing and return error result (current
behavior)
unsupported=continue Ignore the unknown keyword and resume with the
next step
unsupported=break Stop processing the current record, but if we were in
an include: or redirect= then continue with the previous record
3. Add a "trap" mechanism, which doesn't have if/then conditionals but
still has nesting symbols.
v=spf1 +ptr +mx trap(unsupported=break){ +domainkeys -all } ?all
#3 is probably overkill, most people can get by with one failure/fallback
action. If we really need nesting we could use include: or redirect= to
control where we resume.
Including better error handling would also allow Lars Dybdahl to have his
include's work the way he wants:
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200405/0081.html
(follow the threads that include the subject "Recursion limit of 20
include/redirects total")
Right... if we have a "fallback" or "trap" option, whether nested or not,
that improves our error handling (which is a good thing to gain even apart
from extensibility.)
We could even expand our notion of fallback or trap to "trap" the results
of another record and turn them into different results.
For example, here is another scenario altogether that might
benefit from a trap mechanism.
mydomain.com: v=spf1 +a +ptr include:comcast.net include:earthlink.net
-all
comcast.net: v=spf1 +a +ptr -all
earthlink.net: v=spf1 +a +ptr -all
Now, let's say what I *really* want is to return "unknown" (neutral) for
Comcast, since I have some users, but there are also a lot of forgeries
coming from there. If Comcast says it is a PASS, maybe I really want to
interpret that as an unknown. In other words, I am going to (include,
redirect, whatever) to comcast, and I'm fishing for a + or ? which I will
treat as a ?, and if I get a - or error I will move to the next fork.
So, what I would like in this case is something like this...
mydomain.com v=spf1 +a +ptr +=? ?=? -=break error=break
redirect=comcast.net redirect=earthlink.net -all
Comments? feedback? flames? :)
gregc
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>