In <792DE28E91F6EA42B4663AE761C41C2A0250FE33(_at_)cliff(_dot_)bai(_dot_)org>
"Ryan Malayter" <rmalayter(_at_)bai(_dot_)org> writes:
That's just my point. A whole parser written just for SPFv1 is not a
*simpler* solution.
Writing a parser for SPFv1 is pretty easy, lots of people have done it
in relatively quickly. Correctly implementing the SPF algorithm
appears to be a lot more work, but XML won't make that part any
easier.
With XML as part of SPFv2, a developer implementing SPF for their MTA or
MUA (commercial or free) can simply use the XML parser their development
environment already has, and build only the rejection logic. These
widely-used XML libraries will be, for the most part, efficient and free
of stack-and-buffer overflows, something which cannot be said of a
re-implemented SPFv1.
Are these stock XML parsers designed so that very malicious people can
not create DoS attacks on mail servers via either excessive memory or
excessive CPU usage? I can believe that most will be well tested in
many ways, but a mail server is probably not the typical application
for these parsers.
Also, the SPFv1 language has a lot of underlying complexity. People even
talk about Turing-completeness.
Uh, yeah, but people talk about whether vi or Exim are Turing-complete
also (they are). It is an interesting academic exercise, but of no
real use.
Re-implementing a SPFv1 parser may be
equivalent to writing a (simple) compiler. Do we want to force
implementers (commercial or open) that want to have control of their own
SPF to write a compiler just to use SPF? That's a big impediment to
adoption.
There seems to be *very* little problem getting people to write SPF
parsers. There are many that are available for free with very liberal
licenses.
The reference
code cannot be used for everything.
Why not use one of the many already available SPF implementations?
Does everyone use the free reference
C code provided by ANSI when doing AES encryption?
No, but I sure as heck don't go off and write my own, I use an already
available AES implementation.
Do we all still use
sendmail?
No, but a very large percentage of people still use sendmail. An even
larger percentage use one of the freely available alternatives.
There were "simple" solutions already available for AES and
SMTP... but look what happened.
From what I can see, what has happened is that a vast majority of
people use the existing implementations.
Parsing SPFv1 is really a non-issue. Implementing the SPF algorithm
for checking stuff is easy if you don't try to re-invent the wheel.
XML doesn't help this at all.
-wayne