On Mon, 2005-03-21 at 04:26, Frank Ellermann wrote:
Andy Bakun wrote:
It was a chicken-and-egg problem, and SPF chose the way
it did for deployment-likelyhood reasons.
ACK, we apparently agree on many things. So what should
Wayne do in -01, submit it as is (~ -00 minus zone-cut),
or replace the 3*10 by an overall counter and limit X ?
Have we fully explored different weights for each mechanism based on
what kind of DNS load they exhibit?
We are kind of at an stalemate here. Radu wants everyone to have a
"zero load SPF record", which is actually a valid goal (and good
buzz-phrase). Others don't want to suggest that people not use the
features of SPF that actually make it SPF because those features have
legit uses (zero load SPF records are just RMX in disguise). There is a
middle ground.
These numbers below are just an example. I chose these weights based on
my understanding of how expensive each one is to DNS, how likely it is
that the MTA would do that anyway, and if the result will is logically
cachable; my understanding may be flawed.
mechanism/modifier | weight
all | 0
a | 2
mx | 1
ptr | 2
ip4 | 0
ip6 | 0
include | 1
exists | 3
redirect | 2
The upshot of this is that it will be more obvious to people creating
records which mechanisms they should avoid if they can. Right now, it's
a free for all. It also makes it a little easier to see how records can
be compiled/optimized and still retain the same functionality. It is
also much easier to talk about "light mechanisms" vs "heavy mechanisms"
and "light records" vs "heavy records".
The baseline is 2. I've given mx 1 because the MTA needs to
look this up anyway, so it's a lookup, but it's cheaper than
other queries that the MTA might not need to do without SPF
(although, many MTAs do a and ptr lookups, but that's not
required to accept mail, and may be less required when SPF sees
significant deployment).
I chose 3 for exists because these are presumably either a
lookup that immediately results in success or failure (and thus
the processing ends) or is run in front of a stunt DNS server
that gives results that are less cachable (and thus a bigger
load hit).
include gets 1 because the included SPF record gets evaluated
also and its weights get added. I don't want to punish people
for using include if it make sense (it should be considered the
right thing to do to include someone else's complex record
rather than make an additional complex record). I could see
swapping the weights of redirect and include.
all, ip4 and ip6 require no lookups, so they don't count against
any lookup total.
I'm not sure what the total allowed weight should be before returning
PermError, but I don't see any problem with using Wayne's current
values. Again, larger limits make the hard things (complex setups)
possible. But people need to realize that their setup is complex, as a
way to drive change. Weighing the SPF record like this could be a step
in that direction.
--
Andy Bakun <spf(_at_)leave-it-to-grace(_dot_)com>