On Tue, 2005-03-22 at 06:10, Frank Ellermann wrote:
Andy Bakun wrote:
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.
If someone wants to use all ip4 mechanisms in their SPF record, are we
going to stop them because they are not using the other features of
SPF? It is obvious that some of the other features of SPF are better,
but no one is going to enforce their use. The market will decide which
are the most popular features, and, as I've asserted to Radu, DNS
software will change to accommodate them.
mechanism/modifier | weight
all | 0
a | 2
GetHostByName() should be the unit, so here I'd say 1.
Yes, it is a unit, but what I'm suggesting is not that the sum of the
units equal the weight. See below.
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).
I find making mx weighted more reasonable because of the increased query
count.
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
separately).
I was keeping it low because the total weight of the included record
would count against the includer eventually.
exists | 3
That's again a simple GetHostByName() like a, I'd say 1.
Yes, but depending on the actual record asked for, if it has the IP or
the username-part in it, it could negatively influence local DNS caches
if someone is TRYING to DoS you by making your cache entries expire.
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,
True, but ONLY MTAs check MXs, so checking MXs isn't something NEW that
MTAs would do. Thus additional MX queries would be indistinguishable as
received mail or just more sent email. Besides that, even when
receiving mail, the sender has to query MXs, which come out of YOUR DNS,
so it is related to DNS load on the system overall.
Would anyone be complaining "additional email transactions are bad for
the DNS! No one will want to send greater amounts of email once they
find out the load it puts on their DNS servers"? What if MX queries for
SPF checking are considered exactly as expensive as MX queries for
sending email? This is why I weighted mx low initially, because if MX
isn't cheap, then sending email isn't cheap to begin with. But I could
see it going significantly higher.
My weights were not solely based on some raw "number of queries" count,
but on how that mechanism fits into the whole system, just not DNS
(otherwise, the weights are nothing more than a query count, and we
should just count queries -- I'm trying to think about things
differently here). Say there was a mechanism that required downloading
a document via HTTP (an extreme example, which thankfully was shot down
early), something stupid like:
v=spf1 redirecturl=http://www.domain.com/spfpolicy.txt
redirecturl, while it only needs 1 query for www.domain.com, should get
a higher weight because of the increased effort required to handle an
additional TCP connection and the HTTP protocol and document caching
(which the DNS gives you, essentially, for free) during mail acceptance
time. Yes yes, this would be excluded per Wayne's "doesn't use UDP"
razor, but that's not the point.
Anyway, like I said, my initial weights were just off-the-cuff, so they
can be tweaked. But what I'm suggesting for weighting mechanisms is
_not_ just a simple count of calls to gethostbyname() and shouldn't be
compared to each other solely on how many queries they spawn.
I'm guess I'm to the point where weighting on anything other than just a
count of queries isn't any different anyway, especially if the majority
of input into the weight for any given mechanism actually is the number
of queries (which then gives the other, possible inputs to the weight
such small influence as to be inconsequential). I suppose that if I'm
going to assert that DNS will grow/change to handle SPF if it needs to,
I can't also assert that anything other than a simple query count should
go into calculating record expensiveness (otherwise, it's either gaming
or second-guessing the system), especially when DNS is all that SPF uses
to get the information it needs.
But I suppose none of this is worthwhile if no one thinks it's possible
to change the way expensiveness of records are calculated and still
remain backward compatible (although I do think this is possible, by
specifying a high enough limit). One of the goals of the limits is to
avoid abuse, and there's a limit that allows most records to work and
still avoid things running out of control.
or are you talking about MTAs trying some call back methods ?
I am not.
it should be considered the right thing to do to include
someone else's complex record rather than make an additional
complex record
That makes sense, but you're now mixing different goals, DNS
load and sender policy robustness.
These two goals appear to be Radu's trade-offs. I thought they were
orthogonal, because if a policy creator want less load, then he would
reduce his policy robustness (with the least load being all ip4
mechanisms, then he would end up with a record equivalent to RMX).
I don't think anyone disagrees that individual senders need to determine
for themselves (perhaps, if you're an ISP who supports vanity domains,
with input from your customers who might use include) if they need to
make the robustness/load tradeoff in their records.
--
Andy Bakun <spf(_at_)leave-it-to-grace(_dot_)com>