[Spambayes] To think like a spammer...

[Tim Peters]

[Mark M. Hoffman]
> ...
> The spambayes scheme (and others like it that I've seen) can be defeated
> easily, with something like this...
>
> <spam>
>
> THIS  IS  A   F A N T A S T I C   O P P O R T U N I T Y ! !
>
> W A N T  TO  MAKE  A  TON  OF  M O N E Y   ? ? ?
>
> THIS   W E B S I T E   HAS  THE  A N S W E R   TO  ALL  YOUR
> F I N A N C I N G   P R O B L E M S ! ! !
>
> IT  COULD  NOT  BE   E A S I E R ! ! !   C L I C K  HERE NOW ! ! !
>
> http://blah.blah.com/blah/blah.html
>
> </spam>

Spam is cheap to send, but it's not free to send.  Crap like that will
certainly lower the response rate, and at some point it won't repay the
cost.

> Even if you back up and allow single character tokens, you're only
> going to recognize a handful of those.

It's easy to teach the tokenizer about patterns like these if they become
popular.

> A spammer could stuff the end of the message with ham words to overcome
> the effect of the single char. tokens.

*That* would be very expensive for spammers to do:  "ham words" aren't
universal, they depend on the kinds of things the end user is interested in.
If spammers had the resource to determine this, they wouldn't be using a
bottom-feeding advertising medium like spam; they'd be using traditional
targeted marketing techniques, which are darned near a science but also cost
Real Money to pursue.

> Do these space-words have to be collapsed to defeat the effect?

Our current tokenizer won't even "see" them (it ignores "words" with just 1
or 2 chars).  If there's anything spammish in the URL or the headers, the
trick won't do them any good.  A simple and cheap tokenization trick could
merely count the number of 1-character "words", and generate meta-tokens
based on that.  For example, while our current tokenizer doesn't know beans
about Asian languages, all the Asian spam in my corpus is caught because the
tokenizer generates meta-tokens indicating what percentage of characters in
a word have the sign bit set.  Asian spam generates lots of meta-tokens of
that nature, and they all end up with high spamprobs as part of normal
training.

> Actually, protection against stuffing the end of a spam w/ ham words is
> an angle we have to be careful about anyway.

There's plenty of spam that does that already.  The error rates I'm seeing
say that spammers can't guess ham words that are strong enough to overcome
their spam words, and that stands to reason.  I *suspect* this is one reason
I find that our robinson_minimum_prob_strength setting lowers the f-n rate
across scheme after scheme:  the best spammers can hope to achieve without
targeted marketing is to load up on mountains of bland words, but we
systematically ignore those with robinson_minimum_prob_strength set to 0.1.
And they can't even know what our non-bland words are without access to the
database internals.