I know this topic has been addressed time and again in this thread, but I wanted some expert opinions on a specific tool from Notepad.com they call the “Web E-Mail Cloaker.”
It offers two ways to “cloak” an e-mail address for a site: the simple method uses HTML special characters to turn a standard e-mail addy into gibberish, but still displays the e-mail address on the site. The more advanced method uses some simple JavaScript. They bill the tool as an alternative to server-side forms. (I know server-side contact forms are the best method for foiling spammers. This is not going to be a “as good as” option, no matter how effective.)
My question is pretty basic: since both methods still display the e-mail address on the site, and allow the addy to be clicked to send a message, doesn’t that pretty much render the tool’s “cloaking” attempts null and void?
From what I understand, it will help to some extent, but not stop all spam. As long as people have access to the email address in some form, there will be those who abuse it.
Stephen, it’s all client-side. So the upshot is that it’s better than nothing, but not anywhere near a perfect solution? That’s what I thought. Thanks, guys.
To be honest, I don’t see a reason to try and cloak your email account, what I do is have filters set in my email and strong spam protection to help reduce the amount of pollutants. If you really want a safe way for people to email, then your best bet is to have a form with server-side script in place.
No - since the spammers can easily decode any client side coding you apply and some of your genuine visitors may not (such as those without JavaScript available) it is actually worse than doing nothing to try to encode the address client side.
Have you considered using a php form for users to send email to your desired email address? The benefits are:
The spammer doesn’t know your email address as they don’t know the email address within the server app.
You can control Spam attacks by putting delays or throttle rates of spam (control spam repeaters)
They are generally easy to use and to validate (server-side validation)
Can perform reverse dns checks to heavily reduce spammers spoofed email.
The cons are:
A lot more overhead
Some expertise in a server-side language is needed (ie. php, .Net, or Java)
Not as flexible or natural as a user having their own email client.
There is an open source package called Swift Mailer. It is very well document and as far as these things go, it is very easy to understand and implement a simple email form.
Don’t know if this helps at all, but I use this technique on all of my sites and do not get any spam, or malicious attacks.
Using part plain-text and part NCR does slow down the code harvester but doesn’t stop them it is better than just a plain formatted mailto link as they would have to write an algorithm to analyse the string and in most cases (as they are usually lazy) isn’t worth their while converting NCR back, e.g. & back into @ and so forth.
The JavaScript only version leads to accessibility issues if the user-agent does support the scripting language or has it blocked.
There’s a cute method listed here, which I wouldn’t use myself, but I still like the idea. Basically, the email address is written backwards, and then is visually reversed via the css direction: rtl; declaration. E.g.
Server side solutions are not that difficult. I can pull up my C# code, if that will help, it’s also posted on my website. It needs to be tailored to your webhost and mail server, but there is nothing particularly complicated, and… here is the important part… while there is more setup overhead than writing “mailto…”, the maintenance overhead you save day in day out makes it a no-brainer.
Just remember that spammers can view web pages themselves to see email addresses displayed there. They don’t always use automated software to capture the addresses. By doing that they can beat any client side “solution”. Alternatively they mak pay someone a dollar or two per thousand email addresses that were “protected” in a way that required someone to actually look at the page to see it.
I too am willing to turn my php server side solution into a template and share the code here in a way that a non-phper can understand.
If interested let me know. Once an email form is protected against a cross-site scripting attack or sql injection it is very difficult for a spammer to abuse a server-side method.
Spammers can still use the form to send you spam when you use a server side approach however you can then update your processing to be able to identify and block their spam. You can’t do the same with a client side solution because once they have your address, nothing you change will affect them because they already have the address.
Spammers can still use the form to send you spam when you use a server side approach however you can then update your processing to be able to identify and block their spam…
The server side approach I use does a reverse DNS lookup and effectively deals with email spoofing. Like I earlier mentioned it also controls the rate of posts, which picks of unnaturally rates of posted emails.
I still get the odd spammed email; however very manageable.
Steve, anything you’d care to share would be greatly appreciated. Same for your code, CMaster, though God knows what I would do with a C++ snippet. Cry, maybe.
If you want a form and PHP form2mail script solution then it is simply a matter of adding the destination email address in the form2mail script itself. I have a couple of them at http://www.felgall.com/php2.htm where the free one has the default to email address assigned in the config. If you need to be able to send to different addresses then it also allows the parts before and after the @ to be specified separately so that only one half of the address needs to be in the HTML The more advanced version that I sell also allows a simple CAPTCHA to be included in the form as well as being able to limit the number of links allowed in the email content.
I wouldn’t touch CAPTCHA with a barge pole, it’s the most accessibility crippling function on the Internet to date. Unfortunately the technology works in a catch22 situation… the easier it is for end users to decode and repeat, the easier it is for spammers, therefore it has to have all sorts of degrading attached to try and obscure the characters. And this distortion ensures that many disabled people will never be able to correctly identify the content. Therefore, if your CAPTCHA isn’t almost entirely violatory of accessibility, it’s pointless even having it on the page as all the spam bots know how to crack it.
Man, I must be disabled, because that describes my situation a lot of the time. I was trying to buy tickets online last weekend, and each time I tried to click on an event, I had to complete a captcha first, and half of them I just couldn’t get. Very annoying.
Actually, what’s scary is that due to bots becoming ever increasingly clever at decrypting CAPTCHA’s (their even using AI, optical character recognition, speech recognition, etc), the need to make things tougher to crack makes it go beyond the disabled into the average user… some of those things are impossible even for the most literate of us to comprehend. It’s a losing battle where the spammers invest billions of dollars (mostly money earned through fraud, scams or legitimate earnings through heavy spam - as CAPTCHA cracking is critical to their finances) and the only people who are working on CAPTCHA are the general community of developers who are either in education (such as University funding) or the open source community… no competition, the spammers keep winning.
Although there are performance drawbacks using reverse DNS for emails, IMHO the benefits out-way the drawbacks. Reverse DNS helps squeeze out many spammers who are not willing to use their real email address so they spoof one instead. Even if bots try spamming, only the legit (if they use any) email addresses are passed.
