spf-discuss
[Top] [All Lists]

Re: The Case For XML in "Caller-ID for Email"

2004-01-23 18:31:11
On Fri, Jan 23, 2004 at 02:32:26AM +0000, Dan Boresjo wrote:

| XML only generalizes syntax. I believe it is critical for SPF to have an 
| architecture that is *semantically* unambiguous. When I publish an SPF record 
| I need to be sure that everyone on the planet who reads it interprets it in 
| _exactly_ the manner intended. I certainly don't want the meaning of my 
| publication to be wrongly interpreted based on differing support for various 
| open-ended 'optional' semantic elements, 'modules' and 'extensions'.

My original proposal of a DNS based Designated Sender mechanism was let
the DNS server itself perform all policy interpretation.  A DNS query
would (eventually) include all the necessary data about the arriving
email, including where it comes from, to allow that decision to be made.
The advantage I see for that is that usage (a DS client) would be "dumb",
while all the smarts are close to where the information, and policy, is.
This would allow extensibility of complex, clever, or innovative policy
and evaluation against policy, without the delays in implementing the
new ideas in every program, and deploying them to every server.  Only
those who actually need the special cases would have to implement and/or
install programs to carry them out (as custom or hacked DNS servers).

SPF can do this now with the "exists" mechanism.  My only problem with it
is that by using NXDOMAIN for a negative answer, it doesn't get to cache
very well.  I'd like to see it _also_ say that an A record in 0/8 space
also means negative (but can be cached as per the TTL value).


| The only reason the MS is interested in design goal #1 is because it 
| legitimizes an 'embrace and extend' strategy under a fictional 'veil of 
| standardization'. This is why XML is their 'pet technology'.
| 
| This argument for XML is rather like agreeing not to adopt a common standard. 
| Duh.

XML itself is a standard.  But it is as open to abuses in how people use
it as ASCII (also a standard) is.


| Parsing SPF as it stands is
| a) Trivial.
| b) Far more lightweight than any XML parser.
| c) Already coded for many languages.
| d) Constrained by DNS character encoding anyway.

DNS character coding is very transparent up to 63 characters per label.


| But we don't want new datums, that would only serve to screw things up. This 
| is an argument _against_ using XML.

Those who want something new can use "exists".  They can even store their policy
on their custom server in XML format for that server to consult to evaluate each
query that is directed to it by the "exists" macro.


| See answer to (2). Note also that XML is complex enough that most parsers 
have 
| a host of bugs and differing interpretations of the standard. Anyone who has 
| ever made heavy use of XSLT and then tried to port it to a different XSLT 
| parser/transformer will know what I mean. 

Sure do.  That's the kind of volatility SPF can do without.


| Why would you want to encrypt your SPF record? Even signing should take place 
| at a lower level, ie: DNSSEC.

Exactly.


| Is it really that complex? Next we'll be encoding text as XML:
| 
| <w>The</w><s/><w>year</w><s/><w>is</w><s/><d>2</d><d>0</d><d>0</d><d>4</d>
| 
| Wow! So many tools can load that sentence in, must be a good idea!

Let's replace ASCII with XML.  No more ASCII.  Just XML.  Yay!


| Only small numbers of programmers are ever going to need to code SPF support, 
| and it's trivially simple to understand.
| As for publishing SPF records, I assure you that TXT in DNS is more intuitive 
| and understandable than XML.
| 
| There exists a large body of _ordinary_ _people_ who own their own vanity 
| domains and understand plain text, no 'techinical professionals' are wanted 
| or needed.

I consider myself to be a Technical Professional.  Does that mean I have to
use XML?


| 
| > | 9.        There exists a dedicated industry (books, seminars, etc) of
| > | companies and people working to educate same and grow this pool. The
| > | investment put into educating oneself in XML is leveraged knowledge
| > | beyond just administering a spam-deterrence infrastructure that can help
| > | one's career grow and expand outward.
| 
| Aha! Playing to the MCSE crowd? I can't argue with this one. 

Or worse, we'll end up seeing:   SPF For Dummies!

-- 
-----------------------------------------------------------------------------
| Phil Howard KA9WGN       | http://linuxhomepage.com/      http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/   http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡