Loren Wilton <[EMAIL PROTECTED]> writes: > meta LW_BIG_AND_RED (HTML_FONT_BIG && HTML_FONTCOLOR_RED) > describe LW_BIG_AND_RED BIG RED TEXT > score LW_BIG_AND_RED 3
Someone with a corpus could certainly give it a shot. It's speculative without a corpus run, though. >>> The COLOR_UNSAFE rule would be very useful if it worked better. It >>> seems to catch a lot of the fffffe and fefefe type colors on a white >>> background, but it misses a lot fo them also, such as when the color >>> value is 2 lines after the keyword. Do you have an example that is missed by our renderer, but actually renders as said color in a mail client? >> The main problem is that it hits more ham than spam. > And as written it doesn't catch a lot of the bogus values, although it > catches some of them. I believe I said above "if it worked better". Define "bogus values"? Which bogus values are not being caught? How do you propose to reduce ham hits on the so-called unsafe HTML colors? Even if it is missing some spam hits due to some parsing problem, the ham hits are still rather high. > This rule needs sharpening, not deleting. Okay, please propose something substantive or submit some code to sharpen. Daniel -- Daniel Quinlan anti-spam (SpamAssassin), Linux, http://www.pathname.com/~quinlan/ and open source consulting
