On Thu, Jan 22, 2004 at 01:35:11AM -0800, lcarver(_at_)cs(_dot_)ucsd(_dot_)edu
wrote:
| When your network and all the clusters are described by XML, and the
| administrative tools all use XML databases to maintain operations,
| generating an XML SPF record is going to be a lot easier and more natural
| than generating the current SPF TXT record.
Keeping the configuration in XML in your network is one thing. Keeping
DNS zone data in XML is done, too. But that doesn't mean the XML has to
be sent unchanged.
While XML is often said to be human-editable, the fact remains that TOOLS
are almost exclusively used to edit the DATA which happens to be stored in
XML format. Those TOOLS do not force the user to have to know XML, but
rather, to understand the data. So the fact is there not only are ways to
translate things to and from XML, it is also the common practice.
Now how would you do SPF in such an environment? Without any changes to
the DNS/XML tools, there would surely be some way to fill on an arbitrary
TXT record. That wouldn't be the ultimate right way, but it would work
for the moment. Now add a new interface to these TOOLS that understands
(XML without something to understand the data is worthless, remember) the
SPF data model, can present it as an easy to use human interface without
requiring the human to learn the SPF string syntax (instead, they get an
interview form to establish the policy concepts), and store that in XML
in the database. But when it gets to DNS, it will be translated to a TXT
string and sent via DNS in the usual non-XML way.
It is said that some kind of (maybe SOAP like) means to do what DNS does
now will eventually be done in XML. Fine. Go for it. At that time, the
SPF data can go along for the ride in its own XML way. That would make
sense. But in the mean time, in a non-XML DNS world, let SPF's data be
in a nice compact non-XML TXT record.
| Not being an admin, I'd still guess that any the big admin-tool vendor is
| planning to use XML for their next generation of management tools.
Probably. XML is easy to sell to managers, who are the ones to can muster
the massive budgets required to scale up the infrastructure to handle it.
| Meng's suggestion for an xml include directive ("xml:_ep.%{d}") makes a lot
| of sense in this kind of corporate universe.
But that also means EVERY MTA has to handle it.
Instead, there is a better way. Let them use "exists:" and redirect the
query, with all the information that is needed described in the macro form,
and send it to a DNS server built in Java (favorite tool of XML people),
that can directly access that XML data, maybe the appropriate decision,
and send back the yes/no answer. Not only will this work without forcing
all the MTAs using SPF to change, but it also allows the domain owners to
create any new kind of decision logic they want without having to wait for
it to be implemented and deployed in all the MTAs.
--
-----------------------------------------------------------------------------
| 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;±¤Ö¤Íµø?¡