https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7982
--- Comment #19 from Sidney Markowitz <[email protected]> --- (In reply to Henrik Krohns from comment #18) > For example it's assumed that data/nice/002 hits these rules to get a -2 > score, which the string match expects > > -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list > manager > -1.0 NICE_REPLY_A Looks like a legit reply (A) That explains why it is such a problem. If the rule is written like that we can't even consider leaving it relying on the rules in trunk. The test in 3.4.6 does not check for any exact score. How can we have a test that relies on the current live rule set always producing a score of exactly -2 on that sample email? And that score has nothing to do with what this test is supposed to be testing, who cares if it is exactly -2? The NICE_REPLY_A rule isn't even mentioned in the test itself. I can see from the log of a successful run of the test that those two rules appear in the headers. But that is not true if I don't have the trunk version of 72_active.cf in rules. Without that version of 72_active the test fails and there is no indication as to how it expected to get a -2 score, only that it didn't. I don't think it is worthwhile to rewrite sql_based_welcomelist.t. As you say, other rules could do the same thing with data/nice/002. Now that I know what is going on, I can look in the logs for a successful run of a test to see exactly which rules end up used, and I can add those to 01_test_rules.cf. That is a lot more sensible than if I had to include all of all 16 rule files that the test needs and pare it down with trial and error. -- You are receiving this mail because: You are the assignee for the bug.
