-----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 Frank
Ellermann
Sent: Tuesday, March 22, 2005 7:44 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: [spf-discuss] Re: Draft ammendments on DNS lookup limits
Scott Kitterman wrote:
"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 ?include:megapathdsl.net -all"
So if I can get Megapath down to 6 or fewer, I should be OK,
right?
Yes, actually 7 for Wayne, my count starting at 1 was wrong.
For Radu it's 6 because he counts the megapath mx as 2, where
Wayne has a separate "per mx" limit.
And yes, I think 10 is to low a number.
And how should Wayne fix it, adopt Radu's single counter with a
higher limit like 20 or more ? My first proposal 40 was based
on one observation "old RR policy", but if we agree that this
was never okay, we could go for 25 or 20.
Bye, Frank
How about:
Overall limit is X (I think 15 is a minimum, but it may need to be higher)
If you neither include another record nor expect to be included (not an
ISP/ESP), then you may use up to X, although you should minimize the number
of queries.
If you are an ISP/ESP and expect your record to be included in other
records, then you must not use more than X/2-1 and you should minimize the
number of queries.
If you are including another record, then you should not use more than X/2-1
in
your record and you must not use or include more than X total, but you
should minimize the number of queries.
This codifies the idea that ISP/ESPs should have more efficient records.
This also gives domain owners that will use an include a guarantee that they
can use one include and not break the limit, while preserving the option to
go count out the mechanisms if necessary for more complex situations. It
also includes the idea that the record should not be any more expensive than
it needs to be (which is in the curren spec, but not highlighted).
Scott Kitterman