terry(_at_)ashtonwoodshomes(_dot_)com wrote:
Um, how does the complexity of XML improve security. I can think of examples
where XML enhancements
CAUSED exploits, and there are implementations where the XML implementation
poses denial of service
exploit by sheer processing power needed for a full XML parser.
I do trust a parser generated by a parser generator or a common XML
library much more than any hand-coded quick and dirty SPF parser.
There is not automated parsing tool for SPF, and a syntax like SPF
invites for a quick and dirty implementation. Eats valid SPF records.
But that's how buffer overruns are generated.
How is this a "single shot" at upgrading email? The SMTP protocol has been
evolving for a VERY long
time.
That's nonsense. The SMTP protocol was evolving at a time where
the "Internet" consisted of a few hundred users and where e-mail was
just an experiment, where nobody complained if it didn't work for some
time. e-mail was a researchers game, not a highly relevant communication
medium. SMTP had time and chance to evolve.
But to follow your argument: How much time would you like to have for
SPF to evolve? 3 Years? 5? 10?
Interesting arguments on extensibility. All valid. Also all valid for SPFv1
due to the fact that
SPFv1 is extensible.
"Extensible"? You mean you can add new, unknown entry types. Is this
"Exensibility"?
Is it possible to add a time limit to an IP address without loosing
backward compatibility?
Can I extend an entry giving permission to the address 1.2.3.4 such that
it is allowed
only during business hours, while keeping compatibility with older
version (which would
give permission around the clock)?
What if I wish to add, e.g. cryptographic keys or jpeg images to the
records? What if
an entry becomes 180,000 bytes long? Are you sure that all SPF
implementations
will eat this without problem? No buffer limits?
Is SPF really "extensible"? Or is it just not well defined?
Is that what you call "Extensibility" more than just a gap in the
definition?
Hadmut