-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of dave
wanta
Sent: Monday, 31 May 2004 7:36 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] was XML Poll
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
-------
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