Hide Email Address from Bots - Keep mailto:

tl;dr

Hide email address from bots without using scripts and maintain mailto: functionality. Method must also support screen-readers.

Summary

• Email obfuscation without using scripts or contact forms

• Email address needs to be completely visible to human viewers and maintain mailto: functionality

• Email Address must not be in image form.

• Email address must be "completely" hidden from spam-crawlers and spam-bots and any other harvester type

Desired Effect:

• No scripts, please. There are no scripts used in the project and I'd like to keep it that way.

• Email address is either displayed on the page or can be easily displayed after some sort of user interaction, like opening a modal.

• The user can click on on the email address which in turn would trigger the mailto: functionality.

• Clicking the email will open the user's email application.

  In other words, mailto: functionality must work.

• The email address in not visible or not identified as an email address to bots (This includes the page source)

• I don't have an inbox that's full of spam

What does NOT Work

• Adding a contact form - or anything similar - instead of the email address

  I hate contact forms. I rarely fill up a contact form. If there's no email address, I look for a phone number, and if that's not there, I start looking for an alternative service. I would only fill up a contact form if I absolutely have to.

• Replacing the address with an image of the address

  This creates a HUGE disadvantage to someone using a screenreader (please remember the visually impaired in your future projects)

  It also removes the mailto: functionality unless you make the image clickable and then add the mailto: functionality as the href for the link, but that defeats the purpose and now the email is visible to bots.

What might work:

• Clever usage of pseudo-elements in CSS

• Solutions that make use of base64 encoding

• Breaking up the email address and spreading the parts across the document then putting them back together in a modal when the user clicks a button (This will probably involve multiple CSS classes and the usage of anchor tags)

• Alterting html attributes via CSS

  @MortezaAsadi gracefully brought up the possibility in the comments below. This is the link to the full - The article is from 2012:

  What if We Could Use CSS to Alter HTML Attributes?

• Other creative solutions that are beyond my scope of knowledge.

Similar Questions / Fixes

• JavaScript: Protect your email address by Joe Maller

(This a great fix suggested by Joe Maller, it works well but it's script based. Here's what it looks like;

<SCRIPT TYPE="text/javascript">

  emailE = 'emailserver.com'

  emailE = ('yourname' + '@' + emailE)

  document.write('<A href="mailto:' + emailE + '">' + emailE + '</a>')

</script>



<NOSCRIPT>

  Email address protected by JavaScript

</NOSCRIPT>

• Looking for a php only email address obfuscator function

  (A Clever solution using both PHP and CSS to first reverse the email using PHP then reverse it back with CSS) A very promising solution that Works great! But it's too easy to solve.

• Is it worth obfuscating email addresses on the web these days?

  (Javascript fix)

• Best way to obfuscate an e-mail address on a website?

  The selected answer works. It actually works really well. It involves encoding the email as html entities. Can it be improved?

  Here's what it looks like;

  <A HREF="mailto:
  
  &#121;&#111;&#117;&#114;&#110;&#097;&#109;&#101;&#064;&#100;&#111;&#109;&#097;&#105;&#110;&#046;&#099;&#111;&#109;">
  
  &#121;&#111;&#117;&#114;&#110;&#097;&#109;&#101;&#064;&#100;&#111;&#109;&#097;&#105;&#110;&#046;&#099;&#111;&#109;
  
  </A>

• Does e-mail address obfuscation actually work?

  (The selected answer to this SuperUser question is great and it presents a study of the amount of spam received by using different obfuscation methods.

  It seems that manipulating the email address with CSS to make it rtl does work. This is the same method used in the first question I linked to in this section.

  I am uncertain what effects adding mailto: functionality to the fix would have on the results.

• There are also many other questions on SO which all have similar answers. I have not found anything that fits my desired effect

The Question:

Would it be possible to increase the efficiency (ie as little spam as possible) of the email obfuscation methods above by combining two or more of the fixes (or even adding new fixes) while:

A- Maintaining mailto: functionality; and

B- Supporting screen-readers

Edit:

Many of the answers and comments below pose a very good question while indicating the impossibility of doing this without some sort of js

The question that's asked/implied is:

Why not use js?

The answer is that I am allergic to js

Joking aside though,

The three main reasons I asked this question are:

• Contact forms are becoming more and more accepted as a replacement for providing an email address - which they should not.

• If it can be done without scripting then it should be done without scripting.

• Curiosity: (as I am in fact using one of the js fixes currently) I wanted to see if discussing the matter would lead to a better way of doing it.

Solution 1:

The issue with your request is specifically the "Supporting screen-readers", as by definition screen readers are a "bot" of some sort. If a screen-reader needs to be able to interpret the email address, then a page-crawler would be able to interpret it as well.

Also, the point of the mailto attribute is to be the standard of how to do email addresses on the web. Asking if there is a second way to do that is sort of asking if there is a second standard.

Doing it through scripts will still have the same issue as once the page is loaded, the script would have been run and the email address rendered in the DOM (unless you populate the email address on click or something). Either way, screen readers will still have issues with this since it's not already loaded.

Honestly, just get an email service with a half decent spam filter and specify a default subject line that is easy for you to sort in your inbox.

<a href="mailto:[email protected]?subject=Something to filter on">Email me</a>

What you're asking for is if the standard has two ways to do something, one for bots and the other for non-bots. The answer is it doesn't, and you have to just fight the bots as best you can.

Solution 2:

Defeating email bots is a tough one. You may want to check out the Email Address Harvesting countermeasures section on Wikipedia.

My back-story is that I've written a search bot. It crawled 105,000+ URLs during it's initial run many years ago. From what I've learned from doing that is that web crawling bots literally see EVERYTHING that is text, which appears on a web page. Bots read everything except images.

Spam can't be easily stopped via code for these reasons:

1. CSS & JS are irrelevant when using the mailto: tag. Bots specifically look at HTML pages for that "mailto:" keyword. Everything from that colon to the next single quote or double quote (whichever comes first) is seen as an email address. HTML entity email addresses - like the example above - can be quickly translated using a reverse ASCII method/function. Running the JavaScript code snippet above, quickly turns the string which starts with: your... into... "[email protected]". (My search bot threw away hrefs with mailto:email addresses, as I wanted URLs for web pages & not email addresses.)

2. If a page crashes a bot, the bot author will tune the bot to fix the crash with that page in mind, so that the bot won't crash at that page again in the future. Thus making their bot smarter.

3. Bot authors can write bots, which generate all known variations of email addresses... without crawling pages & never using any starter email addresses. While it may not be feasible to do that, it's not inconceivable with today's high-core count CPUs (which are hyper-threaded & run at 4+ GHz), plus the availability of using distributed cloud-based computing & even super computers. It's conceivable that someone can now create a bot-farm to spam everyone, without knowing anyone's email address. 20 years ago, that would have been incomprehensible.

4. Free email providers have had a history of selling their free user accounts to their advertisers. In the past, simply signing up for a free email account automatically guaranteed them a green light to start delivering spam to that email address... without ever using that email address online. I've seen that happen multiple times, with famous company names. (I won't mention any names.)

5. The mailto: keyword is part of this IETF RFC, where browsers are built to automatically launch the default email clients, from links with that keyword in them. JavaScript has to be used to interrupt that application launching process, when it happens.

I don't think it's possible to stop 100% of spam while using traditional email servers, without using filters on the email server and possibly using images.

There is one alternative... You can also build a chat-like email client, which runs internally on a website. It would be like Facebook's chat client. It's "kind of like email", but not really email. It's simply 1-to-1 instant messaging with an archiving feature... that auto-loads upon login. Since it has document attachment + link features, it works kind of like email... but without the spam. As long as you don't build an externally accessible API, then it's a closed system where people can't send spam into it.

If you're planning to stick with strictly traditional email, then your best bet may be to run something like Apache's SpamAssassin on a company's email server.

You can also try combining multiple strategies as you've listed above, to make it harder for email harvesters to glean email addresses from your web pages. They won't stop 100% of the spam, 100% of the time... while also allowing 100% of the screen readers to work for blind visitors.

You've created a really good starting look at what's wrong with traditional email! Kudos to you for that!

A good screen reader is JAWS from Freedom Scientific. I've used that before to listen to how my webpages are read by blind users. (If you hear a male voice reading both actions [like clicking on a link] & text, try changing 1 voice to female so that 1 voice reads actions & another reads text. That makes it easier to hear how the web page is read for the visually impared.)

Good luck with your Email Address Harvesting countermeasure endeavours!