Hi Harald, On 02/25/2018 04:25 PM, Reindl Harald wrote: >> While being very satisfied, I noticed that some DNS tests often cannot >> be conducted because of rate limits, e.g. by URIBL. At the same time, >> running these tests often will not change the outcome of other tests, if >> the score is already way beyond the threshold. > > wrong assumption > > remaining tests can also lower the score (DNSWL as example) > > remaining tests can also put the score which is below the threshold > because of DNSWL/BAYES_00 and so on beyond the threshold when it hits > URIBL_BLACK
wrong interpretation Here are two arguments how a) the issue you're raising can be mitigated; b) interference with negative scores is _lowered_ by my proposal: 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. 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. In other words, a "failing" test is _bad_ because it may lead to false positives. The "fail-safe" solution would be that failure leads to an increased number of false negatives (i.e. less efficient filtering), but you would never want to inflate the number of false positives. Next time you write, I'd appreciate if you a) assumed that the person asking does in fact have some knowledge, and b) did not make claims about which ungrounded assumptions I may be making. > 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. >> Another solution would be to avoid running queries that don't mean much. >> Unfortunately, I could not find information on this (besides a thread >> from 2004; it seems that at that time, such configuration was not >> possible). > > all DNS queries are fired at the begin in parallel and while SA waits on > the repsones it can and will still run other tests Thank you, this is what I observed. I know that some consider this a performance benefit, and it very well may be. However, my concern is not performance. You know, my mail setup is otherwise so blazingly fast that I don't care if a message arrives two seconds delayed because of a DNS delay ... Instead, my concern is precisely the question that I asked, namely how to influence that behavior you have described. >> Hence: Can I, and if so, how can I configure SpamAssassin to run certain >> tests only after other tests have been run, under the condition that the >> classification result is not yet certain? > > since it is a *scoring summary* the result is *not* certain until all > positive and negative score-points are applied That is just plain wrong. It's like saying "since voting for one party reduces the fraction others, the voting result depends on the last voter". It's just wrong. Imagine a situation where the sum of any potential outstanding scores is positive (or negative, but close to zero). In this case, the result is already certain. And this can very well be the case, as there are certainly tests that never produce a negative score. For example, lets say my threshold is 5.0, and I am using a DNS blacklist with score +5 and a whitelist with score -5. Let's say that these two tests are the only ones postponed (everything else already was run and summed up), and the score sum so far is 32. Thus, the two missing tests may move the score sum so span the range 27 to 37. Are you telling me that the classification result is uncertain as long as the two tests have not been run? Nevertheless, thank you for your answer. In any case, as far as my original question is concerned, I'm as informed as before, and I'd appreciate any additional input ... 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
