Andy Bakun wrote:
Have we fully explored different weights for each mechanism
based on what kind of DNS load they exhibit?
IMHO yes. Wayne has "if it doesn't work with UDP than SPF
implementations MAY ignore it". Below this limit he has
one query counted as one, with three counters: mechanisms
and redirect= overall, names of MX per mx, similar PTR.
Radu also has one query counted as one, but with one overall
counter. Wayne and Radu of course don't count exp=, it's at
most one query, and at that moment the evaluation is ready.
Radu wants everyone to have a "zero load SPF record", which
is actually a valid goal (and good buzz-phrase).
ACK, but not as an incompatible MUST in v=spf1, and not as an
excuse to hardwire IPs and CIDRs in sender policies where the
other SPF features are better.
mechanism/modifier | weight
all | 0
a | 2
GetHostByName() should be the unit, so here I'd say 1.
mx | 1
For the same reasons 2. Or Wayne's count (1 + 1..10). Or
Radu's count (1 + number of MXs up to an overall query limit).
ptr | 2
Yes, same as for MX.
ip4 | 0
ip6 | 0
include | 1
IMHO include is about as "bad" as mx, maybe minimally worse,
because it has all problems of a q=txt or q=spf, and the not
exactly obvious matching. Therefore I'd say 5. Wayne counts
1, Radu counts 1 or maybe 2 (if he counts q=txt after q=spf
exists | 3
That's again a simple GetHostByName() like a, I'd say 1.
redirect | 2
Whatever it is, it's almost the same as include, so I'd say 5
and offer weight( include ) - 1 as a compromise, because it's
a very straightforward case compared with include.
The upshot of this is that it will be more obvious to people
creating records which mechanisms they should avoid
In that case ptr should be 1 + max( other weights ) or more.
I've given mx 1 because the MTA needs to look this up anyway
For a MAIL FROM nobody(_at_)xyzzy you'd normally not check the MX,
or are you talking about MTAs trying some call back methods ?
it should be considered the right thing to do to include
someone else's complex record rather than make an additional
That makes sense, but you're now mixing different goals, DNS
load and sender policy robustness.
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.
Wayne's limits kill pobox and Scott, an overall limit at least
100% higher than Radu wants (read: 20) would let them live.