https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6344
--- Comment #10 from John Hardin <[email protected]> --- (In reply to comment #8) > First, to my understanding, the noautolearn setting in question is a > masscheck setting. It doesn't change production systems. Apparently that's not true. Per the documentation: $score = $status->get_autolearn_points() Return the message's score as computed for auto-learning. Certain tests are ignored: - rules with tflags set to 'learn' (the Bayesian rules) - rules with tflags set to 'userconf' (user white/black-listing rules, etc) - rules with tflags set to 'noautolearn' I'd suggest that as a general practice _any_ DNS-based rule having a negative score should have the "noautolearn" tflag set. It's not so much a matter of mistrust as a recognition that a temporary mistake by the DNS service could cause Bayes to go off the rails. > Finally, the concept of not learning for the bayesian system based on > certain rules hitting/not-hitting for production systems seems to have > little merit to me. It's not so much that a DNSWL rule hit would suppress autolearning as, if the message is _still hammy_ when DNSWL is not considered, it should be autolearned. So, +1 from me on the initial suggestion, plus review of other DNS-based standard rules for the same change (which will be quick, I don't think many reduce the score). I agree with Jason, "users can easily implement the rule modifications in their site config" is not an appropriate response to this particular case. -- You are receiving this mail because: You are the assignee for the bug.
