https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6188
--- Comment #3 from Warren Togami <wtog...@redhat.com> 2009-08-31 21:53:27 PST --- Created an attachment (id=4528) --> (https://issues.apache.org/SpamAssassin/attachment.cgi?id=4528) Example misfiring __OBFUSCATING_COMMENT_A http://ruleqa.spamassassin.org/20090831-r809502-n/OBFUSCATING_COMMENT?mclog=ham-wt-jp2 Prior to the above patch, all hits of OBFUSCATING_COMMENT also hit __OBFUSCATING_COMMENT_B. It was easy to eliminate __OBFUSCATING_COMMENT_B because seemingly all cases of <! was preceded by either ! or # characters (for some reason I don't understand). Of the original 213 hits, only 71 matched __OBFUSCATING_COMMENT_A. I tried mass-check after applying that patch. Unfortunately, OBFUSCATING_COMMENT is now firing due to __OBFUSCATING_COMMENT_A 133 times in wt-jp2 ham corpus. Was it short-circuiting and not bothering to test __OBFUSCATING_COMMENT_A if __OBFUSCATING_COMMENT_B had fired before? Is there any short-circuiting or order of precedence in booleans of spamassassin rules? This attachment is one example of __OBFUSCATING_COMMENT_A misfiring. <TD class=3D"font_m">=1B$B!X%=3D%&!Y$N<!$O$3$l!*=1B(B =1B$B$"$N?M= 7A$b=3DP$F$-$^$9!#=1B(B<br> It seems for (__OBFUSCATING_COMMENT_A && HTML_MESSAGE), <! can be preceded by other characters including ordinary ASCII letters. I can't think of any way to fix __OBFUSCATING_COMMENT_A to eliminate ISO-2022-JP FP's. It is at least improved a bit with the above patch. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
