https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5992
--- Comment #1 from Sidney Markowitz <[EMAIL PROTECTED]> 2008-10-01 20:10:34 PST --- It's worse than that. cotton and mutton also match. The mass-check S/O for the rule is pretty bad. At first I thought we should just delete the rule, but the source of this problem is something else that might need fixing. The sandbox file emailed/00_FVGT_File001.cf redefines all of the replace_tags that are used by the ReplaceTags plugin, overwriting what is defined in rules/25_replace.cf. 00_FVGT_File001.cf has new values for the replace_tags G,I,Q,S,T, and W. The redefinition of I is what is messing up this rule, as it makes tition the same as tiiion, and makes tton the same as tion. I don't think that 00_FVGT_File001.cf should be doing anything that has a global effect on rules that it is not defining. We should remove the unnecessary replace_tag definitions that are already in the standard rule set, and rename the changed tags to G2,I2,Q2,S2,T2, and W2 so that they are only referenced in the rules defined in that file. I'm a little hesitant to push this into the rule updates because it will have the effect of reverting all the replace_tag rules in other files to the behavior they had before any 00_FVGT_File001.cf rules were promoted. But it does seem like the right thing to do. Can anyone think of a way to test this without pushing it out to everyone? Would it work to check in a change to 00_FVGT_File001.cf and compare the S/O's of all rules in 25_replace.cf before and after the change, knowing that nobody will see the change until we push an update through the channel? -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
