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.