SA Bugzilla – Bug 6262
[review] _SUMMARY_ in --test output
Last modified: 2009-12-29 08:55:26 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
fix for next rc.
> 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;
Pressed return too soon. What I meant was: < defined $result ? $result : $full; > defined $result ? $result : '';
(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.
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 :)
+1
(In reply to comment #6) > +1 +1 KAM
Bug 6262: pre-define certain tags which might otherwise remain unrecognized Sending lib/Mail/SpamAssassin/PerMsgStatus.pm Committed revision 894438.
Resolved.