t/debug.t and t/spf.t both have failures. I'm not sure how long ago they
started failing as the failures are hidden by the warning-only failures
in rule_names.t.
Is there a way that we can distinguish between rule_names and the other
failures so that we can go back to sending notification emails
http://bugzilla.spamassassin.org/show_bug.cgi?id=3806
--- Additional Comments From [EMAIL PROTECTED] 2005-02-26 21:54 ---
In Comment #42 Justin says that this is fixed in 3.1.0, with the test not
running as root. But t/spf.t in trunk still has the test to not run if root and
not
I fixed the test failure in t/debug.t checking in to r155617.
The test was just missing a new dbg message tag, replacetags, so I added
it to the list.
I'm less sure about what is the correct thing to do for the failure in
t/spf.t. In that case there is a test for SPF_HELO_FAIL in the test
spam.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4157
--- Additional Comments From [EMAIL PROTECTED] 2005-02-27 03:58 ---
Subject: Re: Reducing System Load with Temporary Rejections - Penalty Box
The problem is that you can't count on a high
score really meaning that some piece
http://bugzilla.spamassassin.org/show_bug.cgi?id=4157
--- Additional Comments From [EMAIL PROTECTED] 2005-02-27 08:15 ---
Subject: Re: Reducing System Load with Temporary Rejections - Penalty
Box
I don't think that additional trickery is necessary because it's only a
5 minute
I had a trick I was using in Exim that worked pretty well and cound be
recoded in perl.
First - I had a list of words spelled correctly that spammers often
deliberately misspell.
What I did was take the subject and the first 200 characters of the
body. Then I removed all the words matching
