The first 2.1 development release of Bad Behavior is now available. It contains a number of new and frequently requested features, and may be appropriate for you. Please review the information given, and if you do not find it appropriate for you, then continue to use the latest 2.0 stable releases.
Who should upgrade?
Users who use Bad Behavior’s whitelisting features, or who customize Bad Behavior’s settings on a platform other than WordPress or LifeType, should upgrade to take advantage of new features offered in this release.
What’s new?
Development of Bad Behavior 2.1 generally follows the roadmap outlined earlier. In this initial release, the following features have been implemented:
Bad Behavior now reads whitelists from a separate file which is preserved through updates. See below for preliminary instructions on using this feature.
On platforms where Bad Behavior cannot store settings in the host platform’s database, Bad Behavior now reads settings from a separate file which is preserved through updates. See below for preliminary instructions on using this feature.
Bad Behavior’s core has been reworked to facilitate testing its core logic. While the actual logic tests have not yet been written, a test mode is available for developers to experiment with. See below for preliminary instructions on using this feature.
Whitelists
Bad Behavior now reads its whitelists from a separate file named whitelist.ini. This file is not distributed with Bad Behavior, so that future upgrades do not disturb the whitelist. This means that anyone who wants to use the whitelist must download the whitelist.ini, customize it, then upload it to their server. Place the whitelist.ini in Bad Behavior’s top level directory (the same directory that contains bad-behavior-wordpress.php, README.txt, etc.).
Note for IPv6 users: At this time, single IPv6 addresses can be whitelisted, but IPv6 networks cannot be. This will be fixed in a future release.
Settings
On some platforms, such as WordPress and LifeType, Bad Behavior stores its settings in the host platform’s database and provides an interface through the host platform for changing the settings. On other platforms, Bad Behavior is not capable of storing its settings in the host platform’s database, either because there is no database, or because the database cannot be used in that way.
On these platforms, Bad Behavior can now read settings customizations from a settings.ini file. This file is not distributed with Bad Behavior, so that future upgrades do not disturb your settings. This means that on those platforms, anyone who wants to customize their settings must download the settings.ini, customize it, then upload it to their server. Place the settings.ini in Bad Behavior’s top level directory (the same directory that contains bad-behavior-wordpress.php, README.txt, etc.). This feature has been implemented for the MediaWiki and generic ports; other platforms will need to implement the feature in their platform connectors before it is available to you.
Testing
Bad Behavior’s core logic now supports “black box” testing. This won’t be of much interest to most people, except that testing will help improve the quality of the product. A test suite is still planned and will be released later.
In addition, Bad Behavior now supports a live “test mode” in which it will not actually block any requests, but will report on whether they would have been blocked. This is fully implemented in the WordPress port; to use it on other ports, the platform connector must provide a method for the platform to report the results. To enable test mode, define a PHP constant BB2_TEST.
Download
The 2.1 development releases will not be offered through the WordPress automatic upgrade facility.
Download this development release of Bad Behavior now! You can install Bad Behavior using the usual installation instructions; there are no special requirements for this release.
Remember to subscribe to the Bad Behavior RSS feed to receive notice when Bad Behavior development updates are available.
Support
This release would not have been possible without the support of people like you who find Bad Behavior valuable enough to make a financial contribution to ensure its further development.
Your contributions ensure that I can continue to devote time to bringing you the features you want, as well as continuing work on making spammers’ lives hell.
Since the first release of Bad Behavior four years ago, tens of thousands of WordPress users have used it to protect their sites from the scourge of link spam. Bad Behavior’s second major release, just a year after the first, was a major redesign that has stood the test of time. Bad Behavior became even easier to port to other web site platforms as well as easier to add new features and block new spam.
Now the design needs a few tweaks. This work will eventually become Bad Behavior 2.2. Today I want to update you on some of the changes Bad Behavior needs and what I’m planning for the 2.2 version.
As I noted with today’s 2.0.32 release, development of the 2.0 branch has been limited to bug fixes and security issues so that I can concentrate development on this new version. The development will take place in versions numbered from 2.1. As a development branch, it won’t be appropriate for everyone, but many of you will be interested in following its progress.
Before I get into the details of the roadmap, there’s something I haven’t talked about in a while and should probably do again. Bad Behavior has been a personal project of mine for almost five years now. It was born out of an incident, a couple of months after I started blogging, where I got my first comment spam. Unfortunately, my first comment spam was followed by 700 more over the space of a few hours. As you can imagine, I was thoroughly pissed. I spent some time looking at anti-spam solutions, but at the time there wasn’t much, and what there was didn’t work all that well. I felt I had to roll my own. A couple of months later, Bad Behavior was born.
I still clearly remember cleaning up after that first incident, and killing link spam has become something of a personal crusade for me. But I’ve learned that I can’t possibly do it all alone. Fortunately this field has grown significantly and there are now a whole lot of smart people working on various aspects of the link spam problem. What Bad Behavior brings to the table is to take that 700 spam attack and allow fewer than one percent to reach your blog. Having to clean out 7 spam from the moderation queue is much easier than cleaning out 700. (This is one reason why I advise using more than one anti-spam solution.)
The main technique Bad Behavior uses to accomplish this is to block bots which scrape your site to get access to your comment forms, login forms and other such forms on your site. Once a bot has the form, it can pass it around a botnet and send dozens of spams to that page from all over the world. Preventing malicious bots from accessing the forms in the first place stops the majority of spam. The remainder is a variety of techniques used to identify poorly coded bots which imperfectly masquerade as legitimate web traffic.
As new spammers start up and new botnets come online, some find themselves already blocked, while others need to be analyzed and updates made to block them, so Bad Behavior will always require continuous development. Often this development is delayed because I have to pay bills. As you may be aware if you’ve been a very long time user, I lost my job in 2005 and since then I have lived on revenue from blogging and paid web consulting work. Therefore I can only work on Bad Behavior when my finances permit.
Today my finances do not permit me to do any further work on Bad Behavior, mainly due to the economic recession. If you want this work to continue, as I’ll outline in the roadmap below, skip your morning latte tomorrow and send me a financial contribution. The amount is blank, so fill in whatever you feel is appropriate.
And if you see any problems with the roadmap, or feel it could be improved, feel free to comment below.
Core Changes
The most important change won’t be visible right away. A design change to the core is needed to enable Bad Behavior to be tested using more rigorous test methods. The earliest 2.1 releases will contain this change and I will write tests for each of Bad Behavior’s existing checks. Before the 2.2 stable release, and going forward, a test will be written for each feature introduced into Bad Behavior, to help prevent obvious and silly bugs which require almost immediate updates to fix, as happened with 2.0.30 through 2.0.32. The test suite which emerges from this work will ship as a downloadable package, so that you can test Bad Behavior yourself. (Thanks to Tony Bibbs for suggesting this change.)
Bad Behavior’s various whitelists will be moved out of the core and into a separate file template, downloaded separately from Bad Behavior. This will allow you to update Bad Behavior without disturbing your personal whitelists. This is currently an issue for all platforms. On platforms which support an integrated administrative page for changing Bad Behavior’s settings, and can store settings in the host platform’s database, the whitelists will be manageable from within the administrative page.
Platform Connector Changes
On platforms which do not support an integrated administrative page for changing Bad Behavior’s settings, and require settings to be placed in the platform connector’s file, these settings will be placed in a separate file, downloadable separately from the platform connector. This will allow for the incorporation of settings for new features without updating the platform connector, or conversely, updating the platform connector without disturbing your settings. This is currently an issue for the Drupal module, MediaWiki extension, and possibly other platforms.
The integrated administrative page will be introduced for more platforms. I had originally intended to write this myself for MediaWiki, whose platform connector I maintain, but the lack of adequate developer documentation had made it virtually impossible. (The documentation seems to have improved greatly since then, so I’m going to make another attempt at it.) I expect that these are going to be highly specific to the platform and that little code can be shared between them. If you maintain a platform connector and need assistance with implementing this, please contact me.
The integrated administrative page will be enhanced to allow more complex searching through the database records. Currently it is not possible to search the records except by manually crafting a URL. In the future the entire database will be searchable and you will be able to mark records and forward them to me for analysis. Due to privacy concerns, records sent to me are kept on encrypted media at all times, used solely for analysis of how to permit or block similar traffic (as appropriate) and destroyed within 90 days. Personally identifying information, if present, is not used. I have done this since the beginning.
The current list of platform connectors needs to be updated; it’s come to my attention that some are out of date or their maintainers have stopped maintaining them. If you are, or want to be, a maintainer for a platform connector, please contact me.
The code which creates the database in a new Bad Behavior installation is currently in the core; however, it properly belongs in the platform connector, since it can vary by platform. For instance, the Drupal module already uses its own code for this, but the WordPress and MediaWiki connectors share the same code. This code will be moved out of the core and split into separate files to facilitate reuse where possible, give a slight performance gain, and enable other platforms to do their own initialization where needed.
I’ve identified several new situations in which it would be useful for Bad Behavior to call back to the platform connector to have the host platform perform some action or another. As a result, the platform connector API, such as it is, will expand. It will remain backward compatible, however, in case some platform does not or cannot implement the complete API.
The porting documentation needs to be greatly reworked and expanded. It doesn’t say much except to look at the existing code and base your work off of it, which is perhaps fine for some experienced programmers, but not for everyone.
Bad Behavior needs to be localized, that is, translated into languages other than English. This is still an open design issue, since each platform handles localization in a completely different manner and requires files containing localized translations to be installed in different places. The most likely solution at this point will involve “language packs” which you will be able to download separately from the core. In addition, people will be needed to help translate Bad Behavior. I will make a separate post when I’m ready to accept translations.
Spam Prevention
The core design change mentioned above, which will allow for improved testing, will also enable some new features which haven’t been implementable before, such as improved whitelisting of search engines. As you may know, Bad Behavior has been using the http:BL service from Project Honey Pot to detect spammers for some time now (if you enabled the feature). The http:BL service also identifies many different search engines and can be used to whitelist them, preventing such issues as the recent blocking of msnbot when it began using a suspicious user-agent string. This feature will be available for testing early in the 2.1 release cycle. The original methods of identifying major search engines will remain in place and be maintained for those who cannot use http:BL.
Speaking of Project Honey Pot, Bad Behavior will allow you to serve spammers honey pots or QuickLinks provided by the service, so that it can catch even more spammers.
A screener which uses JavaScript and cookies to identify legitimate users has been in Bad Behavior since the initial 2.0 release, but proved difficult to implement, as it required calls into the host platform which weren’t always available or didn’t work as expected. This feature has been disabled for years. I will finally revisit this technique, as I think there’s still some value in this approach.
And of course I will continue to kill spammers as they come across my radar screen.
Other
Bad Behavior’s documentation has always been less thorough than I would like. It will have to be revamped. In addition I will have to keep on top of it by writing documentation for new features as the new features are written, rather than afterward. Documentation will also need to be translated, and I will need your help for that. I will make a separate posting when I am ready to accept translations.
On many platforms, users currently have to download the Bad Behavior core, then the platform connector, and then upload them together on their web site. If not done perfectly, this can result in errors, or a completely broken site. Where possible, I plan to have a build system which, upon each release of the core, combines it with the platform connector for each platform, an optional language pack, as well as files such as the whitelist and settings templates mentioned above, creating a single download. This should make installing and updating the software more convenient and less error-prone for users of affected platforms.
Finally, I made a proposal long ago for Bad Behavior to automatically update itself. This is not appropriate for everyone, of course, but it may be useful for people on platforms which don’t provide update facilities for their plugins/extensions. This is still a post-2.2 change, though I want to do some preliminary work to see if it can be done reliably and what might be necessary to accomplish it.
I’ve also probably forgotten a few things. They’ll be announced when I remember them.
Status
Bad Behavior must continue to keep up with spammers as they attempt to adapt and find new ways to post their automated garbage. Historically, keeping up with the spammers has not been that difficult, as there is only so much the spammers can do while maintaining their high rates of spamming. Today, 100,000 or more spams in a single run is not unusual, and one spammer I’ve blocked can send 1,000,000 in a day. Bad Behavior attempts to drive up the cost of link spamming by blocking as many automated spammy requests as possible, forcing the spammers to resort to MUCH slower manual methods, or ideally, give up and find more honest work.
I believe the proposed changes outlined above will make Bad Behavior a much stronger tool for preventing link spam while at the same time making it more accessible to a wider variety of users and web site platforms.
Only one thing remains, and that is to do the work. As I noted before, Bad Behavior is a user-supported project. If you think this roadmap looks good, and want to accelerate Bad Behavior development, your financial contribution will help ensure that I can devote more time to its development and bring it to fruition much faster. Otherwise, I have to spend my time first on consulting and other work which brings in revenue, and that means it will be much longer before you see these features.
I would estimate that all of the above would take me about six months to complete if it isn’t funded. At the same time I think contributions totaling $500 or more would allow me time to complete the majority of the above within a month. I know that a lot of you are having financial trouble due to the economy; so am I. Even if you are unable to send a contribution, please leave your comments so that I know you support Bad Behavior and wish it to continue.
This is also the time to send in feature requests. If Bad Behavior doesn’t do something you would like it to do, please leave a comment. (And remember that feature requests accompanied by a contribution are more likely to be implemented sooner.) Due to a hard drive crash I’ve lost all email that was sent to me before August of this year, and possibly some more recent email as well. If you have emailed me with a feature request recently, and don’t see it included above, please also leave a comment.
Thank you again for your support, and here’s to a future without spam.
P.S. If anyone knows how to deliver electric shocks over the Internet, please contact me. This could be the ultimate spam-prevention feature.
Bad Behavior 2.0.21 has been released. It is a maintenance release and is recommended for all users.
MediaWiki and WordPress users should take note of special upgrade instructions below.
Who should upgrade?
Users who receive significant traffic from the Ukraine should upgrade to fix an issue which may cause users in the Ukraine to be blocked.
All users should upgrade to take advantage of protection from newly identified spambots and malicious bots as well as a new method of spambot detection.
Users who specified the Ukrainian language in their browser settings were mistakenly blocked. This issue has been fixed.
Bad Behavior now incorporates data on harvesters and comment spammers compiled by Project Honey Pot and published through its http:BL service. In order to enable this feature, you must obtain an http:BL access key and provide this key to Bad Behavior in its settings. While the http:BL settings can be fine-tuned to block or allow requests based on the threat level and age of a harvester or comment spammer record, the default settings have been extensively tested and found to block virtually all spammers known to http:BL while allowing all legitimate users, even those that http:BL may have classified as suspicious. This feature obsoletes any other http:BL plugins you may have, and they can be removed.
The Majestic-12 search engine crawler was mistakenly blocked. This block has been removed and a block placed for a malicious bot which pretends to be the Majestic-12 crawler.
The bot used by Attributor, a service which looks for copyright infringement and sends takedown notices, has been identified and blocked.
Several additional spambots have been identified and blocked by user agent.
Support
If Bad Behavior has helped you, please make a financial contribution toward further development. Your contribution ensures that I can prioritize Bad Behavior development. Otherwise I must spend most of my time on other projects which pay the bills. Which is a shame, because I really enjoy making spammers miserable and drying up their revenue streams until it’s more profitable for them to work at McDonald’s than to send spam.
For MediaWiki: Before installing this version of Bad Behavior, manually remove (e.g. using FTP or ssh) any old versions you may have, including the lines added to LocalSettings.php. Then install the new version fresh, following the installation instructions for MediaWiki.
For WordPress: If updating to this version through the automatic updater fails, manually remove (e.g. using FTP or ssh) any old versions you may have installed. Then upload and install the new version fresh, following the installation instructions for WordPress. After doing so, future automatic updates should proceed normally.
For other platforms: No changes to your upgrade procedures should be necessary.
Bad Behavior 2.0.13 has been released. It is a maintenance release and is recommended for all users.
Who should upgrade?
Users of MediaWiki who are seeing spurious blank lines in wiki pages should upgrade. Users of any type of software which receives trackbacks and pingbacks (such as blogs) should upgrade.
A bit of code relating to MediaWiki has been disabled. This code attempted to measure Bad Behavior’s run time and insert it into wiki pages as an HTML comment while they were being rendered. This code inadvertently inserted blank lines into the output and has been disabled until it can be fixed.
MediaWiki users receiving fatal errors regarding wfQuery did not install the extension properly and should consult the installation directions and/or the README.txt file.
A bug in Bad Behavior’s user agent blacklist code caused blacklist matches to become case-insensitive, when they should have been case-sensitive. Among other things, this caused pingbacks and trackbacks sent from WordPress blogs to fail. This has been fixed.
This article applies to the 2.x.x series of Bad Behavior. If you are using a 1.x.x version of Bad Behavior, please update as soon as possible.
One of the two topics I get most frequently is the assertion that Bad Behavior has blocked a legitimate request from an actual user, sometimes even the owner of the blog! Since this seems to come up every so often, I’m going to see if I can help out, and maybe eliminate the need for some of these folks to contact me.
(But before we get started, if you are an AOL user, do not use the built-in AOL browser. Use or something else. And get a real ISP as soon as possible.)
Before doing anything else, ensure that you have the latest version of Bad Behavior. Do not leave a comment or contact me if you have failed to update to the latest version. Too many people have done exactly that. It is your responsibility to know how to install and update software on your own Web site.
The next thing to do is to determine why Bad Behavior blocked you. Bad Behavior will display a short message along with a technical support key and a link to “fix the problem yourself.” Make a note of the technical support key, and then click the link. You’ll be presented with more information on why the request was blocked and several suggestions on how to fix the problem.
If you’ve been blocked from a site, and you aren’t the site administrator, please contact that person first, as they will be able to access records on their web server which will be helpful in solving the problem. Be sure to provide them with the technical support key you received. (If you are trying to access a site from a corporate or government network, you may need to contact the network administrator for your company or government agency to resolve the problem.)
If you are the site administrator, and one of your users was blocked and has contacted you for help, you can go directly to the support page and look up their technical support key yourself. You can use either the 8-character key from your database entries, or the 16-character key shown to users, with or without hyphens. You’ll then see the page that would have been shown to that user.
But you should ensure that your user has already followed the suggestions given on the page. The support page is written with non-technical users in mind, and so those of you who really know what you’re doing probably won’t like it, but it’s been my experience that, excepting the occasional bug in Bad Behavior, almost every actual human being who sees the page is able to fix the problem themselves.
If you’re unable to fix the problem yourself, and you’re the site owner/administrator, get your IP address, or the user’s IP address, log in to your phpMyAdmin, and Search the wp_bad_behavior table for the IP address and the last half of the technical support key (without the hyphen). Export the records from phpMyAdmin in SQL format and send them to me. You do not need to zip them, but it’s OK if you do. Please do not export in any other format but SQL. If you send me a screenshot, a PDF, or even worse, an Excel file, I will curse your name until the end of days, and probably not respond.
A workaround has been placed for a problem with the Clearswift Web Policy Engine. Users behind this proxy server are no longer blocked.
A workaround has been placed for a bug in the LiveJournal OpenID process which Six Apart refuses to fix. Logins using OpenID will no longer fail.
A workaround has been placed for bugs in some versions of Internet Explorer and Safari web browsers which caused them to be blocked after leaving a comment on WordPress. These requests are no longer blocked.
A spam prevention feature was causing users to be blocked from their own blogs when they also subscribed to their own feed, or when they accessed the site with multiple web browsers at the same time; it has been disabled for rework.
The 2.0 series of Bad Behavior will be maintained as a legacy branch, with only bug fixes, false positive fixes and security fixes applied to this branch, if any such fixes are needed. No new checks for spammers will be added.
Shortly I will introduce a “development” 2.1 series on a much shorter development cycle, with days or perhaps even hours between releases. In this branch I’ll be experimenting with new spam prevention features, rolling them out quickly and rolling back quickly in case of actual trouble. I’ll also be rolling out a new packaging method which I’ve discussed previously, that will make Bad Behavior even more platform-independent than it currently is, and allow for the “core” to be updated separately from the “glue” which connects it to your host platform.
Once features prove themselves through development and testing to be stable, they’ll be rolled forward into a “stable” 2.2 series, intended for those users who are averse to the risks of blocking legitimate users or having the occasional crash. While I work very hard to ensure that every release, however labeled, does not crash, and does not generate false positives, things occasionally happen which are outside my control.
This parallel development scheme will help balance the needs of the two primary groups of Bad Behavior users.
The first group needs enterprise-grade code which ideally never blocks a single legitimate request and can quickly be rolled into production environments with a high degree of confidence. The tradeoff is the same as it has always been: to prevent any chance of false positives, Bad Behavior’s stable branch will permit some spam, anywhere from 0.1% to 10%, to pass through, and will require a backup solution such as Akismet. Even so, it will drastically reduce the amount of time and money spent managing spam, especially for deployments of dozens or hundreds or thousands of sites.
To serve this class of users more effectively, I’m also studying the feasibility of offering support contracts for enterprise users of Bad Behavior. Services offered under such contracts might include installation assistance, on-call support, hotfix development and deployment, and per-incident support. If your organization may need such a service, stay tuned for more details in the near future.
The second group, I believe, is the majority of Web sites: those for whom a rare blocked user is merely an annoyance rather than a critical problem, and who have much lower tolerance for spam because they aren’t being paid to manage their own blogs, wikis and forums. As much as possible, Bad Behavior’s development branch will limit spam for this class of users to 0.5% missed. The tradeoff is that you will be asked to do what you already do: to report any problems you encounter, whether they be missed spam or blocked users or plain old crashes.
And for users who would like to have their cake and eat it too, the development and stable versions will be installable side-by-side on the same site, and you will be able to switch back and forth between them at the click of a button.
Finally, prior to the first stable 2.2 release, I will be reworking all of Bad Behavior’s documentation and moving Bad Behavior from its current home to a new site dedicated solely to Bad Behavior. So you all will have to update your feed URLs to the new location soon. (Mailing list readers won’t have to do anything.)
In the meantime, Bad Behavior remains a user-supported project, with all code released under the GNU General Public License. If you find Bad Behavior valuable, please consider making a financial contribution. I develop Bad Behavior in my limited spare time, and every contribution means I can devote more time to its development.
Verizon Wireless EV-DO users are no longer blocked.
Blocked requests will be subject to a two-second delay before a response is sent. (See below.)
Some blackhole lists previously used in Bad Behavior have been scaled back or removed.
The address for the Bad Behavior Blackhole has been added. (See below.)
Some new spambots have been identified and blocked.
In recent days spam attacks have been on the rise, with one especially obnoxious bot delivering requests so fast that some sites have been taken offline by them. While the requests aren’t especially numerous or resource-intensive, the most common software used by Web hosting providers is very inefficient at serving dynamic pages such as PHP-based Web sites. So even a moderate number of requests can take a whole server down, or lead the hosting provider to take the site down before the whole server goes down.
Bad Behavior now counters this by introducing a short two second delay to blocked requests, before the HTTP response is sent. Since most spambots wait for the response before going on to the next request, this should sufficiently slow down most of the overly aggressive spambots and give Web site operators some breathing room. While I would have liked to put in a delay of a minute or more, there remains the slight chance that an actual human being would be blocked, and they should be able to get a response back in a reasonable time.
With respect to realtime blackhole lists, all of the existing lists target e-mail spam, and since spambots who send link spam are almost always also sending e-mail spam through the same servers, these are a fairly effective means of blocking link spam. However, since they target e-mail spam, they also block legitimate users. The primary issue here is that while an IP address may be added to a blackhole list quickly, it is not removed quickly — or at all — once the spam stops. Thus, people with dynamic IP addresses are unfairly blocked because some other customer was sending spam.
Bad Behavior Blackhole, which should go online within the next few weeks, is designed specifically for link spam. It adds IP addresses to its database quickly when actual spam is received, and in addition, drops the IP addresses once the spam stops. This helps prevent dynamic IP customers from being blocked because another user’s computer was sending spam. Once Bad Behavior Blackhole is online, all other realtime blackhole lists will be dropped from Bad Behavior.
As always, if you find Bad Behavior valuable, please consider making a financial contribution. I develop Bad Behavior in my spare time, and every little bit means I have more spare time to devote to its development.
And don’t forget to subscribe to the RSS feed or the mailing list. (They’re the same content.)
In the last two days I’ve seen a tenfold increase in the amount of spam being delivered, both that is being blocked, and isn’t being blocked, by Bad Behavior.
While the spam started around the same time as I released Bad Behavior 2.0.7 yesterday, there doesn’t appear to be any correlation between the two. I inspected a few of the spams and they seem like the same old stuff, just cranked into very high gear.
I’ve personally seen over 3,000 spam attempts in the last day, with over 200 missed. This is spam that Bad Behavior is not yet capable of catching without blocking legitimate users as well.
This is why I have been working on the Bad Behavior Blackhole, in order to identify and block spam by its sources, wherever they are.
The Bad Behavior Blackhole is a feature that, once fully up and running, can identify known sources of blog spam and wiki vandalism and pre-emptively block them without affecting legitimate users.
Unfortunately, time constraints have not permitted me to put in much work on Bad Behavior Blackhole, as I’ve had to work on things which bring in revenue. As I’ve said before, while tens of thousands of people use Bad Behavior, only a few dozen have ever actually contributed back.
If you find Bad Behavior valuable, and you want to see this project up and running sooner rather than later, please contribute to its further development.
About four weeks ago I provided a pre-release copy of Bad Behavior 2.0.6 to a select group of testers in order to evaluate a new method of blocking spam, and it’s proved quite successful at blocking a large chunk of spam. On my testbed it blocked 953 spams and missed about 50. So I expect it to cut the spam flow even further.
I said last month I wasn’t generally releasing it immediately so that I could determine whether it blocked any legitimate users. It did indeed block two people that I know of: one was resolved in moments through the fix-it-yourself link, and the other was myself, while using a Wi-Fi access point. I determined that someone had recently sent spam through the same AP, causing the blockage. It had also caught a third person, before the pre-release, whose computer was actually sending spam at the time.
So I’m releasing 2.0.6 generally. If you received a pre-release copy, this copy is unchanged, and you don’t need to do anything.
A new blocking method using realtime blackhole lists is being used to determine if a post originates from a known spam source, open proxy, etc. GET requests are not screened. Links are provided to blackhole list removal procedures through the fix it yourself link.
As always, if you find Bad Behavior valuable, please consider making a financial contribution. I develop Bad Behavior in my spare time, and every little bit means I have more spare time to devote to its development.
And don’t forget to subscribe to the RSS feed or the mailing list. (They’re the same content.)
When I released Bad Behavior 2, I noted that due to time constraints I was unable to complete everything on the roadmap. Most of that is because spammers have dramatically stepped up their activity in recent weeks and the new version provides greatly improved protection against their attacks. Part of it is that as an unpaid project, I can only devote so much spare time to it.
Now that Bad Behavior 2.0 has stabilized, it’s time to update the roadmap in preparation for the next minor (2.1) and major (3.0) releases.
