wayne wrote:
Yes, many anti-spam programs send many DNS lookup queries off all at
once, and wait for various responses to come back. For example,
SpamAssassin will do a bunch of DNSBL queries, and only wait for a
certain amount of time for responses to come back before they ignore
them. Since the response for late DNSBL queries will still be cached,
maybe the next email from the same IP address will benefit.
The SA folks were adamant at the MARID interim meeting that requiring
serialized DNS lookups were a horrible idea.
I only have a quick comment on this.
I think the SpamAssassin folks are right, but only from their perpective.
When you query a list of 10 RBLs, chances are that after a few hours of
running, you've done most of the unique queries you will do. This is
especially true for IP based RBLs. (say that you get 10000 unique IPs
per day).
So in the case of RBLs, most queries are answered out of the DNS cache.
Add to this that TTLs on RBL records are probably much longer than the
average SPF record TTL, and doing parallel queries to RBLs is a very
effective and efficient way to go.
On the other hand, if you check SPF records for all the (faked) domain
names fed by the same 10,000 unique sources of email, you'd be doing a
lot more queries, as each IP will forge several domains and user names.
By the time you allow each one of those domain names to take 111
queries, and use several %{l} and %{i} schemes, you'll be generating a
lot more uncacheable traffic than SpamAssassin would.
While the worst case traffic for SPF with parallel queries is much,
much, much worse than RBLs with parallel queries, the best case SPF in
parallel is still much worse than RBL in parallel. (due to each IP
source forging many domains, and SPF records having much shorter TTLs)
What works for RBL does not work for SPF, and vice versa.
Radu.