-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Radu
Hociung
Sent: Friday, March 18, 2005 4:11 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Draft ammendments on DNS lookup limits
Scott Kitterman wrote:
I'll be the first to object. Go look at my record and tell me
how to make
it less expensive? BTW, the ip4: mechanisms are a best guess
for Comcast.
I'd be interested to see if you can figure a way to do mine in
10 queries or
less. My DSL provider's record takes 10 by itself, and so once I include
that one, I'm already at 11.
Hello, Scott,
First, can we agree that SPF was not invented to resolve an individual's
spam problem? I think that those with complicated setups should find
solutions. Otherwise, there will always be someone with a more
complicated problem than the specification allows, and we'll never find
a solution that makes everyone happy.
Second, the answer to your question follows. There may be bugs in
spfcompile, and they will manifest themselves below. It is work
in progress, but I do think it shows promise.
[root(_at_)sun src]# spfcompile -sender scott(_at_)kitterman(_dot_)com
-flatten
Compiled record (19 mechs, len 397, cost 2 queries):
v=spf1 ip4:66.39.3.0/24 ip4:209.68.3.0/24 ip4:64.32.194.73
?ip4:204.127.202.0/24 ?ip4:204.127.198.0/24
?ip4:216.148.227.0/24 ?ip4:63.240.76.0/24 ?ip4:209.68.5.15
?ip4:209.68.5.16/31 ?ip4:209.68.1.20 ?ip4:209.68.1.210
ip4:66.80.60.20/31 ip4:66.80.60.30/31 ip4:66.80.60.32
ip4:66.80.60.36/31 ip4:66.80.60.38 ip4:66.80.130.3
?ptr:mail2web.com -all
Due to the fact that I used -flatten, you'll need to run a cron job to
refresh it, just in case one of your providers changes their mail
server config (which typically is very infrequently)
Without -flatten, this is a possible record:
[root(_at_)sun src]# spfcompile -sender s(_at_)kitterman(_dot_)com
Compiled record (12 mechs, len 221, cost 11 queries):
v=spf1 include:webmail.pair.com ip4:64.32.194.73
?ip4:204.127.202.0/24 ?ip4:204.127.198.0/24
ip4:216.148.227.0/24 ?ip4:63.240.76.0/24 a:relay.pair.com
?ip4:209.68.1.210 include:megapathdsl.net ?a:voot.pair.com
?ptr:mail2web.com -all
OK. I'd have to figure out how to get the updated record (from flatten)
published, but I imagine that's manageable.
I don't think that my situation is to far outside the norm, so I do think
your limits are a bit low. Basically it seem that you want almost everyone
with anything other than the simplest of situations to have to go to the
added complexity of compiling and updating the record. I'd say start with a
higher limit and then push to have it reduced over time. If you start with
the limit to low (and I think 10 is to low), you'll just drive people away.
If efficiency is really required, people will push for it, but I think it's
really to soon to know if it's a major issue. Heck, if it's a really big
problem, we'll all probably end up using CSV.
Now, looking at your results, some things seem amiss. Here's my current
record:
kitterman.com text "v=spf1 include:webmail.pair.com ip4:64.32.194.73
?ip4:204.127.202.0/24 ?ip4:204.127.198.0/24 ?ip4:216.148.227.0/24
?ip4:63.240.76.0/24 ?a:relay.pair.com ?mx ?include:megapathdsl.net
?ptr:mail2web.com -all"
Looking at the compiled record first:
v=spf1 include:webmail.pair.com - Good
ip4:64.32.194.73 - Good
?ip4:204.127.202.0/24 - Good
?ip4:204.127.198.0/24 - Good
ip4:216.148.227.0/24 - Missing the leading ?
?ip4:63.240.76.0/24 - Good
a:relay.pair.com - Missing the leading ?
?ip4:209.68.1.210 - Good (this is the IP address of the MX)
include:megapathdsl.net - Missing the leading ?
?a:voot.pair.com - Because of ?ip4:209.68.1.210, this is redundant.
?ptr:mail2web.com - Good
-all
Additionally, I don't understand:
Compiled record (12 mechs, len 221, cost 11 queries):
How does this cost 11 queries?
1 for kitterman.com TXT record
1 for webmail.pair.com TXT record
1 for relay.pair.com A record
1 for megapathdsl.net TXT record
10 for the A records listed in the megapathdsl record
2 for the MX listed in the megapathdsl record (one for the MX and one for
it's A)
1 for the voot.pair.com A record
1 for the PTR record of the sending IP address to see if it matches
mail2web.com
I'm not sure how this can add up to 11?
Now on the flattened record, it appears on casual inspection (I'm not
looking up all the Megapath IP addresses) to have neither the redudnancy nor
the loss of ? problems that the regular compiled record did. It does appear
to have one problem in that all the Megapath IP addresses are listed as
PASS, instead of NEUTRAL (?). I think you perhaps aren't carrying the
?include forward into the IP adresses from the called record.
I hope that helps with debugging your program. I agree that it shows
promise.
I see the biggest benifit as being the flattened record, but that's the
biggest challenge because we have to keep it updated. One of the major
advantages of include: is that I don't have to maintain my record, in
effect, the ESP/ISP does it for me.
Scott Kitterman