Bug 136503 - autolearn=ham for spam mails
autolearn=ham for spam mails
Product: Fedora
Classification: Fedora
Component: spamassassin (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Chip Turner
Depends On:
  Show dependency treegraph
Reported: 2004-10-20 12:01 EDT by Aleksandar Milivojevic
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-26 12:03:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Aleksandar Milivojevic 2004-10-20 12:01:08 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914

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

For non-spam mail, all is fine:

X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham

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):

How reproducible:

Steps to Reproduce:
1. spamassassin < sample-nonspam.txt
2. spamassassin < sample-spam.txt

Additional info:
Comment 1 Theo Van Dinter 2004-10-20 12:21:21 EDT
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 
Comment 2 Aleksandar Milivojevic 2004-10-20 16:43:27 EDT
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).
Comment 3 Aleksandar Milivojevic 2004-10-20 17:01:45 EDT
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 ]
   mkdir -p $RPM_BUILD_ROOT/usr/share/man
   mv $RPM_BUILD_ROOT/$RPM_BUILD_ROOT/usr/share/man/man1
   mv $RPM_BUILD_ROOT/$RPM_BUILD_ROOT/usr/share/man/man3
   gunzip -r $RPM_BUILD_ROOT/usr/share/man
# 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
Comment 4 Aleksandar Milivojevic 2005-01-26 12:03:13 EST
Was error on my part, not a bug.

Note You need to log in before you can comment on or make changes to this bug.