One of the purported positives of XML seems to extensibility.
I wonder if this is really an issue.
i.e. is there really much need or value of extensibility in SPF?
In general extensibility is a good thing in protocols. But it only
makes sense if the protocol allows client and server to negotiate the
use of extensions.
In SPF there is little room for negotiation. In particular, the SMTP
client sending a message cannot modify it's behaviour based on what
SPF features the SMTP server recognises.
This means that the SMTP client has to assume the server at-best
understands version-1 features. So there is never any point in
relying on others.
I would particular like to take issue with the example of extensions
mentioned in the SPF doco (I don't remember exactly where).
That is that an unknown directive such as domainkeys:.... should be
passed on the Received-SPF header in case the MUA or similar can
recognise it.
I seriously doubt the value of this. If "domainkeys:" is only
optional, who is going to rely on the recipient understanding it when
they send mail? I think no-one. So what is the point?
Currently recipients "should" accept "almost anything" (though many
don't).
Once there is a standard that allows recipients to treat certainly
classes of mail extra harshly (higher spamassasin weight, etc), there
is no going back.
What am I missing?
NeilBrown