Hide Email Address from Bots - Keep mailto:

Question

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.

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!

Here is an approach that does make use of JavaScript, but with a rather small foot-print. It's also very "ghetto", and generally I would not recommend an approach with inline JS in the HTML except you have an extreme reluctance to use JS, at all.

<a
  href="#"
  data-contact="bGUtZW1haWxAdGhlLWRvbWFpbi5jb20="
  data-subj="QW4gQW1hemluZyBTdWJqZWN0"
  onfocus="this.href = 'mailto:' + atob(this.dataset.contact) + '?subject=' + atob(this.dataset.subj || '')"
  >
  Send an email
</a>

data-contact is the base64 encoded email address. And, data-subj is an optional base64 encoded subject.

The main challenge with doing this without JS is that CSS can't alter HTML attributes. (The article you linked is a "pie-in-the-sky" musing and does not have any bearing on what is possible today or in the near future.)

The HTML entities approach you mentioned, or some variation of it, is likely the simplest option that will have some efficacy. Additionally, the iframe approach is clever and the server redirect approach is pretty awesome. But, all three are vulnerable to bots:

• The HTML entities just need to be converted (and detecting that is simple)
• The document referenced by the iframe might simply be followed
• The server redirect might simply be followed, as well

With the approach outlined above, the use of a base64 encoded email address in a data-contact attribute is very "one-off" – as long as the scraper is not specifically designed for your site, it should work.

Simple + Lot of @ + Editable without tools

<a href="mailto:user@domain@@com"
   onmouseover="this.href=this.href.replace('@@','.')">
   Send email
</a>