Re^2: (OT) Fighting spam (naive, but not *that* naive)

You may think about Paul Graham whatever you want, but he's not that stupid. I am continuously surprised that people don't seem to get how and why Bayesian filtering is works so effectively for old-fashioned (more on that in a bit) spam.

Let me ask once more: how likely do you deem "M0n-stur" to be in legitimate mail? How likely is it in spam? And what is the ratio of these probabilities? Now, how likely is "Monster" to be in legitimate mail? How likely is it in spam? And what is the ratio of these probabilities?

Result: "M0n-stur" only appears in mails that are spam. "Monster" appears in mail that is probably around 30-80% spam, depending on your specific mail traffic. This means you do not want to map the variation back to "monster". The presence of a variation is almost a dead give-away of spam.

This is why naive Bayesian filtering works as well as it does for spam so far, despite being naive.

This extreme effectivity of Bayesian filters against obfuscated variations of keywords has prompted spammers to move on beyond variations. They are now circumphrasing, and not mentioning viagra, monster rods or whatever it is they're advertising at all.

I am now occasionally getting mail along the lines of

Subject: I never thought I'd see better days I was really in a bind until I found this, and now I can even afford to live carelessly. Believe me, it works.

There is absolutely nothing in there that any kind of content based filter could pick out, unless it were to actually understand the message.

This is why content based filtering is a dead end. Most of the things you describe will only fool rule based filters; statistical filters, a family of which Bayes is just one member, will pick them up reliably. But they cannot comprehend the message; hence spam such as what I outlined above, and which tachyon and Andy Lester observed as well.

Makeshifts last the longest.

Comment on Re^2: (OT) Fighting spam (naive, but not that naive)

Replies are listed 'Best First'.
Re: Re^2: (OT) Fighting spam (naive, but not that naive) by forrest (Beadle) on Nov 18, 2003 at 03:23 UTC
Result: "M0n-stur" only appears in mails that are spam. "Monster" appears in mail that is probably around 30-80% spam, depending on your specific mail traffic. This means you do not want to map the variation back to "monster". The presence of a variation is almost a dead give-away of spam. Certainly, you don't want to treat "M0n-stur" as equivalent to "Monster", because it's an obfuscated variation. The point of the original poster is that naive Baysian filtering cannot keep up with all the possible variations of "\|V\|()\|\\|STER" whereas a good regex can "see" they're equivalent. This is why naive Bayesian filtering works as well as it does for spam so far, despite being naive. Only if all spammers use the exact same obfuscated text variants of spam keywords. Since there are literally millions of variants, and spammers are now actively trying to defeat Baysian filtering, that seems unlikely. A good regex can, first of all, tell you "this is obfuscated text" which is enough to flag the mail as spam without figuring out what the text is supposed to be. Going further and finding the word which is being obfuscated could help more, and let a string like "\|_33t \|-\|ax0R" pass as a probable joke, while having no tolerance for "\/\|AG.RA" at all. Your last point about stealth spam seems to be on target. However, it points out how we need many tools in our spam-fighting arsenal. One type of content filtering won't do it; and content filtering alone won't do it either. Hopefully we'll have some new weapons soon.	[reply]
Re: (OT) Fighting spam (naive, but not that naive) by jonadab (Parson) on Nov 18, 2003 at 14:02 UTC
Let me ask once more: how likely do you deem "M0n-stur" to be in legitimate mail? Zero, of course. So what? A naive bayesian filter doesn't know that, until you've seen it already in some minimum number of spam messages -- by which time, the spammer has gone on to spell it some other way. The presence of a variation is almost a dead give-away of spam. Yes, but the computer isn't smart enough (certainly naive bayesian filters aren't smart enough) to know which spelling is correct. We can introduce larger and larger dictionaries, but one interesting thing about English is, regardless of how ginormous you make the dictionary there will be many perfectly cromulent words that are non-extant, and in any case how would you program your filter to distinguish innocent misspellings (if, for example, I had written "cromelent" above) from deliberately evasive ones ("monstur", "monstir", "mawnsteur", ...)? Can the filters be made smart enough to know that "/\/\0N-STAR" is probably a deliberate misspelling? Yes, probably, assuming you don't get much legitimate mail that uses 1337 5P33\|< -- and that was my point, or a large part of it. It's not good enough to treat "M()n5terr" as a new word that's never been seen before, filling my inbox with each new variation. Ideally the filter ought to figure out that it's a mangled form of the word "monster", but failing that it at least needs to be treated as a member of a class of words that match a known pattern. The latter is easier than the former, because all it requires is character classes. Actually figuring out which word is the unmangled original requires a very large and continuously updated dictionary, among other things. Though that would be a good thing to work toward, certainly, but the patterns based on the character classes can be built automatically from an existing corpus of mail (given, only, the character equivalence classes, and allowing for some "characters" to be more than one character long, e.g., "/\/\"); whereas, the dictionary would have to be hand-built almost entirely. Furthermore, it's not good enough to assign some probability to "a variation of 'monster'" and be done. I want "monster", or any variation of monster, to have a much higher spam probability when it occurs in close proximity to "rod", or any variation thereof. This gets much more CPU-intensive, of course, but as noted, CPU time is cheaper than bandwidth and much cheaper than hiring a human to filter my mail. `$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/` [download]	[reply] [d/l]

Replies are listed 'Best First'.
Re: Re^2: (OT) Fighting spam (naive, but not that naive) by forrest (Beadle) on Nov 18, 2003 at 03:23 UTC
Result: "M0n-stur" only appears in mails that are spam. "Monster" appears in mail that is probably around 30-80% spam, depending on your specific mail traffic. This means you do not want to map the variation back to "monster". The presence of a variation is almost a dead give-away of spam. Certainly, you don't want to treat "M0n-stur" as equivalent to "Monster", because it's an obfuscated variation. The point of the original poster is that naive Baysian filtering cannot keep up with all the possible variations of "\|V\|()\|\\|STER" whereas a good regex can "see" they're equivalent. This is why naive Bayesian filtering works as well as it does for spam so far, despite being naive. Only if all spammers use the exact same obfuscated text variants of spam keywords. Since there are literally millions of variants, and spammers are now actively trying to defeat Baysian filtering, that seems unlikely. A good regex can, first of all, tell you "this is obfuscated text" which is enough to flag the mail as spam without figuring out what the text is supposed to be. Going further and finding the word which is being obfuscated could help more, and let a string like "\|_33t \|-\|ax0R" pass as a probable joke, while having no tolerance for "\/\|AG.RA" at all. Your last point about stealth spam seems to be on target. However, it points out how we need many tools in our spam-fighting arsenal. One type of content filtering won't do it; and content filtering alone won't do it either. Hopefully we'll have some new weapons soon.	[reply]
Re: (OT) Fighting spam (naive, but not that naive) by jonadab (Parson) on Nov 18, 2003 at 14:02 UTC
Let me ask once more: how likely do you deem "M0n-stur" to be in legitimate mail? Zero, of course. So what? A naive bayesian filter doesn't know that, until you've seen it already in some minimum number of spam messages -- by which time, the spammer has gone on to spell it some other way. The presence of a variation is almost a dead give-away of spam. Yes, but the computer isn't smart enough (certainly naive bayesian filters aren't smart enough) to know which spelling is correct. We can introduce larger and larger dictionaries, but one interesting thing about English is, regardless of how ginormous you make the dictionary there will be many perfectly cromulent words that are non-extant, and in any case how would you program your filter to distinguish innocent misspellings (if, for example, I had written "cromelent" above) from deliberately evasive ones ("monstur", "monstir", "mawnsteur", ...)? Can the filters be made smart enough to know that "/\/\0N-STAR" is probably a deliberate misspelling? Yes, probably, assuming you don't get much legitimate mail that uses 1337 5P33\|< -- and that was my point, or a large part of it. It's not good enough to treat "M()n5terr" as a new word that's never been seen before, filling my inbox with each new variation. Ideally the filter ought to figure out that it's a mangled form of the word "monster", but failing that it at least needs to be treated as a member of a class of words that match a known pattern. The latter is easier than the former, because all it requires is character classes. Actually figuring out which word is the unmangled original requires a very large and continuously updated dictionary, among other things. Though that would be a good thing to work toward, certainly, but the patterns based on the character classes can be built automatically from an existing corpus of mail (given, only, the character equivalence classes, and allowing for some "characters" to be more than one character long, e.g., "/\/\"); whereas, the dictionary would have to be hand-built almost entirely. Furthermore, it's not good enough to assign some probability to "a variation of 'monster'" and be done. I want "monster", or any variation of monster, to have a much higher spam probability when it occurs in close proximity to "rod", or any variation thereof. This gets much more CPU-intensive, of course, but as noted, CPU time is cheaper than bandwidth and much cheaper than hiring a human to filter my mail. `$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/` [download]	[reply] [d/l]