(Please note I haven't been on this list long, so if I am repeating
someone elses arguments or commit some faux pas I apologise
ahead of time.)
Jim Lyon wrote:
In summary, the requirements that drove the current design include:
1. It MUST be possible for organizations to publish email policy records
without installing any new software. (This pushes us toward TXT
records.)
Agreed.
2. It MUST be possible to extend the kinds of policy information that
get published in the future, without breaking previously deployed
interpreters. (This pushes us toward XML, plus requiring interpreters to
ignore tags in namespaces they don't understand.)
I agree that extending policy in the future is a requirement.
I don't believe XML is the only way to do this. A more concise
format would serve better. As to ignoring tags that are not
understood this can lead to odd behavior. For example:
if version 1 supports something like this:
<my_mail_comes_from_ip>10.0.0.1</my_mail_comes_from_ip>
and version 2 adds support for something like this:
<my_mail_comes_from_ip>10.0.0.1
<unless_sender_is>bob(_at_)example(_dot_)com</unless_sender_is>
</my_mail_comes_from_ip>
then ignoring the <unless_sender_is> tag can cause the policy
to fail badly in v1 implementations.
(this is a contrived example in which it is obvious the v2
behavior will have a bad failure case in v1, in the real world
version interactions are often less obvious.)
The spf versioning system (where each version can be a
separate TXT RR) allows the publisher to publish v1 and v2
separately and thus work around versioning problems in a
predicable manor.
Also note that TXT records are limited to 127 or 255 bytes
by some nameservers, not the full 512 reserved for the entire
packet. Most XML records will exceed the 127 byte limit very
fast and thus break point 1 of your requirements.
3. It MUST be possible for EVERY organization who chooses to, to publish
their policy data in such a fashion that fallback to DNS over TCP is not
required. (This pushes us toward short XML tags, indirection elements,
and eliminating the boilerplate namespace declarations from the records
themselves.)
I agree that email policy records in DNS cannot push the
packets into TCP space. This "pushes" us away from XML like
formats that needlessly bloat the size of the records.
I would humbly suggest that people who don't like XML, or don't like TXT
records, or don't like something else, either need to argue that the
above requirements aren't appropriate, or they need to explain why their
favorite alternative does a better job than the current design of
meeting the above requirements.
I'd humbly suggest that there are other more concise methods
of achieving the same objectives you've outlined without using
XML at all. SPFv1 already contains enough extensibility to
accomplish the task a hand. The exists method and the ability
to publish v1 and v2 records simultaneously already provide
more than enough extendablitiy. SPFv1 can handle my example
from above by puslishing a v1 record with an exists method and
a v2 record with the new logic. (note, using the exists method
does not automatically violate point 1 from above, see Meng's
per user SPF examples.)
Also note that the recent poll on the SPF mailing list came out
12:1 against XML, and there is now talk of forking SPF should
XML be introduced. (Some already want to fork based on it's
consideration alone.) If MARID continues to consider XML it
should also start thinking about how it's going to generate
buy-in from the existing SPF community to prevent a fork from
happening should XML be adopted in the end.