Bug 4042 - _score_ has lost the leading zero
Summary: _score_ has lost the leading zero
Status: RESOLVED INVALID
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Score Generation (show other bugs)
Version: 3.0.1
Hardware: Other Linux
: P5 normal
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-12-17 16:24 UTC by trio universero
Modified: 2004-12-17 08:36 UTC (History)
0 users


Attachment Type Modified Status Actions Submitter/CLA Status
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description trio universero 2004-12-17 16:24:17 UTC 
Saluton,

   Forgive me if i am doing this incorrectly, i am new here. I searched for a
current bug listing on this but found none.

   I am running Debian Linux and switched from the default SpamAssassin, whch i
believe was v2.?? to BackPorts.Org's version which is v3.01. I rewrite the
Subject with the string "SPAM _SCORE_ >>>". Previously, i could sort my messages
by Subject and get a listing such as:
=====
SPAM 05.67 >>> Viagra
SPAM 12.34 >>> Mortgage
SPAM 23.45 >>> Phishing
=====
But now i get:
=====
SPAM 12.34 >>> Mortgage
SPAM 23.45 >>> Phishing
SPAM 5.67 >>> Viagra
=====
I have already trained all of my users to do this and search for any false
positives via this method and "... anything above a score of around 10 is
usually safe to throw away..." So if there is a list of 30 or 100 spams (not
unusual), the user (and myself) have to scan all the way to near the bottom,
somewhere, to see if there are any false positives.

   Maybe i missed it, but is there a "switch/flag" i am missing to put the
leading zero back in? If not, i suggest that this be put back to the old method.

   Dankon.
Comment 1 Theo Van Dinter 2004-12-17 17:36:55 UTC 
>   Maybe i missed it, but is there a "switch/flag" i am missing to put the
>leading zero back in? If not, i suggest that this be put back to the old method.

This is a use issue and should be discussed on the users list, there is no bug here.

BTW, the documentation clearly covers this:

        _SCORE(PAD)_      message score, if PAD is included and is either spaces or
                          zeroes, then pad scores with that many spaces or zeroes
                          (default, none)  ie: _SCORE(0)_ makes 2.4 become 02.4,
                          _SCORE(00)_ is 002.4.  12.3 would be 12.3 and 012.3
                          respectively.