spf-discuss
[Top] [All Lists]

Re: XML!! Lets bang square peg into round hole!!

2004-06-01 11:02:42
On Tue, 2004-06-01 at 09:34, Jeremy T. Bouse wrote:

      I think people are failing to miss what I thought was the entire
point of James' intent which was why are we even bothering to waste time
contemplating the use of XML within DNS records for the publishing of

You would be correct there Jeremy.  Using XML is just plain WRONG.  I
love your analogy:

You wouldn't see a brain surgeon using needle nose
pliers during surgery would you?

Yet amazingly people in here are STILL missing my point:

On Tue, 2004-06-01 at 10:19, Guillaume Filion wrote:

People will complain about that lousy syntax, and ask why we didn't
choose XML in the first place.

The dual syntax offers the simplicity of ol'SPF with the
future-proofness of XML.

Give me a break!  We were doing perfectly fine until all this useless
banter about XML started up again.  Superb discussion was occuring in
the SRS/SES department and all was well until you know who came along
and waved their magic carrot in front of the donkey.

If XML is so great, why didn't we decide to use it in the first place? 
Because SPF would NOT even exist if Meng had opted to go with something
as LUDACRIS and placing XML inside of DNS records.  XML is so NOT ideal
for this task, and there are far better tools for the job that use less
space and offer more functionality, even something like JSON.  Yet even
with things like that about, SPF decides to go with its own syntax, and
somehow we've got much of the world's attention, all because we chose
NOT to go with XML?

Remember the point here.  SPF is not a permanent thing.  It is a MEANS
to an end.  Its goal is to stop forgery, nothing more, nothing less. 
Let me REPEAT: SPF IS DESIGNED TO STOP FORGERY, NOTHING MORE, NOTHING
LESS.  

On Tue, 2004-06-01 at 09:21, Greg Connor wrote:

I think the merger talks with MS are important.  This is not to say
that we should all capitulate and use XML, but there are other reasons
(mostly non-technical) why some level of cooperation makes sense.

And I would agree with you Greg, however, what we need to have Microsoft
do, is take their shiney XML and remove it from the table.  I have no
qualms with them wishing to be involved, provided they stop with with
this absolute shyte of XML in DNS.  I honestly used to think that MS was
like a bully with a brain, but the more I am exposed to ideas like this
crack-pot...

In comparison to our "which is better" debates, MS seems to have 
sidestepped the whole issue by saying "OK we will read and accept both
formats".

Greg++;

AHA!  Everyone PAY attention to what Greg just said!  Good eye sir.  And
now we've got clueless drones in here saying the exact same thing of
SPF.

  They are also re-swizzling their XML to use the same mechanisms (a,
mx, ptr, etc) so we have already exerted some amount of influence
there.  I don't think it would be such a terrible thing to have
receivers read and understand both, and then let publishers do what
they want.

Greg--;

No, its a BAD thing.  No one believes or enjoys being offered a "choice"
but in this particular case all were doing here is slowing things down
and creating problems.  Please do not miss my point here:

- XML in DNS is WRONG WRONG WRONG.

When an XML library is larger than my ENTIRE MTA, that makes using it
WRONG.  Just what kind of drugs is everyone on here when stopping
forgery requires more code than one of the worlds most popular MTA
implementations?

Everyone has been using SPF, whilst no one has been using CID, so
Microsoft came back because they fear Google and Yahoo.  So why in God's
name are we sitting here capitulating to this bastardization of SPF?!

Cheers,

James

-- 
James Couzens,
Programmer
-----------------------------------------------------------------
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xBD3BF855

-------
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

Attachment: signature.asc
Description: This is a digitally signed message part