Is it worth obfuscating email addresses on the web

2019-01-23 05:36发布

问题:

There are various ways to obfuscate email addresses on the web, but most of them don't work when you need to have a mailto: href.

I generally use name[AT]domain.com, because I think it's fairly obvious to the user what they have to do to get a real email address, but I wonder if there's any benefit to this (as it's easy to automate by a spammer). I'm aware of the services which hide the email address behind a captcha, but to me this is too much work for the user.

So, two questions:

  1. Is there any way that (a) retains the use of mailto: links, (b) will stop spammers and (c) isn't too complicated for non-power users to work out?

  2. Is it worth it? Do we just accept that spammers will find a way round it and just use Gmail?

Edit: I should mention that, in this specific case, I'm talking about the contact email address for the companies whose websites I'm making, on their websites.

回答1:

On websites I maintain, I consider it my duty to protect my user's email addresses. Spam is bad enough, I don't need to make it easy for the spammers.

At the same time, usability demands functional mailto links. My favorite method for achieving this is to use the free SpamSpan technique (at paranoia level 3). It is free, cross-browser, seems effective, and leaves easy-to-read text when JavaScript is disabled.

Sample HTML

<span class="spamspan">
<span class="u">user</span>
[at]
<span class="d">example [dot] com</span>
</span>

Result (JavaScript enabled)

user@example.com

Result (JavaScript disabled)

user [at] example [dot] com



回答2:

IMHO, there's no good reason to obfuscate emails. Spam filtering can be done quite well automatically by third party services so it's not really your or your users problem, yet retrieving a working email is a barrier however small in communication, which is.



回答3:

I doubt that it's ever been worth it. Email obfuscation has been entirely based on second guessing the spammers and imagining what the scrapers will and won't do.



回答4:

Whenever I sign up for a new account, I use a unique email address for that account. I know which sites are bad at giving out my address and which sites keep it confidential, and if an address starts receiving spam I assume the worst about that company (IE, that they've resold my personal info as opposed to lax security allowing it to be seen by a spider).

Your users shouldn't have to take such measures. You should be keeping their personal information as private as possible unless they explicitly ask you to do otherwise.

It's difficult to offer advice as the need to display user information varies from site to site. As a general rule, I would introduce a captcha in the login process, and then only show the email address within a properly marked-up mail-to link to logged in users. For people (and spiders) anonymously browsing your site, I would omit the address entirely rather than display it obfuscated, or disallow them access to whichever pages contain user information.



回答5:

Are the email adresses yours? (your company?) or are those user email adresses.

For user adresses I would use some obfuscation or a login wall. For personal email adresses I would not use any walls but I'd make sure everyone has some sort of spam filter.



回答6:

I just inject the email address via JavaScript.

var e = ["m", "o", "c", ".", "l", "i", "a",
         "m", "g", "@", "s", "m", "a", "i",
         "l", "l", "i", "w", ".", "r", ".",
         "j", ".", "a"];

$(".email").text( e.reverse().join("") );

It's obviously not going to keep out spammers who either manually trawl the web or parse the crawled pages and execute the JavaScript before extracting email addresses, but I doubt many go to that trouble.



回答7:

I would say that it's not worth it. Either the page contains an email address which can be read by a user-agent with permission or it doesn't. Obfuscating it detracts from the semantic value of the web, restricts to specific types of user agents such as those which can execute JavaScript or those which have a UI and a user sitting at that UI.

If you're going to display an email address then you should just display it mailto: and all, go one further and make it part of an hCard, link back to the user's XFN profile page and encourage user agents of the future to use this rich semantic data. Otherwise simply don't display an email address.