To start with, I am using spamassassin as a part of mimedefang, with network tests enabled.
And here's my situation: I have a Hotmail account, through which I'm subscribed to various Microsoft mailing lists such as security updates, MSDN information, MCP lists, etc. Microsoft's bulk mailer adds a X-Message-Info header. I fetch this mail through gotmail, which then stuffs it through sendmail/mimedefang/spamassassin. The matched rule X_MESSAGE_INFO is worth 4.2 points. With the default threshold of 5.0, all it usually needs is one other rule to push the mail over the limit. One problem is when the piece of mail enters DCC (since Microsoft lists have a HUGE distribution their mail is pretty much guaranteed to be listed in DCC, as I understand it) and is scored an additional 2.2. As far as I can tell DCC does not distinguish between potential spam and ham, so while it's useful in most circumstances it's really easy to false-positive with this rule. Another problem is the path Microsoft mail usually takes to hit Hotmail. A lot of their mailing list servers seem to take an internal path to the Hotmail servers, thus also triggering FORGED_HOTMAIL_RCVD rules, so even if the mail does not hit DCC it can also be snagged by this rule. While I'm happy enough to re-score X_MESSAGE_INFO in my local rules, it seems to me that this rule has such a large false-positive potential that the scoring should be reconsidered "upstream". Thanks for your attention. Guyang Mao - attached are two examples of false-positived Microsoft mail - I have also had Hewlett-Packard mail false-positived by X_MESSAGE_INFO, so it's by no means exclusive to Microsoft lists
hample
Description: Binary data
