Quoting Dan Boresjo (dan(_at_)boresjo(_dot_)demon(_dot_)co(_dot_)uk):
On Friday 21 November 2003 2:59 pm, Jonathan Steinert wrote:
What you are proposing would require all mail servers to add a caching
web client to their code. Personally this no longer feels 'lightweight'
in code or in bandwidth.
Well, an HTTP callout is actually very simple particularly if you know what
you expect to receive. It's not more heavyweight than a DNS lookup, in fact
simpler. Perl seems popular around here and has builtin functions that make
this easy. A C implementation may be a couple of pages of code, but still
trivial.
Don't forget that SPF needs to become an RFC. This is a difficult
task at best. I don't think that the RFC folk will have any interest
in overloading the HTTP protocol to fetch SPF records.
Personally I agree with Eric Raymond that TXT records at the top
level are not the proper place for SPF data. A distinct RR type
would be best but that's a major battle. Hijacking an unused,
existing, already supported, RR type might be the way to go.
If TXT records are to be the mechanism then I think they should be
in a subdomain like _spf and not at the top level.
I haven't kept up with all of the draft changes but I am assume the
concept of a fallback domain is still in the draft. IIRC, the
purpose of the fallback domain is to provide a way to publish SPF
records for slow adopters. Perhaps the fallback domain scope could
be extended to those domains that can not publish SPF records for
whatever reason.
I am sure there are enough people interested in rapid, wide deployment
of SPF that we could contribute at least secondaries for the fallback
domain. Creating a semi-public, need some validation to keep spammers
out, SPF publishing mechanism would require considerably less effort
than implementing HTTP overloading in every MTA in use on the planet.
--
John Capo
In terms of caching I personally am planning to cache (domain, localpart,
sender_ip) tuples of SPF results (along with other mechanisms such as
bondersender.org lookups). DNS caching and HTTP caching are both 'secondary
caches' as far as I am concerned.
You may be right that most implementations will want to rely on cached DNS
and
HTTP. How hard can it be to cache (smtp-spf.txt, domain) tuples? Another page
or two of C?
I'm more worried about load than complexity. It will certainly add to machine
and network load, but maybe the benefit outweighs the cost?
- Dan
-------
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.6.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡
-------
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.6.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡