Ryan Ordway asks how XML extensibility differs from a hypothetical
version of SPF that ignores both mechanisms and declarations that it
doesn't understand.
The major difference is that the XML (as specified) has more
extensibility points. Consider for example, an SPF record that says
"+mx -exists:%i.blacklist.example.com ?all". The publisher of this is
saying that he normally sends mail from his incoming mail servers; he
never sends mail from known spammers' IP addresses, and he isn't sure
about anything else.
Now suppose that there is an extension that gives feedback to the
publisher when various mechanisms fire. For example, the publisher of
the above might want to receive a copy of any mail that ended up
matching the "?all". (He might also, for other reasons, want a copy of
any mail that matches the "-exists" to be sent to a different address.)
We could invent new SPF syntax to accomplish this like:
+mx
-exists:%i.blacklist.example.com/feedback=forgeries(_at_)example(_dot_)com
?all/feedback=ToAnalyse(_at_)example(_dot_)com
However, with XML we don't need new syntax: there are already plenty of
places to hang new information.
Continuing the example, suppose that the publisher knows that lots of
spammers are forging his addresses, and wants to receive only 1 in every
1000 of them (as samples for prosecution, for example). Maybe the
second term becomes:
-exists:%i.blacklist.example.com/feedback=forgeries(_at_)example(_dot_)com/probabil
ity=0.001
But now we have an ambiguity of whether the "probability=0.001" modifies
"feedback" or "-exists". Again, XML allows us to make the relationships
explicit.
In summary, XML gives us more, and better-defined, extensibility points
than anything we're likely to dream up ourselves as extensions to SPF.
-- jimbo
Internet commerce will never really take off until you can buy something
online without getting spammed by the vendor.