https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6389
Adam Katz <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #4 from Adam Katz <[email protected]> 2010-04-06 23:35:26 UTC --- Regarding comment 0 and its sample FP attachment 4721, it looks like that should have been ALL_TRUSTED (see the documentation for internal_networks). While this doesn't solve the bug, it would help alleviate the spammy-messages-from-colleagues problem. Hm. This header from attachment 4730 is quite interesting: X-MIME-Autoconverted: from quoted-printable to 8bit by popo.ctimail.com id o31FCcI16161 I believe this is reporting that ctimail's mail system converted the quoted-printable headers to 8bit, which triggered the rule. Plugging that header into google shows 19k hits, which is small but not intangible. Even my own sendmail server has added it in the past. Comparative data: X-Spam-Status (236k), X--MailScanner (10k), X-Spam-Flag (27k), X-Greylist (17k), X-X-Sender (9k), X-Sieve (7k), X-Received (16k) ... (searches performed in quotes with a second query being "Message-ID" to ensure we're looking at email headers). I've placed a possible fix into our QA system (20_bug_6389.cf in my sandbox) to sanity-check it, containing the following code (the first rule is just a popularity test for that header): header __HAS_XMIME_AUTOCONV exists:X-MIME-Autoconverted header __MIME_QP_TO_8BIT X-MIME-Autoconverted =~ /from quoted-printable to 8bit/ meta DOS_HIGHBIT_HDRS_BODY_BUG6389 __FROM_NEEDS_MIME && __SUBJECT_ENCODED_B64 && __FROM_ENCODED_B64 && __SUBJECT_NEEDS_MIME && __HIGHBITS && !__MIME_QP_TO_8BIT Sadly, this doesn't help the first sample. Appending "&& !__RCVD_VIA_APNIC_LE" would also fail to solve it since it is from France and not Asia. According to yesterday's numbers, that extra requirement would also reduce the spam hit by 43% and the ham by under 20%, reducing 1.1268% spam to 0.7423% and the ham to somewhere between 0.0261% and the current 0.0326%. I'm disheartened by the French FP as it was composed with the latest version of Thunderbird (3.0.4, WinXP, French build), but at least configuring internal_networks would solve it for that particular user's internal company mail. For a full fix, I can think of nothing but removing this rule. The question becomes: how many FPs does this rule really create, i.e. is this an isolated incident? -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
