On Tue, 08 Jun 2004 11:11:35 +0200, Teddy wrote in
<40C582C7(_dot_)9020901(_at_)teddy(_dot_)ch>
Karl J. Smith wrote:
I can imagine an ugly hack to get around this.
Break things into smaller pieces manually, or with a script, and use a
convention to make 'linked lists'.
e.g.:
_spf_000.karl.com = 'spfv9 blah blah blah'
_spf_001.karl.com = 'more blah blah'
_spf_002.karl.com = 'still more blah'
_spf_003.karl.com = 'final blah 9vfps' # reversed version indicates end
It's not pretty, but it would allow things to remain in UDP, if the
SPF library did multiple UDP lookups.
If it is really neccessary we can do that, but I think if we let away
the XML or include the XML in form of
v=spf1 xml=http://mydomain.tld/spf.xml -all
we don't need that.
Teddy
I think multiple lookups, to multiple subdomains is not a good
idea, for multiple reasons (need a keyboard shortcut for
multiple)
* Using a subdomain will generally require an explicit request,
but when the txt record is in domain being checked, it may have
already been pulled into cache by another request from the MTA
or SPF code.
* Creating subdomain records for those without direct contol of
their DNS is frequently difficult, and even for those that
control their DNS it may not be that easy. This is also a big
problem for the CID XML record location. Whilst support for the
txt record in the base domain is not globally available to all
yet, it is considerably better than subdomain txt records.
* Multiple records in multiple subdomains, even with sequence
numbers is likely to be prone to errors and mistakes, and will
make debugging harder.
I think Teddy's idea has some merit, but there will be much
resistance to it, though for differing reasons, such as:
* The requests should be kept in DNS, this seems a circular
argument to prevent XML adoption at all, with record size
issues, TCP not generally being an option, new record type etc...
* It will require another service (http) to make it work, which
whilst generally available to most sites, is frequently not
under the control of the DNS and / or Email admins. Also mail
servers will require access to HTTP through the firewall, which
is not always available, or only via a proxy, with the coding
and caching issues that brings.
Teddy's suggestion has given me food for thought that may
please many, but not Microsoft, which to to:
* Make the SPF? record have precedent, if it does not exist,
XML enabled software could then check the "default XML record"
location.
* Give the SPF? record the syntax the ability to redirect/defer
to either the default XML record, or a more specific alternate
(format) record for XML enabled software (Somebody suggested
something like this yesterday I think, sorry not to credit if so)
* SPF1 record MUST have (non XML information and/or an XML
redirection) or MUST not exist otherwise.
The idea being to allow for the continuing rollout of of SPF1,
and submission as a IETF standard. Vendors would be able to
decide on whether they have XML support, and we are not left
waiting for the inevitably long time it will take to work out
XML implementation.
IMHO Microsoft will not like this, since the market is more
likey it to decide against them in the short term, also their
solution users would need to provide both SPF and XML records
to be "compatible", rather than all the other providers having
to read XML to be "compatible".
I think XML support is inevitable in the long run, no matter
how many of our dead bodies will have to be stepped over, but I
think we need to quickly find a low pain solution to optional
XML record integration to prevent SPF1 development stalling.
My tuppence worth again, this list is getting expensive.
Karl Prince
P.S. now I know who got karl.com
______________________________________________________________
Email via Mailtraq4Free from Enstar (www.mailtraqdirect.co.uk)