The algorithm is so good that there are almost no false positives, and together with a decent spam plug-in like Akismet or Spam Karma 2, you’re blog will be forever clean. But it has a problem with Opera. Most builds of Opera trigger a false alarm, leaving your blog reader-less, especially with the release of Opera 9, an excellent browser in all rights, but there is a solution.

1. Download and extract Bad Behavior
2. Open ./bad-behavior/common_tests.inc.php
3. Comment out the code beginning from line 57 to line 60 (inclusive). It should look like this when you’re done:
   [sourcecode lang='php']/*
   if (array_key_exists(’Te’, $package['headers_mixed'])) {
   if (!preg_match(’/\bTE\b/’, $package['headers_mixed']['Connection'])) {
   return “582ec5e4″;
   }
   }
   */[/sourcecode]
4. Save the file, upload the directory to your wp-content/plugins folder, activate, and enjoy!

The Technical Stuff

What we just did is disable “TE Request-Header” checks. TE request-headers are from RFC2616, section 14.39; and although we have no doubt that the authors of this wonderful algorithm had their reasons for including TE request-header checks, and that certain spam bots do indeed employ this particular header-request for TE, as far as we can tell the benefits gained by using such a check are minor.

You can view the entire RFC here. At any rate, it doesn’t matter. Bad Behavior is famous for its excellence and cross compatibility, and lack of false positives, so we feel it should stay that way – without the TE request-header checks. An ideal solution would be to implement this function as a subset of ‘Strict Mode’ which is specially designed to block more illicit traffic, but with the knowledge that it may block some legitimate users.

These messages were sent to random addresses, so whether or not you’re a member here doesn’t matter. Odds are, you won’t receive one of these emails, but we just wanted to make that all clear.

Some background on domain spoofing:

Spammers ‘spoof’ the domains and randomize the aliases (first half of email adresses) to avoid detection & identification, having their own inboxes flooded with complaints, and bounced messages. You can tell if a message really was sent by the domain in question if the SMTP server in the message headers matches their domain’s IP address. Obviously in our case it doesn’t.

Spoofed messages normally won’t get a domain blacklisted – that’s a common misconception. When spammers do their thing, the IP address is blacklisted, not the faked domain name itself. Not only does this keep the colateral damage to innocent victims like us down to a minimum, it also is more effective by getting closer to the originating spam servers too.

So, don’t worry, NeoSmart Technologies hasn’t been bought out by spammers yet, and we’ll continue to do our thing to make sure your private data is safe and sound, and you can count on us not to abuse our position. If you have any idea who actually did the spamming, we urge you contact NeoSmart’s emergency security team at security@neosmart.net as soon as possible.

JavaScript can do a lot of things, but that doesn’t mean it should be used that way. But that’s not the problem – not this time. The problem is that people are still insisting on believing that using JavaScript to hide text means that the bad guys won’t ever see it. But that’s just not true.

For one thing, as we all know, the weapons reach the bad guys first, and it takes a long time for the “good guys” to get them later. Just because GoogleBot and Yahoo! Crawler don’t exactly understand JS-rendered text, doesn’t mean that the spam bots, email harvesters, blog spammers, and more don’t. As a matter of fact, more spam bots come to NeoSmart Technologies with javascript enabled engines than authentic users with JS enabled browsers (stats thanks to SpamKarma 2) – and they’re on your site too.

Just like people insist on writing their emails as ramblings [at] neosmart dot net or one of it’s variations, and it never occurs to them that spambots can harvest these just as well as they can ComputerGuru@NeoSmart.net with or without the mailto: entity defined, it just doesn’t matter. It takes the code masters over at HiveLogic a month or more to write such a complicated algorithm, but it takes spam bot and email harvester authors mere hours to add JS processing to their engines – and all of a sudden everyone is vulnerable.

There really is no good way to prevent an email address from being listed in spam directories and sold in bulk along with thousands of others to spammers around the web – especially not image renders of email addresses, OCR is actually a rather practical method once combined with baesian filters to identify a likely email-in-image target. The best thing one can do is to sign up for a good email service if you use free webmail (don’t use AOL, Hotmail, Walla, WowMail, SpyMac, or most others; use Yahoo!, Live.com, or GMail if you have to), or if you have your own MX server, invest in a quality spam-control engine (don’t use BrightMail or anything else Symantec!). If it’s too late to change whatever it is that you picked or your email address is all over the web such that it doesn’t make a difference, get a decent client-side program instead (reviews to come!).

Remember, you can never beat them completely, just do your best to bat them away. Using disposable email addresses helps, but it’s not the best way since spammers will send messages to random email addresses and bookmark those that don’t bounce back – you really can’t win outright, just keep trying.

However (and this is important!) Hivelogic deserves recognition for their algorithm. I personally used it the month it went public (3 or 4 years ago?), and it was a great idea, the innovation is there, and it definitely worked for a couple of years, but times change and technology swarms and grows, and nothing lasts forever. If you really want security via obsecurity, then this is your award-winning horse that’ll take you quite far, but remember, no one is perfect, and nothing lasts forever.

I've noticed it has a helluva lot more options than Akismet, and at the very least the logic remains on our server and does not await a reply from a heavily-hit server on Automattic's end. We'll see if this does the trick, but we have high hopes!