https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6592
--- Comment #3 from Mark Martinec <[email protected]> 2011-05-18 16:29:39 UTC --- The failing test #14 is just plain wrong I believe. It takes t/data/spam/018 as a data source, which is spammy mainly because it contains a GTUBE test pattern. So when a GTUBE rule has a default score of 1000 the message is clearly detected as spam, which is correctly detected by a test. Now the test #14 switches user prefs to 'score GTUBE 0', which turns off the main reason why the t/data/spam/018 can be considered spam. The test #14 nevertheless still insists that the result should be tagged as 'X-Spam-Flag: YES', but it has no good reason to expect so. As it happens, because of other tests like INVALID_DATE, the message still barely exceeds the spam threshold in trunk and in the 3.3 svn branch (which both carry additional rules) and the test #14 passes, but does not reach a threshold in the distributed package, which has no other rules besides test rules. Suggested solution: - move the 'X-Spam-Flag: YES' from %patterns into %anti_patterns - fix Date header field in the mail sample t/data/spam/018 so that it does not trigger INVALID_DATE -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
