Re: Problems with Bayesian filtering

Laird Breyer <[email protected]> Thu, 26 Feb 2004 14:11:58 +1000
Newsgroups gmane.ietf.asrg.filtering
Message-ID <20040226041157.GA31824@ender>
On Feb 25 2004, Justin Mason wrote:

> >IMHO, picking up explicitly on individual spammer tricks is at best a stop
> >gap until a unified way of dealing with those is found.
> 
> Could you expand on what you mean here?

Fair request ;-)

There's a finite amount of information in a message. Part of that
information conveys content, part conveys meta data such as display
and formatting suggestions or other things. 

Bayesian filters generally try to pin down the content by measuring
it against content that's been seen and classified before.
They try to skip the meta data, because the latter doesn't convey 
useful information.

For example, HTML markup is a familiar form of meta data. Does the
paragraph tag convey useful information? No, but it's ubiquitous,
so must be skipped. 

So what many of those spammer tricks we're talking about
are attempting to do is to take advantage of the meta data to confuse
the filters. That's because filters aren't perfect at separating 
meta data from content. 

For example, early filters didn't screen out HTML tags, and the
spammers inserted the bogus ones to transform the content those early 
filters would see.

Presumably, there should come a point where the filters' parsing
technology is so good that it separates meta data from data very
accurately. Then the spammers would be cornered, and have to modify 
their content.

Except that with powerful meta data such as CSS and Javascript, it's
possible to self referentially change the meta data in endless ways.
Who hasn't thought of creating a style sheet where black on white is
turned into yellow on yellow? This is a game the spammers can always 
win by adding layers and layers.

There's a catch with this: complex obfuscation like this means that
the amount of information carried in the meta data grows. 
Content filters ought to be able to pick this up generically, rather
than one obfuscation trick at a time.

Here's a simple idea, for example, just to illustrate the future. I
make no claims of how well it works ;-) : 

When scanning HTML and throwing away tags as usual, make a note of the
amount of text (ie non whitespace characters) found in official meta
data (ie things like SCRIPT tags). The spammer can do his best to
obfuscate what his code really does, but he can't easily hide the
amount of code he needs to write his obfuscated javascript payload.
Information theory imposes a minimum complexity, and reality imposes
a much larger one.

So a content filter will pick up that there's a complicated meta data
structure, without needing to understand what the meta data really does.

Moreover, the entry points for the meta data (SCRIPT tags, javascript
attributes in HTML tags etc.) are well defined in the HTML
specification, so they can be exhaustively monitored.

Then of course the meta data complexity could be compared with that
for legitimate mail. Even if spam and legitimate mail evolves over
time to include more meta data (think ascii -> html messages), 
the added obfuscation by spammers can be detected on average,
because they are simply inserting more instructions for the MUA than 
a typical legitimate mail does.   

And the filter complexity is minimized over time, because it doesn't
look for specific tricks, but general complexity.

Well, I've expanded enough on this. I'm not claiming to have a
workable solution, just an in-principle objection to pursuing tricks
forever ;-)

-- 
Laird Breyer.