![[Home]](/static/logo.png){kind=logo}
Hide e-mail addresses (or other addresses like ICQ numbers or Jabber account names) from automated spiders while keeping them accessible to humans at the same time.
The Wiki engine detects and replaces occurrences of e-mail addresses and of “mailto” links in all generated pages, without making its users care about that task. The addresses are replaced with an obfuscated form that is hard to detect automatically by the spider bots.
Then users don’t need to type “ at “ instead of “@” or “ dot “ instead of “.” when leaving an e-mail address.
It’s important to get this feature adopted fast and widely, so that the spammers can’t cripple online communication any further with their practices.
Simple, transparent kinds of Wiki:NameMangling email addresses, such as <a href = "mailto:username@example.net"> or "My email address is d.cary+wikifeatures@<!-- d.cary@sparkingwire.com -->ieee.org" .
All transparent methods could, in theory, be overcome by sufficiently sophisticated harvesting spiders, but in practice, few – if any – address harvesters understand even the simplest transparent name mangling methods, according to the report "Why Am I Getting All This Spam? Unsolicited Commercial E-mail Research Six Month Report" March 2003.
Using JavaScript encryption (also known as name mangling) of e-mail addresses. Unfortunately, this makes the information unavailable to many valid users (MeatBall:LynxUsers).
This can be overcome by using JavaScript-aware spider, for example by using the SpiderMonkey engine.
Encoding addresses into graphics is a common example. But that is awful for the visually impaired.
Another flavor of Turing test involve an instruction for the human on how to decode the address (e.g. “remove all fruit names”). This requires that the user can find, understand and apply the instruction (but to write to us he already has to know the language, right?) and places some burden on him (but still smaller than when not providing any address at all).
You can hide the e-mail addresses completely, and provide a web-based e-mail client for sending messages. If done properly, this will make the addresses very safe, but there are still some problems.
The users may receive spam posted by wiki spam bots that treat the maling form as just yet another page edit form and try to publish their links.
When the recipient receives that mail, it comes directly from the wiki. How should that person reply? Some protocols:
But all too often people make a typo in their email address, and the reply bounces.
Spiders and Wiki:SpamBots cannot overcome POST <form>s currently (this is first to hide their activity and due to incomplete implementations).
However this allows simply to place a bridge page between the page a mail link originally had to appear and a page noting the the real mail address. That bridge page however requires the client to send a POST request to access the page that really shows up the mail address. (You have to see an example http://erfurtwiki.sourceforge.net/?GuestBook to understand its function).
This is not 100% secure, but can be enhanced by placing some <form> fields and a quiz into the POST form required to access the mail addresses page. Such a quiz of course would require some human intelligence and would be impossible (or too time consuming) to solve for automated programs. Search engine registrations would place an image quiz (“enter the letters from the image here: [ …. ]”) at this place, but there are better ways (without graphics).
Currently however, a quiz is not required and a simple <textarea> (no check) or a <checkbox> does the trick. Bots cannot solve it, because they even refuse to POST, and their authors don’t want to be chased down because they’ve caused havoc by activating POST <form>s all over the net.
Instead of a mailto link, you can put a link to a script that will reply with a 303 redirect with the actual mailto address. This allows users to click on a link and have their mail client appear with the “to” field filled with the address.
Bots will usually ignore redirect replies, especially when they contain a protocol other than the supported http.
Note: this doesn’t work in the Safari browser.
Only show e-mail addresses to the users who are logged in. Mail-harvesting bots are usually much simpler than wiki spam bots (and they are not targeted for a specific site), and thus cannot log in automatically.
| status | wiki engines |
|---|---|
| Implemented | TWiki (???), PWiki2 |
| Developing | - |
| Intend to Develop | - |
| Considering | - |
| Rejected | - |
| status | wiki engines |
|---|---|
| Implemented | ErfurtWiki MoinMoin |
| Developing | - |
| Intend to Develop | - |
| Considering | - |
| Rejected | - |
The ProtectedEmail plugin from ErfurtWiki was also ported to the http://nanoweb.si.kz/ HTTP server. At best there also was an Apache2 port 
MoinMoin displays “normal” mailto: links to users who have logged in (which requires a POST, right?), but Wiki:NameMangling the address for ‘bots and users who have not logged in. See http://moinmoin.wikiwikiweb.de/HelpOnMacros_2fMailTo Unfortunately, it requires users to type in
[[MailTo(Firstname DOT Lastname AT example DOT net)]]
.
I wish MoinMoin and other wiki tried to detect normally-typed email addresses. Then
Many people simply write a mangled version of their email address (see Wiki:NameMangling) on their NamePage. This works with any wiki.
Some people put a picture of their email address on their NamePage. This works with any wiki that supports pictures. (As far as I know, spambots with OCR scanners are still hypothetical. But some people add “noise” to the picture of their email to confuse any spambots with OCR scanners that might be built in the future.)