On Wed, Jan 21, 2004 at 04:19:49PM -0500, Meng Weng Wong wrote:
| On Wed, Jan 21, 2004 at 01:00:00PM -0800, Hallam-Baker, Phillip wrote:
| |
| | There are two difficulties with this approach. First there is barely a
| | process for developing SPF. Who gets to decide what goes into SPF 1.1? What
| | happens if someone makes a proposal for an extension and the group does not
| | think it is a good idea? There is no way we can force them to drop it, they
| | can go ahead and publish anyway.
| |
|
| The synthesist in me says "let's have it both ways!"
| That synthesist is sometimes wrong, but let's hear his pitch.
|
| Suppose we keep the simple SPF syntax for the common mechanisms: a, mx,
| ptr, ip4. They're the ones that bring 90% of the benefit for 90% of the
| population, at least today.
|
| But we add a new mechanism that indicates where the full-fledged XML
| policy document can be found. If that policy document is present, it
| overrides the regular SPF declarations.
|
| xml:_ep.%{d}
I would not fight this as an XML issue. Instead, I would fight this as
an issue of trying to expect the MTAs to carry out way too many different
kinds of policy. Most (or all) of the mechanisms in SPF now cover the
common things. So why not let more complex policies be handled in the
domain owner's DNS server end, where you can have policies stored in
XML to your heart's content. The mechanism to do this is in SPF already
so doing this is just a matter of grabbing a DNS server written in Java,
tying in the XML toolkits, configuring a few thing to hook it together
(in XML of course), publish an SPF record with an "exists" mechanism to
send all the data you need in a query back to that DNS server, and go at
it at the server end.
| Think of it as an "include" with a twist in the language along the way.
Better to use "exists". See above.
Oddly, this may well end up being just what it was I described a long
time ago (not sure if it was here or not), that ultimately, things just
had to be done on the DNS server end because complexity needs to be as
close as possible to the policy source.
| If a domain wants to express accreditation attributes that are
| inappropriate to SPF, it can do so in the XML space.
It can do the interpretation of it in it's own network in whatever
namespace or format it likes.
| That allows all the "v=spf1 -all" domains to not get into XML at all.
|
| It also allows people to ramp up toward XML compliance while making full
| use of the existing installed base.
|
| Now, if we start down that path, we don't want to entrench XML-less SPF.
| I don't want to see domain owners fearing to publish XML versions simply
| because there are legacy clients that don't read them.
|
| The industry can work together to agree that after a certain date all
| SPF clients MUST read XML. I can add AFTER X DATE, YOU MUST SUPPORT XML
| to the SPF spec.
This is what will meet a huge resistance. XML does not meet resistance
as long as it stays where it has advantages. But there are no TECHNICAL
advantages to adopting XML when what we have right now will work. The
only reason is that some unknown entity wants XML, and wants it for a
purpose that just cannot have a technical foundation.
| This strikes me as the kind of compromise that isn't worth making and
| plain won't work: it's so much cleaner to make XML all or nothing. But
| what do people think? There may be better ways to mandate the
| transition so if an objection springs to mind first see if there's a way
| to work around it.
I can say that if SPF goes all XML right now, I'll probably drop out of
even trying to implement it and may well not even deploy it, just because
of the complexity factors. I use a few things that use XML now and I have
many administrative headaches all the time with it. It has gotten to the
point that I just avoid things with XML, unless I have the time to see if
it is using XML the right way, and truly gains from it (which I believe
SPF will not do).
--
-----------------------------------------------------------------------------
| 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;±¤Ö¤Íµø?¡