On Fri, 1 Apr 2005, Hector Santos wrote:
I was not suggesting of crossing the boundary. I was thinking IP (Not
domain) caching would be in SPF server itself.
You're still crossing the boundary in a way. The correct relation should
have been DOMAIN:HOST:IP (domain authorizes hosts which have specified
ips) with that relation the caching of ip is done by dns and is not
dependent on changing of actual list of hosts and then the feature you
want to add would be easy to handle properly, but as you see below it
can be done right now as well.
If the assertion can be made:
SPF result1 = IP1 : DOMAIN1
then
SPF result1 = cache(IP1)
for any incoming domain from the same IP for a limited "quantum/resfresh"
time.
So what you want is to allow administrator to change spf record but that
those using it could cache particular part of it longer. This is
administration feature that greater majority would not need (how often
do spf records get changes for majority of domains?) and those that do can
use DMP architecture and again use already existing dns per-record caching
architecture.
In particular, the setup is to macro-forward dns request from main spf record
and set very long caching time for that, set short caching time for unknown
(unauthorized) ip and somewhere in between (depending on what ip that is
and if its expected to change) for actual mail server ip:
example.com. 604800 IN SPF "v=spf1 redirect=%{ir}.%{v}._spf.%{d2}"
*.in-addr.arpa._spf.example.com. 1800 IN SPF "v=spf1 -all"
1.0.168.192.in-addr.arpa._spf.example.com. 86400 IN SPF "v=spf1 ip4:192.168.0.1
-all"
(above could also be "v=spf1 +all")
Or simpler alternative (with non-existant record taking default as
set by dns server):
example.com. 604800 IN SPF "v=spf1 exists:%{ir}.%{v}._spf.%{d2} -all"
1.0.168.192.in-addr.arpa._spf.example.com. 86400 IN A 127.0.0.1
The initial SPF(domain) lookup can be used to optional define the "SPF
refresh time" for this IP.
I think this will work for a system where there is high trust, and in the
real world, the majority of sites use an email model closely resembling a
social network, hence, while DNS provides domain caching, SPF can provide
SPF result caching based on IP.
I think it is so interesting, that I am thinking to pencil it in for R&D or
not. :-)
Lucky for us you're not Microsoft who would already be patenting it ... :)
(and then imposing on us no matter if its good for every case or not).
So go ahead with R&D if you have time and resources for it, but I don't
think this feature is needed for SPF (as dns can already do it) and even
if it was there, I don't think it would be much used.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net