Jason Hendriks

nicholaswilson

Hiding email addresses from spammers has a long history. There are some obvious golden goals, like making the process seamless to your visitors, and be practicable to implement. The one that often gets left out is accessibility, but in some areas this is actually a legal requirement.[1]
<h4>The method</h4>
To my knowledge, this plugin implements the best method so far devised. Credit goes to Roel Van Gils for this technique, which he calls Graceful Email Obfuscation.[2] The basic idea is actually very simple: use PHP and JS to hide the address effectively, and make sure the fallback can be used easily by blind or visually impaired users by using a text-based CAPTCHA.
The PHP code takes passed-in emails and generates simply-encoded string using alphabetic characters. It is therefore very hard to imagine what sort of spammer’s parser could possibly detect it. The only way is to load the whole DOM and jQuery to run the decryption routine. As far as we know, no bots go to those lengths, but it adds essentially no overhead if the theme or any other plugins already load jQuery; otherwise a fraction of a second might be added to page load.
<h4>Comparisons with other plugins</h4>
Amazingly, no other WordPress plugins seem to use this method, either offering very little spam protection, or not coping with JavaScript turned off (3-10% of users). <a href="http://www.privatedaddy.com/" rel="nofollow ugc">Private Daddy</a> comes closest, but falls at the last hurdle by offering an image CAPTCHA with no non-visual alternative. Clunky though my first code bash is, it seems to the best available at the moment if accessibility is really important to you (of course, if I did not think that, I would not have written this). There is a similar Drupal plugin.[3]
<h4>Comparisons with other methods</h4>
The most viable alternative methods are:
<ol>
<li>Using images (cf. <a href="http://www.facebook.com/" title="Facebook" rel="nofollow ugc">Visagefolio</a>). This requires typing and is a pain for everyone.</li>
<li>Poor “test [at] example [dot] com” style text replacements provide no protection and annoy users.</li>
<li>Clever things like outputting “moc.elpmaxe@tset” and using CSS unicode rules to reverse it. Unfortunately these cause trouble for the blind and in some browsers make it confusing to copy and paste the link.</li>
<li>Using XML comments or CSS <code>display: none;</code> to remove elements inside the link text. There is still no clickable link, which makes it hard for the blind to use.</li>
</ol>
<h4>JavaScript fallback</h4>
If there is no JavaScript, the user is taken to a page on the site using an empty content box where they are asked a simple text question to check whether they are a human. Basic sums are asked at the moment, though a wider range of questions could be added using the <a href="http://testCAPTCHA.com" rel="nofollow ugc">testCAPTCHA.com</a> service.
<h4>References</h4>
<ol>
<li>See particularly ‘508’ legislation in America.</li>
<li>Original description on <a href="http://www.alistapart.com/articles/gracefulemailobfuscation" title="A List Apart: Graceful Email Obfuscation" rel="nofollow ugc">A List Apart</a>.</li>
<li><a href="http://drupal.org/project/geo_filter" rel="nofollow ugc">Drupal plugin</a></li>
</ol>
Further reading:
<ol>
<li><a href="http://technology.kencarlson.org/general/graceful-e-mail-obfuscation/" rel="nofollow ugc">GEO review</a> by Ken Carlson</li>
<li>Spam obfuscation comparison recommending use of this method for 508 compliance: <a href="http://doteduguru.com/id415-e-mail-obfuscation.html" rel="nofollow ugc">.eduGuru article</a> by Michael Fienen</li>
</ol>
Some notes and future details on <a href="http://www.nicholaswilson.me.uk/2010/04/notes-on-good-email-obfuscation/" rel="nofollow ugc">my site</a>

Graceful Email Obfuscation

Hiding email addresses from spammers has a long history. There are some obvious golden goals, like making the process seamless to your visitors, and b …

Scott Reilly

Obfuscate email addresses to deter email-harvesting spammers, with a focus on retaining the appearance and functionality of email hyperlinks.
“Obfuscation” simply means that techniques are employed to modify email address strings that appear on your site in such a way that bots scraping your site are unable to identify those addresses; however, at the same time those emails addresses should still look and work correctly for visitors, as much as possible.
The plugin allows for use of one or more (or all!) of three techniques for email protection that have proven themselves in the past. While techniques abound for email obfuscation, the three techniques included provide the best balance of email address protection with minimal impact on visitors. You can decide on a technique by technique basis which ones you’d like to employ as some have potential drawbacks. The plugin’s settings page allows you select which techniques to use.
Ultimately, your best bet would be to not publicly expose an email address and to offer a contact form as an alternative means of contact. Or you can just accept that email addresses will get scraped and spammed, and rely on an email service that is good at filtering out spam. But this plugin is here for you if you want to employ the most reasonable means of making email harvesting difficult for your site.
See Filters section for <code>c2c_obfuscate_email_filters</code> for complete list of filters that are processed.
Please read the Details section of this documentation to learn more about the techniques employed.
<h3>Details</h3>
The email obfuscation techniques included in this plugin were chosen for their effectiveness and general applicability with minimal impact on users. I urge you to read about an <a href="https://web.archive.org/web/20180908103745/http://techblog.tilllate.com/2008/07/20/ten-methods-to-obfuscate-e-mail-addresses-compared/" rel="nofollow ugc">experiment</a> performed by Silvan Mühlemann in which he protected email addresses using nine different techniques. He ensured the page containing those email addresses got indexed by Google and then waited 1.5 years. During that time he measured the amount of spam received to each of the email addresses. (Note: this experiment came out a few years after this plugin was originally created, but at this point was conducted over 10 years ago. Its conclusions may not apply as strongly today.)
Three techniques stood out as having received zero spam emails during that time. Two of those three techniques are included in this plugin. The fourth of his techniques is also included even though it did get a very small amount of spam — the technique was still very effective and more importantly does not rely on users to have CSS or JavaScript enabled.
The techniques are as follows. Two are enabled by default. Weigh the requirements against what you’re comfortable requiring of visitors in order for them to see and make use of email addresses you post on your site.
(For all the examples below, assume you have the link <code><a href="mailto:person@example.com">person@example.com</a></code> in your post.)
<h4>Using CSS display:none</h4>
<ul>
<li>
How does it work? Garbage text, wrapped in span tags, is inserted into any displayed email addresses. Using CSS, the text gets hidden so that visitors see the email addresses as intended. Email scrapers don’t typically utilize a CSS engine to help determine how text would look onscreen.
</li>
<li>
Uses CSS? Yes, which means if a visitor does not have CSS enabled, the emails will appear with extra text in them.
</li>
<li>
Uses JavasScript? No.
</li>
<li>
Can visitor copy-n-paste the link from onscreen text without needing to make modifications? Yes (unless they have CSS disabled).
</li>
<li>
Does this protect email addresses appearing in mailto: links and within HTML tag attributes? No.
</li>
<li>
How effective is this? In the aforementioned experiment, no spam emails were received when using just this technique.
</li>
<li>
Example
<pre><code><a href="mailto:person@example.com">person@nullexample.com</a>
</code></pre>
</li>
</ul>
<h4>Replacing the `@` and `.` characters</h4>
<ul>
<li>
How does it work? The <code>@</code> and <code>.</code> characters are replaced with alternative strings, such as <code>AT</code> and <code>DOT</code>, respectively. The exact replacements are configurable on the plugin’s settings page. By default, if you don’t specify custom replacements, the plugin will use entity substitution (<code>@</code> becomes <code>@</code> and <code>.</code> becomes <code>.</code>).
</li>
<li>
Uses CSS? No.
</li>
<li>
Uses JavasScript? No.
</li>
<li>
Can visitor copy-n-paste the link from onscreen text without needing to make modifications? No, though it should (hopefully) be clear to the user what they need to replace.
</li>
<li>
Does this protect emails appearing in mailto: links and within HTML tag attributes? Yes, though if you specify custom replacement strings visitors clicking on a mailto link will have to modify the email address that shows up in their mail program.
</li>
<li>
How effective is this? In the aforementioned experiment, almost no spam emails were received when using just this technique. As a bonus, this technique does not require the support of any particular client-side techniques (CSS or JavaScript).
</li>
<li>
Examples
<ul>
<li>Custom AT and DOT replacements
<ul>
<li><code><a href="mailto:personATexampleDOTcom">personATexampleDOTcom</a></code></li>
<li><code><a href="mailto:person@DELETETHISexample.com">person@DELETETHISexample.com</a></code></li>
</ul>
</li>
<li>Everything encoded (aka hexadecimal HTML entity substitution) 
<a href="mailto:person@example.com" rel="nofollow ugc">person@example.com</a></li>
</ul>
</li>
</ul>
<h4>Changing text direction with CSS (not enabled by default)</h4>
<ul>
<li>
How does it work? The email addresses are sent reversed in the markup. Using CSS, the text gets reversed so that visitors see the email addresses as intended. Email scrapers don’t recognize the emails in their reversed form and don’t typically utilize a CSS engine to help determine how text would look onscreen.
</li>
<li>
Uses CSS? Yes, which means if a visitor does not have CSS enabled, the emails will appear backwards to them.
</li>
<li>
Uses JavasScript? No.
</li>
<li>
Can visitor copy-n-paste the link from onscreen text without needing to make modifications? No, text copied in such a manner will be reversed. However, a right-click -> “copy link/email address” will work properly for linked email addresses.
</li>
<li>
Does this protect emails appearing in mailto: links and within HTML tag attributes? No.
</li>
<li>
How effective is this? In the aforementioned experiment, no spam emails were received when using just this technique.
</li>
<li>
Example:
<pre><code><a href="mailto:person@example.com">moc.elpmaxe@nosrep</a>
</code></pre>
</li>
</ul>
<h4>How it looks</h4>
If all techniques are enabled at once, the resulting obfuscation of the example link above is (for the full effect, view this in the page’s source or the <a href="" rel="nofollow ugc">readme.txt</a> file directly):
<pre><code><a href="mailto:person@example.com">moc.elpmaxenull@nosrep</a>
</code></pre>
However, in your browser it would appear to you as it does prior to obfuscation, and the link for the email would still work. Theoretically, however, spammers would have a somewhat more difficult time harvesting the emails you display or link to in your posts.
NOTE: (Only when using the custom replacement feature will visitors need to modify the email address for use in their email program.)
Links: <a href="https://coffee2code.com/wp-plugins/obfuscate-email/" rel="nofollow ugc">Plugin Homepage</a> | <a href="https://wordpress.org/plugins/obfuscate-email/" rel="ugc">Plugin Directory Page</a> | <a href="https://github.com/coffee2code/obfuscate-email/" rel="nofollow ugc">GitHub</a> | <a href="https://coffee2code.com" rel="nofollow ugc">Author Homepage</a>
<h3>Template Tags</h3>
The plugin provides one optional template tag for use in your theme templates.
<h4>Functions</h4>
<ul>
<li><code>function c2c_obfuscate_email( $text, $args = array() )</code></li>
</ul>
<h4>Arguments</h4>
<ul>
<li>
<code>$text</code> 
Required argument. The text and/or HTML that contains email addresses that you want to be obfuscated.
</li>
<li>
<code>$args</code> 
Optional argument. An array of configuration options, each element of which will override the plugin’s corresponding default setting.
<ul>
<li>encode_everything (boolean) : Encode all characters in the email address using hexadecimal HTML entity substitution?</li>
<li>use_text_direction (boolean) : Utilize CSS text direction technique?</li>
<li>use_display_none (boolean) : Utilize CSS display:none technique?</li>
<li>at_replace (string) : String to use in place of <code>@</code> in email addresses (used only if encode_everything is false)</li>
<li>dot_replace (string) : String to use in place of <code>.</code> in email addresses (used only if encode_everything is false)</li>
</ul>
</li>
</ul>
<h4>Examples</h4>
<ul>
<li>
Basic usage. Obfuscate email addresses in $text according to current plugin settings.
</li>
<li>
Override all plugin default settings when obfuscating email addresses in $text and just use text direction technique.
 true, ‘use_display_none’ => false, ‘encode_everything’ => false, ‘at_replace’ => ”, ‘dot_replace’ => ”) 
) ); ?>
<h3>Hooks</h3>
The plugin exposes one filter for hooking. Typically, code making use of filters should ideally be put into a mu-plugin or site-specific plugin (which is beyond the scope of this readme to explain).
</li>
</ul>
c2c_obfuscate_email_filters (filter)
The ‘c2c_obfuscate_email_filters’ filter allows you to customize what filters get processed for email obfuscation. The following filters are all filtered by default:
<ul>
<li>link_description</li>
<li>link_notes</li>
<li>bloginfo</li>
<li>nav_menu_description</li>
<li>term_description</li>
<li>the_title</li>
<li>the_content</li>
<li>get_the_excerpt</li>
<li>comment_text</li>
<li>list_cats</li>
<li>widget_text</li>
<li>the_author_email</li>
<li>get_comment_author_email</li>
</ul>
Arguments:
<ul>
<li>array $filters : the default array of filters</li>
</ul>
Example:
<pre><code>/**
 * Also obfuscate emails appearing in custom field values.
 *
 * @param array $filters Filters that get filtered to obfuscate email addresses.
 * @return array
 */
function change_c2c_obfuscate_email_filters( $filters ) {
 $filters[] = 'the_meta';
 return $filters;
}
add_filter( 'c2c_obfuscate_email_filters', 'change_c2c_obfuscate_email_filters' );
</code></pre>

Obfuscate Email

show definitely no effect, either on ajax-loaded content nor on simple wordpress pages...

no effect

Obfuscate email addresses to deter email-harvesting spammers.

Graceful Email Obfuscation vs Obfuscate Email