Hi Harald, On 02/25/2018 05:02 PM, Reindl Harald wrote: >> 1.) If only tests that are known to have positive weight are postponed, >> no issue can occur. Furthermore, the situation I was referring to is >> where the score is way beyond the threshold; that is, it is a _lot_ over >> the threshold. Any negative scores that (in sum) fall into that excess >> range will be of no consequence. > > well, SA can't know if something has positive or negative weight, > especially when it comes to DNS queries *before* run it
But I do. That's why I'm asking how to configure it. >> 2.) If the DNS tests are done so often that at some point they start >> failing, any potential negative score (e.g. from a DNS whitelist test) >> will not be applied (because the test failed). Thus, NOT limiting >> queries will actually _harm_ negatives scores under some circumstances. > > no, test fail when you exceed a limit to a distinct dns-server, the > DNSWL is pretty sure a different a different dns-server or your local > cache would step in anyways That's true. But as I told you, tests are already failing, so there are already problem with a distinct DNS server. What I am telling you is the following: You are claiming that running certain tests (e.g. the problematic DNS test) in the end, and only if necessary, is a bad idea, because negative weights may change the fate of the message. My point is that precisely because of the same reason, risking running into a rate limit is also a bad idea. So, in summary, the chance of complications is lower if DNS tests are only run when necessary. >>> use unbound as local caching resolver and play around with that two >>> values: >>> >>> cache-min-ttl: 90 >>> cache-max-negative-ttl: 90 >>> >>> 2018-02-24 07:00:56 [856:0] info: server stats for thread 0: 285034 >>> queries, 125619 answers from cache, 159415 recursions, 3196 prefetch, 0 >>> rejected by ip ratelimitin >> >> I am already using a caching resolver > > most people do, but most DNSWBLDNSWL have very low TTL (in the range of > a few seconds) and by default no caching resolver overrides that 1.) Apart from the fact that it may indeed be reasonable to do some ttl config tuning here, we should also consider why the TTLs are so low. Obviously, it has to do with how quickly new entries on the lists become effective (especially the negative TTL). In order words, messing with this makes the DNS lists less efficient. On the other hand, if I could just run those tests after determining whether it's necessary at all, there would be no efficiency impact, but my problem would be solved. 2.) There's a great number of hosts that only send messages once within the TTL (even when increasing to a few minutes). For those, tuning that setup hardly helps. However, avoiding unnecessary queries helps! So, while I'm glad that we've clarified all this, I don't think that any of this was actually directly related to my question. Reminder: My question was not "how to run DNS efficiently" or "how does SpamAssassin run DNS queries", my question was "how can I influence the order of tests". Best, Peter -- ------------------------------------------ a4a GmbH Scheffelstr. 14 97072 Würzburg Germany fon: +49-931-2705351 fax: +49-931-27049942 web: https://a4a.de e-mail: i...@a4a.de
signature.asc
Description: OpenPGP digital signature
