In <200406011930(_dot_)29551(_dot_)lars(_at_)dybdahl(_dot_)dk> "Lars B.
Dybdahl" <lars(_at_)dybdahl(_dot_)dk> writes:
Tirsdag den 1. juni 2004 19:19 skrev Guillaume Filion:
People will complain about that lousy syntax, and ask why we didn't
choose XML in the first place.
It's much easier to introduce XML later, than to introduce a concept
like SPF in the first place. I know that introducing XML will require
replacing all software, but so does new SMTP extensions, non-ascii
domain names etc.
Right. SPFv2 could easily be "v=spf2 <xml document>" *IF* there
really is a need for XML.
Personally, I have real doubts about needing to extend the SPF syntax.
If we are going to allow rejecting email before the DATA command, we
are pretty much limited to things like the client MTA IP address, the
MAIL FROM address and the HELO domain. There is a limit to what you
can reasonably do with that information.
In the 9 months since the SPF spec has really started to gel, I have
heard of quite a few proposed extensions to SPF, but very few that
*require* a new version of SPF, let alone a syntax change. Of those
proposed extensions, very few seem worthwhile to me. (All of the
ones that require syntax changes, such as the "error handling", seem
like *very* bad ideas to me. If we want to do Java in a sandbox, we
know where to find it.)
Yes, *maybe* in two or ten years we will figure out some good ideas
that will completely break the SPF syntax, but I think it is also
likely to break the any XML schema that we come up with that is
restrictive enough about what extensions are allowed to prevent
problems with abusive XML records.
I know that my arguments are basically against XML, but I do prefer a
dual-format standard. By having dual formats, you can always specify
99% of all cases using the simple syntax, so that XML is only needed
for the < 1% domains that belong to people, who don't understand the
K.I.S.S. principle :-)
The current dogma is that the XML and SPF formats will be completely
isomorphic. That is, there will be *nothing* that can be done
(semantically) in one but not the other.
I think that the dual format is bad because:
1) It forces people new to SPF to make a "hard" and certainly
confusing choice right off the bat: Do the publish in SPF syntax,
or XML? Which one is "better"? If they are both the same, why are
there two?
2) the two published records could conflict, which will, at best,
cause confusion.
3) It will require two lookups to see if either are available. The
current merged SPF/C-ID proposal calls for the XML to be used. So,
for literally 99.7% of the domains, we will have to check for a
non-existent XML record and also check for the SPF record. (There
are around 250 times as many domains that exclusively publish SPF
records than exclusively publish C-ID records.)
4) You have more than twice the chance that there will be bugs in the
parsing code and twice as much parsing code to test.
5) The current rough draft of the SPF in XML syntax document calls for
IP addresses to have to be parsed for CIDR block notation and for
macro strings (domain names) to be parsed exactly as if they were
in SPF syntax. This is the worst of both worlds! Not only do you
have to do a lot of parsing of the XML data, but you don't get the
XML ability to extend things.
6) People who are trying to figure out email problems will have to
know both formats, making debugging harder.
7) XML in a terse format is hard to read.
-wayne