Pants Full of Unix

I think this works more reliably:

header MPOP_MUA X-Mailer =~ /\bmPOP Web-Mail\b/
describe MPOP_MUA (False?) useragent used by anti-Bayes spam.
score MPOP_MUA 0.75 0.75 2.50 2.50

header ANTIBAYES_SUBJECT Subject =~ /\bRe: ([A-Z]+|%RND_UC_CHAR\[2-8\]),\s+\p{IsGraph}+\b/
describe ANTIBAYES_SUBJECT Subject matches pattern for anti-Bayes spam.
score ANTIBAYES_SUBJECT 0.75 0.75 2.50 2.50

header ANTIBAYES_MESSAGEID MESSAGEID =~ /\b[A-Z]{7}-[0-9]{13}@\b/
describe ANTIBAYES_MESSAGEID Message-ID matches pattern for anti-Bayes spam.
score ANTIBAYES_MESSAGEID 0.75 0.75 2.50 2.50

meta ANTIBAYES_SPAM (MPOP_MUA && ANTIBAYES_SUBJECT) || (MPOP_MUA && ANTIBAYES_MESSAGEID) || (ANTIBAYES_SUBJECT && ANTIBAYES_MESSAGEID)
describe ANTIBAYES_SPAM Several indications of anti-Bayes spam.
score ANTIBAYES_SPAM 1.50 1.50 5.00 5.00

The idea here is that some HTTP relays that these people use blank the subject, some of the SMTP relays that they use overwrite the Message-ID (in ways that SpamAssassin's MESSAGEID doesn't necessarily catch; it does look for things like Message-Id, X-Message-ID, and some other common one, and the pattern returns true if any MessageID field matches the regexp), and I'm not convinced that the X-Mailer field is unique to this spam.

So, instead of hiding the checks all in one, we let each of these rules add some spamminess, and if two (or more, of course) of them match, then we add even more. The even more isn't really supposed to cause a positive effect on the message's score; it's supposed to counter act the predicted wrong decision that the Bayes module will make. (Note that feeding these messages through sa-learn would probably be a bad idea; it's not smart enough to look for multi-word trends or do quite as well with word frequency as SpamProbe's, as near as I can tell.)