On Wed, 10 Aug 2005, Frank Ellermann wrote:
wayne wrote:
But each new ptr: mechanism doesn't add more DNS lookups,
Depends on the SPF implementation, doesn't it ? Even if
it's smart it has to try to match bar after foo, and baz
after bar. An expensive mechanism, and almost deprecated.
Because DNS servers return all results they think you might need
for each query, *any* DNS application including SPF will include
at the very minimum a simple short-lived cache with no TTL of "records that
have been returned by domain". Given that, new ptr: mechanisms
don't add more DNS lookups (modulo the lazy validation I have
mentioned before). They use CPU to compare the names, but
we are talking about limiting DNS lookups, not CPU.
Is your implementation always "smart" with multiple ptr-
mechanisms ? In your foo, bar, baz.com example, what if
other mechanisms stand between the ptr, and / or if the
qualifiers are different ?
Because of the nature of DNS, yes, all servicable implementations
will be smart in the sense of having the minimal cache of
"RRs seen for this SPF query". They may or may not be smart enough
to delay validation of the PTR records until needed.
In other words, the "count to ten" concept is KISS. Do
really like to add a special rule "count only the first
ptr, and do something with the p-macro if ..." [TBD] ?
Actually, the KISS approximation would be to ignore PTR completely for
DNS limiting purposes as Wayne suggested. A decent model of the lazy
validation PTR algorithm would be to count 1 for the first PTR, plus
1 for each ptr match.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.