I accidentally posted this to spf-devel yesterday, I'm reposting it now to
spf-discuss:
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. In
general, *semantics* based on the XML syntax ignore unknown tokens, parameters,
and blocks. 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.
Why? Because of SPF *semantics*:
3.2 SPF Directive Evaluation
There are two types of directives: mechanisms and modifiers. A given
mechanism type may always appear multiple times in a record.
Modifiers may be constrained to appear at most once per record,
depending on the definition of the modifier. Unknown mechanisms
cause processing to abort with the result "unknown". Unknown
modifiers are ignored by clients.
...
4.2 "include"
...
This mechanism matches when the inner, included query result returns
a pass, and doesn't match when the result is fail, softfail, or
neutral. However, if the new query returns none, error, or unknown,
then processing of the entire SPF query stops immediately and
returns the error result.
...
6.1 Unrecognized Mechanisms and Modifiers
I'm sure there are plenty of other sections I could quote, but this gives you
the general idea. Aborting all processing on errors/unknowns kills
extensibility.
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. (Modifiers could be used to work
around this, but it would be a hack.)
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
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")
I would like to add that I am fairly ambivalent about the whole extensibility
issue. SPF works fine for me the way it is, and will for the foreseeable
future, but I can see how some people feel like it is important.
A hidden problem with extensibility is the fact that non-uniform practices can
emerge and multiple competing mechanisms might fight for dominance. With a
frozen spec, things are a lot more predictable because new mechanisms are
released uniformly with new versions.
Michael R. Brumm