I agree that supporting two syntaxes is the worst possible option.
On Wed, Jun 16, 2004 at 10:19:39AM -0700, Greg Connor wrote:
2. SPF classic syntax
* Extensibility is a reasonable goal, but should not get in the way of
simplicity, human-readability, and byte-economy, which we see as more
important.
* We are not convinced of the need to bind MARID together with a larger
"email policy" document that is not yet defined.
* SPF classic is extensible by way of adding modifiers (e.g.
domainkeys=all) and by new version tags (e.g. v=spf1d). SPF records may
contain unknown mechanism (like +dk) but pre-existing implementations will
always stop and return "unknown" in that case.
* Support for those domains that have already published SPF is important.
So far I haven't heard any good feature suggestions that require complex,
structured arguements. I fear that supporting XML will lead to more complex
client implementations resulting in more bugs. Many will try to create
extentions and interoperability will suffer. This would cause mail admins
more problems than it solves. As a mail admin I don't want to worry about
what other sites running this implementation or that will do with my record.
They MUST all work exactly the same way. It has to be perfect, not sortof
almost perfect like what we get with web browsers.
I strongly believe that new features should be worked out by groups like this
one rather than being added randomly by vendors. The fact that we must be more
careful when adding features to SPF is a benefit not a problem. This protocol
should do only one thing and do it well: stop header forgery.
From most to least important: Simplicity, byte-economy, human-readability,
extensibility.