https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7944
John Hardin <jhardin@impsec.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |jhardin@impsec.org
Resolution|--- |WONTFIX
--- Comment #1 from John Hardin <jhardin@impsec.org> ---
(In reply to stephansfourie from comment #0)
> I think the __MSGID_OK_HOST in that meta is perhaps missing an exclamation
> mark before it.
No, that was intentional based on a combination that was fairly spammy at the
time. The scored version has exclusions for ham hits and is doing fairly well
in masscheck:
https://ruleqa.spamassassin.org/20211114-r1895009-n/FONT_INVIS_MSGID/detail
I've added another current ham exclusion to reduce the FPs further.
> This matches on good message IDs
It also matches on spam having good message IDs:
https://ruleqa.spamassassin.org/20211114-r1895009-n/__MSGID_OK_HOST/detail
If __MSGID_OK_HOST + other rules hit well on spam and poorly on ham then that
combination is a useful spam sign even though the single rule isn't useful by
itself.
The fact that a rule hits ham is not, by itself, a problem. Has this rule been
contributing to hams being scored spammy?
Rule discussions should take place on the Users mailing list, please follow up
there.
--
You are receiving this mail because:
You are the assignee for the bug.
John Hardin <jhardin@impsec.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |jhardin@impsec.org
Resolution|--- |WONTFIX
--- Comment #1 from John Hardin <jhardin@impsec.org> ---
(In reply to stephansfourie from comment #0)
> I think the __MSGID_OK_HOST in that meta is perhaps missing an exclamation
> mark before it.
No, that was intentional based on a combination that was fairly spammy at the
time. The scored version has exclusions for ham hits and is doing fairly well
in masscheck:
https://ruleqa.spamassassin.org/20211114-r1895009-n/FONT_INVIS_MSGID/detail
I've added another current ham exclusion to reduce the FPs further.
> This matches on good message IDs
It also matches on spam having good message IDs:
https://ruleqa.spamassassin.org/20211114-r1895009-n/__MSGID_OK_HOST/detail
If __MSGID_OK_HOST + other rules hit well on spam and poorly on ham then that
combination is a useful spam sign even though the single rule isn't useful by
itself.
The fact that a rule hits ham is not, by itself, a problem. Has this rule been
contributing to hams being scored spammy?
Rule discussions should take place on the Users mailing list, please follow up
there.
--
You are receiving this mail because:
You are the assignee for the bug.