http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4636
------- Additional Comments From [EMAIL PROTECTED] 2006-01-10 22:23 ------- (In reply to comment #21) > For these reasons, I am -1 (that is, vetoing) the current form of this code > that has the performance loss and requires recoding. If the Encode::Detect module is not installed, there is negligible performance loss and no change of behavior from before the patch (other than the bug fix to include text/plain content in the "visible rendered" form). What do you mean by "requires recoding"? I wasn't aware this change required anything. Is your point that there needs to be some way to disable charset normalization in the case where Encode::Detect is installed? > I would also be -1 on requiring any non-utf8 rules to be utf8. I don't understand what you mean by this. > Basically, SpamAssassin does need better understanding of character set and > ability to support more character sets better, for rules, descriptions, > rendering, and tokenization, but I see no benefit to recoding messages, > especially since anti-spam patterns are written against a small subset of > possible encodings. By that argument, there is no need for "body" or "rawbody" rules. There is a small subset of possible transfer encodings and the like. Motoharu-san has given clear, convincing evidence of the value of charset normalization. Are you saying that you have contradictory experience in the Japanese environment? ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
