Like I said..
The only valid argument is that XML adds bloat.
But i think its advantages out-weigh its disadvantages, which is why I said
to keep it. When SMTP was originally written, no one in their wildest
dreams would have thought it would have become what it is/does today.
Why possibly repeat the same mistakes? Using xml we can express/store *any
data* in Xml. Look at the horrendous beast IMAP has become, with its nested
envelopes and body structures. Xml would have been 10x easier.
I'm also not saying *not using Xml* is bad. I just have a bad feeling we
would be locking ourselves into something, and 5 - 10 years from now we
have to have all these exceptions when parsing data, because of a new format
or something that needs to get added to the spec.
Cheers!
Dave
PS: I'm not a debater, I just want a solution that works. But I'll attempt
to post to reply to some of your comments below.
1. It's bullet proof tested
Yeah. So is Windows.
Windows is an OS, Xml is a file format. I have yet to see some data that
can't be stored in some type of Xml document. So yes, it is bulletproof. I'm
not talking about parsers, I'm not talking about Software. I'm talking about
storing data.
Just like HTML, right?
Yes, exactly. You can pull it up in your favorite text editor and read it. I
didn't say anything about it being pretty.
Why are you comparing XML to mime?
Because Xml and Mime are both text. DNS is typically binary (except for the
TXT records we are discussing). So I just picked Mime. Both store data in a
textual format.
(Paraphrasing: where you talked about downloading all this XML for DoS).
Lists will probably be maintained of those offending domains, so you will
know who they are.
KEEP IT SIMPLE.
Xml as simple. It's so simple, it is bloated. That's it's inherent problem.
----- Original Message -----
From: "Scott Taylor" <security(_at_)303underground(_dot_)com>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Sunday, May 30, 2004 3:46 PM
Subject: Re: [spf-discuss] XML Poll (Please respond only once)
On Sun, 2004-05-30 at 13:55, dave wanta wrote:
Keep XML
1. It's bullet proof tested
Yeah. So is Windows. I bet ASN.1 libraries were all bullet proof tested
too. SNMP too. Everything's been bullet proof tested at one point or
another. Lot of good that does.
2. its extensible by its very nature
3. represent any file structure, easily and effortlessly
4. parsers are easily available
5. it will be accepted by those "part time programmers" who need to whip
something up to get it to work
6. easily readable
Just like HTML, right? So how do you explain the popularity of, for
example, Macromedia DreamWeaver? Sure, *I* opt to edit websites in a
plain text editor, but for some reason people still use such tools.
7. less fragile, than say something as convoluted as mime
Right, or something as wickedly complicated as "v=spf1 a mx -all". Can
someone please hire me a consultant so I can figure out what those 15
characters mean? Why are you comparing XML to mime? Compare XML to a DNS
record... One of these things is not like the other. Everyone sing along
now.
8. will be more acceptable to Fortune 1000 companies
There are more than just 1000 domains on the internet that should be
protected with SPF. The Global 1,000,000,000 are the ones that should
apply SPF. If the Fortune 1000 want to add CID, then great, go for it.
Nothing is stopping them. They are the only ones that need to have the
fine-grained control down to user-level authentication. Most everything
else are vanity domains and small businesses where if they say "all our
mail will come from this one ip address only", then they have succeeded.
SPF, in its current state, is perfect for them and a single dns entry
could feasibly protect them from being Joe-Jobbed.
9. easily scriptable by part time admins.
Ok, so lets say XML becomes part of the standard, and now for every
email we receive, our mail servers download XML files from [every
hostile spammer/vx author on the planet]. We're looking for CID info, so
they know that we are using one of a handful of possible implementations
of it. And since we're looking for CID info to block such spams/viruses,
they are certainly interested in getting back at us, by either
tarpitting or trying to overflow the buffers we have available for XML
data from them, or just plain blasting random data back at us in hopes
of confusing, breaking, or locking up the CID parser. Or maybe just
pointing references back and forth between an infinite set of XML
references to DoS those servers that show a lot of nerve by trying to
block spam. I'm sure big bloated software giants would love to see that
they weren't the only platform susceptible to email-borne nastiness. I'm
surprised they aren't insisting that SPF would benefit from ActiveX and
VBScript too. Then they would certainly have the best implementation for
proliferating viruses, as if they needed any help in that department.
KEEP IT SIMPLE. Thats the best practice in terms of security as well as
processing efficiency. And of course, being understood, accepted, and
implemented by the people that need to be able to understand it.
Other than the comment about it being bloated, I have yet to hear a
valid
negative point.
----- Original Message -----
From: "George Mitchell" <george(_at_)m5p(_dot_)com>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Sunday, May 30, 2004 12:02 PM
Subject: [spf-discuss] XML Poll (Please respond only once)
Before we waste any more time on XML, could we take a quick poll on
whether we want to use it at all? I request all of the members of
this
list respond (once) to the list in this thread, stating simply whether
you believe the SPF specification should include the use of XML. I'll
start off:
I am opposed to the use of XML in conjunction with SPF.
-- George Mitchell
-------
Sender Policy Framework: http://spf.pobox.com/
The Inbox Event at the Marriott San Jose features SPF.
June 2: Email Accountability Symposium (free)
June 3: SPF Strategy BOF (free) where industry will coordinate
deployment timeline
Times: 6:30pm - 8pm, both sessions. http://www.inboxevent.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
-------
Sender Policy Framework: http://spf.pobox.com/
The Inbox Event at the Marriott San Jose features SPF.
June 2: Email Accountability Symposium (free)
June 3: SPF Strategy BOF (free) where industry will coordinate
deployment timeline
Times: 6:30pm - 8pm, both sessions. http://www.inboxevent.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
--
Scott Taylor - <security(_at_)303underground(_dot_)com>
Paralysis through analysis.
-------
Sender Policy Framework: http://spf.pobox.com/
The Inbox Event at the Marriott San Jose features SPF.
June 2: Email Accountability Symposium (free)
June 3: SPF Strategy BOF (free) where industry will coordinate
deployment timeline
Times: 6:30pm - 8pm, both sessions. http://www.inboxevent.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com