Seems to me that we need yet another test, one that compares the MIME text/plain content with the text/html content, and rings the alarm bell when they have nothing in common.
It's invalid to assume that the two need to be related. Just because SOME mailclients make them the same, does not mean that lack of relationship between the two is a good spamsign. It's quite common in legit HTML newsletters for the text/plain to simply state "this is a html message, view it in a html capable mailclient".
Adding a billion variants of common kinds of "this is a html message" notes as exceptions to the rule is a giant kludge, and a pain in the tail to maintain and fix all the constantly evolving FP cases.
The text/plain section also isn't likely causing enough impact on bayes to be worried about anyway.. That's not the poison that's causing it to miss the BAYES tests... look at the message.. most of the poison is in the text/html section. The text/plain contains 3 lines of poison, the HTML contains 36 lines of it.
I suspect that the above situation is better dealt with by well written rules.. I've been plagued by the same spam, and have modified my ruleset to catch it...
For starters I added some better v-word rules that catch the obfuscations used. I'll be releasing a drugs ruleset next week to catch this junk.
------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
