You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2009/09/03 02:36:40 UTC

[Bug 6192] New: masscheck "got hit" reports target filename instead of matched text

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6192

           Summary: masscheck "got hit" reports target filename instead of
                    matched text
           Product: Spamassassin
           Version: SVN Trunk (Latest Devel Version)
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Masses
        AssignedTo: dev@spamassassin.apache.org
        ReportedBy: jhardin@impsec.org


Running a local masscheck on 9/2/2009 I'm seeing stuff like this in the logs:

log:[2029] dbg: rules: ran header rule INVALID_DATE ======> got hit:
"/home/jhardin/develop/spamassassin/corpora/ham/lib.mbox.12411"

...a header rule is getting a hit on the _corpus filename_?

Not all rules are doing this, but several of the header rules are behaving the
same way.

The corpus file is properly formatted and named. The number after the filename
appears to be a line number, as running masscheck against a single file
containing a single message reports a filename ending in ".0"

Is this just cosmetic?

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 6192] masscheck "got hit" reports target filename instead of matched text

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6192


John Hardin <jh...@impsec.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|enhancement                 |trivial




--- Comment #2 from John Hardin <jh...@impsec.org>  2009-09-03 08:20:53 PST ---
(In reply to comment #1)

> whatever was previously left in the $& is
> reported in a debug call.

...which is cosmetic. Good, thanks for figuring that out.

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 6192] masscheck "got hit" reports target filename instead of matched text

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6192





--- Comment #4 from Mark Martinec <Ma...@ijs.si>  2009-09-03 09:49:08 PST ---
> I'm not sure about meta rules, perhaps it's always been this way
> and nobody noticed.

Actually it does not affect meta rules, all affected rules were header rules.


  Bug 6192: suppress logging of $& when its value is not available
  (i.e. when no regexp has been evaluated during rule evaluation)
Sending        lib/Mail/SpamAssassin/Plugin/Check.pm
Committed revision 811024 ( https://svn.apache.org/viewcvs.cgi?view=rev&rev=811024 ).


Instead of an unrelated string it now logs a simple "<YES>".

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 6192] masscheck "got hit" reports target filename instead of matched text

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6192





--- Comment #3 from Mark Martinec <Ma...@ijs.si>  2009-09-03 08:24:49 PST ---
> Could this be related to the "got hit" API changes you recently made?

No, but is related to how the 'exists:' is now evaluated.

Previously it tested for an empty header field body,
now it really tests of existence of a header field, as
the documentation claims it does.

See Bug 5965, change r689682 ( https://svn.apache.org/viewcvs.cgi?view=rev&rev=689682 ).


I'm not sure about meta rules, perhaps it's always been this way
and nobody noticed.

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 6192] masscheck "got hit" reports target filename instead of matched text

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6192





--- Comment #1 from Mark Martinec <Ma...@ijs.si>  2009-09-03 08:08:04 PST ---
>> lib.mbox is the file, and it's formatted correctly. The same thing happens
>> when I tell it to check a single file containing a single message.
>>
>> I think the trailing number is the offset of the beginning of the message,
>> because when I use a single file the number is zero.

These are all either meta or 'exists:' rules behaving this way.

It's because neither meta nor 'exists:' uses regexp matching
in its code, so whatever was previously left in the $& is
reported in a debug call.

For example, here is a compiled code for an 'exists:' rule:

if (defined($hval)) {
  $self->got_hit(q{__TOCC_EXISTS}, "", ruletype => "header");
  dbg("rules: ran header rule __TOCC_EXISTS ======> 
    got hit: \"" . ($&|| "negative match") . "\"")
}

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 6192] masscheck "got hit" reports target filename instead of matched text

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6192


John Hardin <jh...@impsec.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #5 from John Hardin <jh...@impsec.org>  2009-09-03 10:05:44 PST ---
Beautiful. Thanks!

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.