Red Hat Bugzilla – Bug 136503
autolearn=ham for spam mails
Last modified: 2007-11-30 17:10:52 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914 Firefox/0.10 Description of problem: First of all, I tested this on Fedora Core 2 (perl 5.8.3) and Red Hat 7.3 (perl 5.6.1, I just changed Req for perl to installed version, and removed compat 5.6.1 thingie from spec file and rebuilt) using SRPM package from test release of Fedora Core 3. Needs to be tested on "real" Fedora Core 3. I've installed spamassassin v3, and run it on two test mails from /usr/share/docs/spamassassin-3.0.0, namely sample-nonspam.txt and sample-spam.txt. For both files, I got autolearn=ham!? Here's the relevant part of output (the headers that spamassassin appended): For non-spam mail, all is fine: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.0.0 For spam mail (GTUBE), it says it's spam, but claims that it told Bayesian classifier that it is actually ham: X-Spam-Status: Yes, score=997.2 required=5.0 tests=ALL_TRUSTED,GTUBE autolearn=ham version=3.0.0 As I said, this is result from backported SRPM package (Fedora Core 2, and Red Hat 7.3), however since components in Fedora Core 2 are similiar in version to Core 3, it might be problem with Core 3 also. All config files were vanilla (as installed from RPM package). Version-Release number of selected component (if applicable): spamassassin-3.0.0-2 How reproducible: Always Steps to Reproduce: 1. spamassassin < sample-nonspam.txt 2. spamassassin < sample-spam.txt Additional info:
if you read the documentation, you'll find that "userconf" rules (including GTUBE) are not considered when determining if bayes autolearn is to occur. so the mail scored a -2.8 via ALL_TRUSTED.
You are right. I missed on that little thingie. BTW, when rebuilding package on RH 7.3, I've noticed that during install stage, man pages are placed into $RPM_BUILD_ROOT/$RPM_BUILD_ROOT/usr/share/man, instead of $RPM_BUILD_ROOT/usr/share/man. Because of this, resulting rpm package has no manual pages (there's find in spec file that searches for files in $RPM_BUILD_ROOT/usr to include into final package). Does this also happens on Fedora Core 3? I've tried doing quick-and-dirty trick to move them to the right place just before the filelist is generated, but I end up with bunch of "error: File not found: /var/tmp/spamassassin-root/usr/share/man/man1/spamd.1" and so on, for each and every man page (if I look on the disk, the files are there).
Just found it. Again, my fault. brp-compress needs to be done *after* I move the files, and before the filelist is generated (yeah, the files where there, but the filelist listed them uncompressed, and on the disk they were compressed). Basically, this is quick-and-dirty cludge. Excerpt from spec file, no patch, sorry. But there's enough meat so that it could be compared with original file and see the change find $RPM_BUILD_ROOT \( -name perllocal.pod -o -name .packlist \) -exec rm -v {} \; find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2>/dev/null ';' # this is my cludge to move the files to the right place if [ -d $RPM_BUILD_ROOT/$RPM_BUILD_ROOT/usr/share/man ] then mkdir -p $RPM_BUILD_ROOT/usr/share/man mv $RPM_BUILD_ROOT/$RPM_BUILD_ROOT/usr/share/man/man1 $RPM_BUILD_ROOT/usr/share/man mv $RPM_BUILD_ROOT/$RPM_BUILD_ROOT/usr/share/man/man3 $RPM_BUILD_ROOT/usr/share/man gunzip -r $RPM_BUILD_ROOT/usr/share/man fi # moved brp-compress here, so that it is executed after # files are moved, and before filelist is generated [ -x /usr/lib/rpm/brp-compress ] && /usr/lib/rpm/brp-compress find $RPM_BUILD_ROOT/usr -type f -print | sed "s@^$RPM_BUILD_ROOT@@g" | grep -v perllocal.pod | grep -v "\.packlist" > %{name}-%{version}-filelist
Was error on my part, not a bug.