On Fri, 2008-10-10 at 16:45 +0200, Mark Martinec wrote:
> Benedict,
>
> > I found bug # 3364 in the buglist and according to this it seems like a
> > Debian issue. It doesn't seem to occur on other systems or at least it's
> > not reproducable.
Do you use customized headers? (Sorry, don't have the OP, but IIRC I
spotted some.) What are the results of the snippets in comment 4, and
what about comment 11?
> > The uri bl black is scored as nan again.
> > It's really annoying as this is what probably is causing the score not
> > to be counted correctly.
>
>
> Please try the following patch (to 3.2.5).
> It should produce a warning on stderr when some plugin
> would attempt to add a NaN to score:
>
> --- lib/Mail/SpamAssassin/PerMsgStatus.pm (revision 703484)
> +++ lib/Mail/SpamAssassin/PerMsgStatus.pm (working copy)
> @@ -2141,6 +2138,12 @@
> return;
> }
>
> + # this should not happen; warn about NaN
> + if ($score != $score) {
> + warn "rules: score '$score' for rule '$rule' in '$area' '$desc'";
> + return;
> + }
> +
> # Add the rule hit to the score
> $self->{score} += $score;
Nice. :)
Just thinking out loud, if Benedict would add another line in there, to
force the NaN score to be 0.01, he also could *temporarily* work around
the issue. Mail exceeding the spam threshold then should not slip by
uncaught. Of course, identifying the offending mail for later
investigation would be slightly harder, but less obtrusive for the user,
if he gets a lot of these.
Puzzling, how he gets NaN in the first place. Benedict, did you lint
your rc files? Did you carefully check all score definitions (possibly
including user_prefs) for that rule? (Like using a wrong decimal
separator, or some invisible stray chars.)
guenther
--
char *t="[EMAIL PROTECTED]";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
