Bug 136503 - autolearn=ham for spam mails
autolearn=ham for spam mails
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: spamassassin (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Chip Turner
:
Depends On:
Blocks:
  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:
Environment:
Last Closed: 2005-01-26 12:03:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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
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:
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 
ALL_TRUSTED.
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 ]
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
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.