From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030611 Description of problem: http://bugzilla.spamassassin.org/show_bug.cgi?id=2030 spamassassin -r erroneously causes Bayes to learn the spam as ham, effectively poisoning your Bayes database. This bug has been fixed in SpamAssassin Bugzilla. The following unidiff I applied by hand to the SRPM and seems to work for me. Please check before applying to Rawhide. diff -urN Mail-SpamAssassin-2.55.orig/lib/Mail/SpamAssassin.pm Mail-SpamAssassin-2.55/lib/Mail/SpamAssassin.pm --- Mail-SpamAssassin-2.55.orig/lib/Mail/SpamAssassin.pm 2003-05-19 20:06:17.000000000 -1000 +++ Mail-SpamAssassin-2.55/lib/Mail/SpamAssassin.pm 2003-06-19 20:38:58.000000000 -1000 @@ -558,7 +558,7 @@ $mail = $self->encapsulate_mail_object ($mail); # learn as spam - $self->learn ($mail, $mail->get_header("Message-Id"), 1, 0); + $self->learn ($mail, scalar($mail->get_header("Message-Id")), 1, 0); require Mail::SpamAssassin::Reporter; $mail = Mail::SpamAssassin::Reporter->new($self, $mail, $options); @@ -598,7 +598,7 @@ $mail = $self->encapsulate_mail_object ($mail); # learn as nonspam - $self->learn ($mail, $mail->get_header("Message-Id"), 0, 0); + $self->learn ($mail, scalar($mail->get_header("Message-Id")), 0, 0); require Mail::SpamAssassin::Reporter; $mail = Mail::SpamAssassin::Reporter->new($self, $mail, $options); Version-Release number of selected component (if applicable): spamassassin-2.55-2
is this a known issue upstream and has the patch been accepted there?
Yes, it is fixed in upstream CVS. Above is the patch that I used on my production server for a while before upgrading to 2.60-PR2. http://videl.ics.hawaii.edu/~warren/fedora/spamassassin-2.55-2.fdr.1.src.rpm Alternatively though please consider upgrading to 2.60-PR2. They keep saying that 2.60 final is out "soon". I've been using 2.60 PR's in production lately and it works VERY WELL. In any case my spec changes will be useful when RH moves to 2.60 as a few little things changed. http://videl.ics.hawaii.edu/~warren/fedora/spamassassin-2.60-0.fdr.0.2.PR2.src.rpm
Sounds like this might be a rather important fix. Any idea if this will get in cambridge or not chip? I'd like to upgrade / test the new spamassassin, but this seems like a serious bug.
http://videl.ics.hawaii.edu/~warren/fedora/spamassassin-2.60-0.fdr.0.4.rc2.src.rpm spamassassin-2.60-rc2, very heavily tested in production. According to upstream final should be any day now.
We're beyond package version freeze now however. Any such change would have to be approved by notting.
I'd certainly prefer not to ship <foo>-rc versions.
That is understandable, but please patch the bayes poisoning bug at least.
Please apply before Cambridge. This poisoning of the bayes database is very bad. http://download.fedora.us/patches/redhat/0.94/i386/SRPMS.stable/spamassassin-2.60-0.fdr.2.0.94.src.rpm Alternatively fedora.us has just published spamassassin-2.60 which has been proven to be very stable for very many people. This package also fixes the bayes poisoning bug (upstream official release) while fixing several packaging flaws in RH's original package.
can you clarify what those packaging flaws are? diff'ing the specfiles isn't terribly productive since the fedora specfile has a number of whitespace changes. that aside, since 2.60 is in Cambridge, the actual poisining problem should now be solved
I don't have time to analyze it until Saturday. Ville made most of the recent spec cleanups, perhaps he can give you the analysis before then.
Well, "flaws" is a bit strong word here :) Anyway, compared to 2.60-2 in Rawhide, the "meat" of the improvements in the fedora.us version (comment 8) are: * Builds an SSL-enabled spamc. * Uses upstream bzip2'd tarball. * Removes Prefix: - AFAICS the package is not really relocateable. * Owns more dirs to avoid problems caused by unowned dirs on erase (related: bug 73970). * Some (subjective) specfile cleanups, %install in particular. Also, I see the fedora.us version doesn't have "-m5 -H" in SPAMDOPTIONS in spamassassin.sysconfig. I don't know if that is an improvement or a flaw or whether they were removed from the fedora.us version or added in the rawhide one; it wasn't me and the change is not evident from changelogs of either of the packages...
Please minimally apply this spec patch which allows the spec to Require the specific version of perl that was used to build it. It also pulls in perl into the BuildRequires before building. This should theoretically remove the need of changing the spec again along with the perl version. http://www.spamassassin.org/released/Mail-SpamAssassin-2.62.tar.bz2 http://www.spamassassin.org/released/Mail-SpamAssassin-2.62.tar.bz2.asc Please consider upgrading rawhide too. --- spamassassin.spec.orig 2004-01-17 21:47:11.320019205 -1000 +++ spamassassin.spec 2004-01-17 21:47:28.242296090 -1000 @@ -20,14 +20,14 @@ Source99: filter-requires-spamassassin.sh # Patch: spamassassin-2.50-servicename.patch # Patch2: spamassassin-2.50-chld.patch -Requires: perl >= 2:5.8.2 +Requires: %(perl -le 'use Config; print $Config{archlibexp}') Buildroot: %{_tmppath}/%{name}-root Prefix: %{_prefix} Prereq: /sbin/chkconfig /sbin/service #Distribution: SpamAssassin BuildRequires: perl-Net-DNS -BuildRequires: perl >= 2:5.8.0 +BuildRequires: %(perl -le 'use Config; print $Config{archlibexp}') BuildRequires: perl-Time-HiRes Requires: perl-Net-DNS
Oops, that BuildRequires is wrong. It was fine how it was previously. Ville, please submit cleanups for the spec as a unidiff from Rawhide's current spec. I can get them checked in now.
Committed the new Requires line and spamassassin-2.62 to CVS. Should hit rawhide soon. I can incorporate more fixes if necessary. Re-open if you have a spec unidiff.
Note that January 23rd freeze for FC2's test1. So I believe you have a few days if you want your cleanup to go into test1.