wp-spamspan

Screenshots

The “wp-spamspan” plugin implements strong, automatic anti-spam protection for email addresses in content on a WordPress site. To spam crawling ‘bots, email addresses appear in obfuscated form. To human visitors, they appear as clickable links. There are two parts to the wp-spamspan process. First, the message text is scanned for email addresses and they are rewritten into an obfuscated form. So, if you have a post that contains the text: chip@example.com This plugin will rewrite that address to display as: chip [at] example [dot] com A ‘bot that harvests email addresses will see this text and won’t be able to extract a usable email address from it. For human users, however, once the page is loaded into the web browser, a Javascript procedure runs that locates the obfuscated email addresses and converts them to clickable “mailto:” links for web browsers. This plugin incorporates spamspan.js, which is licensed and published separately (but bundled into this plugin distribution). The home page for spamspan.js is: http://www.spamspan.com/ Bugs Javascript Assumption The SpamSpan protection would fail against an email harvesting ‘bot that contains a Javascript interpreter. Then the ‘bot would receive the decoded email address, just the way a web browser does. Fortunately, it appears that most (if not all) current email ‘bots don’t handle Javascript. So long as the time and effort of Javascript processing exceeds the benefits of doing so, ‘bot authors won’t have a lot of motivation to add that capability. Naive Email Recognition & Overly Aggresive Obfuscation The mechanism used to identify email addresses to obfuscate is somewhat naive, and at times overly aggressive. For instance, the URL for a shared, public Google calendar is: http://www.google.com/calendar/ical/username@gmail.com/public/basic.ics If I put that text in an article body then wp-spamspan will attempt to convert the email address in the middle of that URL into an obfuscated mailto: link. The workaround is to replace the “@” at-sign with its “@” HTML character entith code, so you’d write the above as: http://www.google.com/calendar/ical/username@gmail.com/public/basic.ics It’s also possible that some complicated-but-valid email addresses may not be recognized, and will appear without obfuscation. Failsafe (Note – this is a theoretical, architectural issue — so don’t let it scare you off.) One of the basic rules of security is that when a protection fails, you want it to fail in a way that makes everything “safe”. In the case of wp-spamspan, that means that if the plugin stops working, you’d like it if the email addresses would still be protected. Unfortunately, that’s not the case. If, for instance, I accidentally twiddle a bit in the administration control panel and disable the wp-spamspan plugin, all of the email addresses on my site will now be exposed to address harvesting spambots. This could be done (by munging email addresses before writing them to the database), but probably not worth it. Plus that has its own set of drawbacks. I don’t anticipate doing anything about this … I just want you to know that I tried to think through the disaster and attack scenarios for this plugin.