> Matthias, If it is possible for you to identify which of the BLOCKED ip > addresses are open nameservers, and use a different code for them such as > 127.0.1.255 or 127.0.0.254, then we can have a different rule for them that > has a description that says explicitly not to use open nameservers on the > server that is running SpamAssassin, while making the rule description for > 127.0.0.255 be more specific about high usage requiring a subscription.
It’s not easy to identify open resolvers with good accuracy (eg Google and Cloudflare completely lack PTR records, and we have to resort to guesstimates using ASNs and whois…). I’ll try to add additional meta data so that we can at least manually mark „entries of interest“. But we would not want to update that frequently and on an ongoing basis if it can be avoided... > And now I realize that I was forgetting how each query is going to be for a > different ip address with its own A record lookup, so increasing TTL is > unlikely to have any noticeable effect. We used to have much longer TTLs some years ago (it was 24 hours, IIRC). However this has the risk that fixing a wrong listing would also take that long to propagate. Back then we experimented with different TTLs, and interestingly there was not much net effect between eg one or two hours. I suspect this likely for two reasons: 1) some „conscious abusers“ ignore the TTL anyway, 2) the query questions are statistically heavily skewed: relatively few questions will have relatively good caching regardless of TTL, while the long tail of questions has relatively poor caching regardless of TTL. > Maybe it is better for us to increase dns_bock_time as a way to reduce load > on all dnsbl servers. All of the dnsbls that support BLOCKED codes are > dealing with the same situation of having infrequently updated ip addresses > that they are blocking. Dynamically set the dns_block_time to the same value as the TTL for each zone? — Matthias
