Bug 6262 - [review] _SUMMARY_ in --test output
Summary: [review] _SUMMARY_ in --test output
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Building & Packaging (show other bugs)
Version: 3.3.0
Hardware: Other All
: P1 minor
Target Milestone: 3.3.0
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard: needs 1 vote
Keywords:
Depends on:
Blocks:
 
Reported: 2009-12-23 03:56 UTC by Justin Mason
Modified: 2009-12-29 08:55 UTC (History)
2 users (show)



Attachment Type Modified Status Actions Submitter/CLA Status
pre-define certain tags which might otherwise remain unrecognized patch None Mark Martinec [HasCLA]

Note You need to log in before you can comment on or make changes to this bug.
Description Justin Mason 2009-12-23 03:56:54 UTC
I installed 3.3.0-rc1.proposed2 system-wide on my Ubuntu host here, using

   70  2009-12-23-11:44:52 perl Makefile.PL 
   71  2009-12-23-11:44:54 make
   72  2009-12-23-11:45:05 make test
   75  2009-12-23-11:48:02 sudo make install
   76  2009-12-23-11:48:08 sudo sa-update

all went swimmingly.

   77  2009-12-23-11:48:28 spamassassin --lint

returns no errors.

        spamassassin -Lt < sample-spam.txt 

does the right thing and returns

[...]
X-Spam-Checker-Version: SpamAssassin 3.3.0-rc1 (2009-12-22) on
        jmason.ubuntu.amazon.com
X-Spam-Flag: YES
X-Spam-Level: **************************************************
X-Spam-Status: Yes, score=1000.0 required=5.0 tests=GTUBE,NO_RECEIVED,
        NO_RELAYS autolearn=no version=3.3.0-rc1
[...]
Content analysis details:   (1000.0 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
-0.0 NO_RELAYS              Informational: message was not relayed via SMTP
1000 GTUBE                  BODY: Generic Test for Unsolicited Bulk Email
-0.0 NO_RECEIVED            Informational: message has no Received headers


but

: 88...; spamassassin -Lt < sample-nonspam.txt 
[.....]
X-Spam-Checker-Version: SpamAssassin 3.3.0-rc1 (2009-12-22) on
        jmason.ubuntu.amazon.com
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=unavailable
        version=3.3.0-rc1
[.....]
Content analysis details:   (0.0 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
_SUMMARY_


That _SUMMARY_ line is pretty ugly.

I think this is something to do with hitting no tests at all.  If I use the
svn rules dir, I get:

: 90...; spamassassin -C /home/jmason/ftp/spamassassin/rules -D -Lt < sample-nonspam.txt 
[....]
Content analysis details:   (0.0 points, 5.0 required)
 pts rule name              description
---- ---------------------- --------------------------------------------------
 0.0 T_FSL_HELO_NON_FQDN_2  T_FSL_HELO_NON_FQDN_2
-0.0 T_RP_MATCHES_RCVD      Envelope sender domain matches handover relay
                            domain
 0.0 T_KHOP_NEWSLETTER      BODY: Is a newsletter or has list managing details
Comment 1 Justin Mason 2009-12-23 03:57:58 UTC
fix for next rc.
Comment 2 Mark Martinec 2009-12-23 06:34:16 UTC
> That _SUMMARY_ line is pretty ugly.
> I think this is something to do with hitting no tests at all.

That leaves a question: should all the potentially-to-be-used
tags be pre-defined, or should PerMsgStatus::_replace_tags
replace unknown tags with blank, instead of leaving them as-is:

sub _replace_tags {
[...]
  $text =~ s{(_(\w+?)(?:\((.*?)\))?_)}{
my $full = $1;
        my $tag = $2;
        my $result = $self->_get_tag($tag,$3);
        defined $result ? $result : $full;
      }ge;
Comment 3 Mark Martinec 2009-12-23 06:35:38 UTC
Pressed return too soon. What I meant was:

< defined $result ? $result : $full;
> defined $result ? $result : '';
Comment 4 Justin Mason 2009-12-23 06:55:43 UTC
(In reply to comment #2)
> > That _SUMMARY_ line is pretty ugly.
> > I think this is something to do with hitting no tests at all.
> 
> That leaves a question: should all the potentially-to-be-used
> tags be pre-defined, or should PerMsgStatus::_replace_tags
> replace unknown tags with blank, instead of leaving them as-is:

this is by design :(

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=4793#c15

I would prefer pre-defining the known-good ones.  should be possible
to do that quite briefly.
Comment 5 Mark Martinec 2009-12-23 08:50:29 UTC
Created attachment 4614 [details]
pre-define certain tags which might otherwise remain unrecognized

How about this one.

( I hate returns in the middle of code :)
Comment 6 Justin Mason 2009-12-29 05:00:54 UTC
+1
Comment 7 Kevin A. McGrail 2009-12-29 08:10:01 UTC
(In reply to comment #6)
> +1

+1 KAM
Comment 8 Mark Martinec 2009-12-29 08:54:59 UTC
Bug 6262: pre-define certain tags which might otherwise remain unrecognized
Sending lib/Mail/SpamAssassin/PerMsgStatus.pm
Committed revision 894438.
Comment 9 Mark Martinec 2009-12-29 08:55:26 UTC
Resolved.