> > Also of note it looks like the thing has some bugs in it.. it would appear > that $RANDOMIZE is intended to be replaced with random words, but in a few > spots, a $RANDOMIZE got split with a newline in between. It might be > interesting to do a rule to look for it which has some \s?'s added in. > > Something like this rule (note: untested, just conceptual off the top of my > head) > > body LOCAL_RANDOMIZE_SPLIT /\$R\s?A\s?N\s?D\s?O\s?M\s?I\s?Z\s?E/
Sounds good. I'll give something like that a try. But I wonder if the spammers might not just fix that bug at some point, and use their current subterfuge of lots of random words whited out by the font, and URL indirection? Would it make sense for SA, to detect URL indirection and assert a spam tag? Also would it make sense for SA's canonical HTML processing to simply delete "whited out" text from the body text that is subsequently processed? (admittedly, a full "white out" test would have to match the foreground with the current background color, rather than just looking for <font color="#ffffff">, but color="#ffffff" would still catch most of the spam uses of this trick. ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
