Is there any reasonable way to allow a human user to click on a link in a web page to have an effect equivalent to a mailto: link but in such a way as to hide the email address from an automated email address harvester bot?
(My site uses PHP if that can be part of the solution. I also use JavaScript. That’s about all the technology I have at my disposal for all practical purposes.)
You could use a form on the webpage and never have to reveal the email address. Have the user input text, subject etc. then send it off with mail(). It’s not the same as a mailto:, but maybe you can use it.
You could somehow set up your server to have temporary one-use e-mail addresses (user00038403703573@example.com) that redirect all incoming mail to a specific address exactly once and then expire. If a certain IP address makes too many requests in an hour, block it. That could be useful or completely useless depending on your needs.
But svrider’s solution is probably the best.
Another off-the-shelf solution is recaptcha’s email protection. The way it works is you put a little blob of script inline in your page which causes your email address to appear in a truncated form, like “john…@example.com”, and when someone clicks the “…” link, they’re forced to solve one of those “decipher a funky picture of text” puzzles (commonly referred to as a “captcha”) before they’re told your whole address.
Of course, you have to trust recaptcha.net enough to give them your email address, but a) they seem to be on-the-level and generally dedicated to the cause of fighting spammers, and b) if you can program, I think it’s conceivable that you could use their APIs to implement your own system which doesn’t require you to send them your address.
ETA: if you blink, you’ll miss it, but the "john…@example.com link on that recaptcha page is actually a working example if you want to see how it would look to people visiting your site.
The best method is to use a web form with sufficient impediments to reduce the chances the form itself is not hijacked as well as protecting the email address. Proper protection requires server interaction. Any user dependent code – and that includes Javascript – can be hijacked.
One of the best out there is the Secure and Accessible PHP Contact Form v.2.0.
I use javascript on my site… Within the html of my web site, I plopped in the code below. I use that code on my contact page as well as other places. I’ve used this method for over a year and I’ve never had a problem with spam sent to that email address.
All you have to do is change the “showlink”, “showname”, and “showhost” variables and it should work for you as well.
<script language=javascript>
<!--
var showlink = "Contact Us";
var showname = "info";
var showhost = "LifeOnRecord.com";
document.write("<a href=" + "mail" + "to:" + showname + "@" + showhost +
">" + showname + "@" + showhost + "</a>")
//-->
</script>
What exactly do you mean by “user dependent code”?
Runs on the client, not the server.
We used to have something similar to that, except the parts of the address were even more obfuscated than that. Can’t really remember the details, but it might have been along the lines of the ‘name’ and ‘host’ variables being expressed in hex codes, and run through a javascript routine that would turn them back into ascii. From there, it’s easy enough to use other cryptocipher techniques.
Of course, as Duckster and Rysto alluded to, these techniques aren’t much good if the email harvesting program runs a full javascript interpreter on your page source - all the instructions for showing the email on the page source have to be available to a web browser, so if the email harvester is capable of browser emulation, it’ll get them. Not sure how many spammers actually do this. Seems likely that if javascript email concealment becomes more popular, it’d be more worth it for the spammers to go through this.
On the other hand, there’s probably no easy way to say which pages might be using javascript email concealment tricks. Are the spammers hurting for processing power? (No, probably they have more trojan hacked computers than they really need.) Well, it’s still a thought.
I used Spam-me-not E-mail Link Obfuscator. Although on my web page I coded the email link and display. Compare what you see with the email link and HTML display.
iGoogle also has a web tool “Nemdil Email Encryption”.
There are trade articles indicating that email obfuscation as you use on you web site was lost to the spammers years ago.
from a March 2003 study..
Do you have something more recent? I’m particularly interested in the HTML obscured in mixed hex and decimal forms.
Another data point: I was getting tons of spam, then changed my email addresses (say, from “info@” to “information@”) simultaneous with implementing JavaScript obfuscation (from sites that provide that free service). My spam went down 90+%. That was over two years ago, and the results hold.
I don’t think it is that the spammers can’t do it - but rather it is like a burglar: there are easier targets, so why spend time trying to circumvent the more-difficult defenses?
No.
None that don’t make it harder for the user to reply to you. And that is not a good thing if you are a business, or an organization seeking volunteers, etc.
You are effectively shifting the burden of dealing with SPAM from yourself onto your user. The morality of that you have to decide for yourself.
Also, none of these really work all that well.
email obfuscation (like “t-bonham(at)scc(dot)net”) is a trivial problem for a harvesting program to handle.
scripts generally have the real email available via ‘view page source’, and deciphering it from there is nearly as trivial as obfuscated emails.
captcha’s are increasingly being read by harvester programs via optical character recognition. Also, there are ‘distributed’ sites set up where humans unknowingly break captcha’s for spammers. (Set up a porn site that is free if you solve a captcha, the captcha is one the spammer hit at a website a few seconds ago, the human solves it, and the spammers program uses their response to answer the captcha protecting the other website.)
web forms are probably the best, but they restrict the responses your user can send to you: they can’t include attachments, etc. Also, it’s outside their email program, so they have no record of emailing you, so no way to lookup your email address if they lose it. Bad idea for a business.
Frankly, you’re going at it backwards, here.
If you don’t want emails, then don’t put your email address on your webpage. If you do want emails, then don’t put these roadblocks in the way of users responding to you!
Instead, put your efforts into a good process on your end for dealing with spam.
You can write your email address as: **cookingwithSPAMgas@whatever.com ** and note that the sender should “remove the spam” to send email. It’s a small extra step for the sender but it will defeat an automated harvester.
Well, if that’s what he means, then that’s wrong: Just because a solution uses javascript doesn’t mean it runs entirely on the client. Look at the recaptcha method I used: it shows you a challenge, submits your response to the server, and if you’re right, the server sends back the email address.
And there’s no reason code that runs entirely on the client can’t be reasonably secure. Here’s an example I made that sends all the secret data to the client, encrypted with a secret key. If you know the key, you can put it in and click Decrypt, and the crypto all runs on the client. The server is not contacted. (The crypto algorithm I am using is TEA in case you’re interested.) I challenge you to get the sensitive data without breaking TEA itself. Not that that’s an impossible feat, but the fact that it’s implemented in javascript is irrelevant. One of the marks of good crypto is that you can know every minute detail of how it works and if you don’t have the key, you’re still out of luck.
ETA: the password for the crypto sample above is “sample” in case you want to try it.
But obfuscating the email address using a method similar to aaelghat’s doesn’t put any additional burden on the user at all, unless that user happens to be browsing without Javascript enabled (and, quite frankly, anyone who tries to browse without Javascript these days is going to run into some pretty big problems early on).
Obviously it won’t block every single email harvester that has been or will ever be written, but it will certainly block some of them–maybe even most of them–and with little or no cost. Any spam that does get through can be dealt with in the usual manner.