Forum Moderators: not2easy
What do people use when trying to hide mailto links: javascript or one of the online encoders such as Automaticlabs or the ohlone college website?
Also, when I use either Javascript or one of the encoders, my css styling for the hover state doesn't work. Anyone know how I can get the masked link to perform like the unmasked links?
Cheers
nando
No idea about javascript.
<script language="Javascript">
<!--
var name = "info"
var domain = "yourdomainname.com"
document.write("<a class=link href='mailto:" + name + "@" + domain + "'>")
document.write('Click Here to Email us')
document.write("</a>")
//-->
</script>
I change the variable names "name" and "domain" in each case to minimise the chances of a harvester picking this up. Only the 'Click Here to Email us' part is visible on the page. If you also want to display the actual email address you can do this with a graphic.
For the above sample script, let's say I put it in a separate js file. How do I call it from the link?
Within the <head></head> of your html.
Then you just call the function as if you'd coded it directly on the page:
<script type="text/javascript">doemailaddy()</script>
edit: oh and you'd need to turn it into a function first...
function doemailaddy() (
var name = "info"
var domain = "yourdomainname.com"
document.write("<a class=link href='mailto:" + name + "@" + domain + "'>")
document.write('Click Here to Email us')
document.write("</a>")
)
Would be pretty much it I think, although I tend to make about 1 syntax error per line of code..
Here's one way you could do it. Put this in it's own file (mailto.js):
// Setup namespace to avoid conflicts
var FOTI = window.FOTI ¦¦ {};
/**
* Create a mailto link in your document
* @param {String} container The id of the container for your link
* @param {String} addr The portion to the left of the 'at' symbol
* @param {String} domain The portion to the right of the 'at' symbol
* @param {String} text The text to appear for the link
*/
FOTI.MailTo = function(container,addr,domain,text) {
var n = document.getElementById(container);
if(!n ) return;
n.innerHTML = "<a href='mailto:" + addr + "@" + domain + "'>" + text + "</a>"
};
Next, create your HTML with an element that will contain your link. This could be a <div>, <span>, whatever.
<div id="contactLink">You must have JavaScript enabled to view our contact link.</div>
Finally, create the link when your window loads:
<script type="text/javascript" src="mailto.js"></script>
<script type="text/javascript">
function init() {
// Create mailto link
FOTI.MailTo("contactLink","info","example.com","Contact Us");
}
window.onload = init;
</script>
Note, this forum replaced the pipe character with ¦¦. Be sure to use the correct pipe in your code.
[edited by: Fotiman at 7:10 pm (utc) on Jan. 26, 2007]
Note, it's not recommended to use document.write
Just curious as to why? Do you mean that some bots are smart enough to follow this - even having to parse variables - or is there another reason?
The document.write method provides a way of incorporating strings into the HTML content of the page. There are better ways to do that, such as .innerHTML and .createElement or HTML cloning patterns. Use of document.write should be avoided.document.write is recklessly dependent on timing. If document.write is called before the onload event, it appends or inserts text into the page. If it is called after onload, it completely replaces the page, destroying what came before.
document.write encourages bad structure, in which script and markup are intermingled. A cleaner structure has minimal interaction between markup and script.
Note also that if you're separating your content from behavior (which is good practice), then if you try to attach your behaviors once the page has loaded, you can't use document.write because the page has, well, finished loading.
[edited by: SuzyUK at 11:39 am (utc) on Jan. 27, 2007]
[edit reason] Please no Personal URL's thanks [/edit]
Just a little note.
Here in UK, companies must now display the contact email.
Just a website email form is not allowed.
What that got to do with this?
Well... using js to obscure the link may make you fall foul of accessability laws.
Here in UK, companies must now display the contact email.
Says who?
Says Who?
Apparently, The DTI's Companies Act 2006 [dti.gov.uk], updates came into force on 1st January 2007. I haven't read or digested the whole **PDF FILE** - document [opsi.gov.uk]
this site:
out-law.com [out-law.com] (not sure if this link will stay) has a summary of what it means:
Minimum information to be providedService providers, whether involved in e-commerce or not, should provide the following minimum information, which must be easily, directly and permanently accessible:
- The name of the service provider must be given somewhere easily accessible on the site. This might differ from the trading name and any such difference should be explained – e.g. "XYZ.com is the trading name of XYZ Enterprises Limited."
- The email address of the service provider must be given. It is not sufficient to include a 'contact us' form without also providing an email address.
- The geographic address of the service provider must be given. A PO Box is unlikely to suffice as a geographic address; but a registered office address would. If the business is a company, the registered office address must be included in any event.
- If a company, the company's registration number should also be given.
- If a company, the place of registration should be stated (e.g. "XYZ Enterprises Limited is a company registered in England and Wales with company number 1234567") though this is a requirement of the Companies Act as from 31st December 2006, not the E-commerce Directive.
- f the business is a member of a trade or professional association, membership details, including any registration number, should be provided.
- If the business has a VAT number, it should be stated – even if the website is not being used for e-commerce transactions.
- Prices on the website must be clear and unambiguous. Also, state whether prices are inclusive of tax and delivery costs.
can't find much information on it, or if it's here at WebmasterWorld already
will try to find out the legitimacy of the above quote and maybe move these posts to somewhere more appropriate
Suzy
[edited by: SuzyUK at 12:38 pm (utc) on Jan. 27, 2007]
BeeDeeDubbleU & SuzyUK:
Thanks very much for bringing the legal stuff to our notice! I didn't know this and it's pretty important.
Fotiman:
I can't seem to get your method to work.
Also, will the new bots not pick up on the elements of the email link and be able to reconstruct the email address?
I take it then that no one uses the encoding method?
Cheers
nando
Fotiman:I can't seem to get your method to work.
Could post your code (and/or send it to me via Sticky mail)?
Also, will the new bots not pick up on the elements of the email link and be able to reconstruct the email address?
Assuming the bots don't have a JavaScript parser, no they should not pick up on the email link.
Note, it's not recommended to use document.write
I am not expert enough to comment on this. All I can say is that I have been using the simple method I posted for ages and I have never once known it to malfunction or otherwise cause a problem.
The document.write method provides a way of incorporating strings into the HTML content of the page. There are better ways to do that, such as .innerHTML and .createElement or HTML cloning patterns. Use of document.write should be avoided.
It's not so much that it's going to cause a problem... it's just a messy way of doing things. If you're using document.write, you're doing so before the onload event, which means you've got your HTML markup and JavaScript all intermingled. This encourages bad structure. A cleaner structure has minimal interaction between markup and script.
Separating your content from behavior is good practice and promotes good coding practices.
I accept that your method is best but the poster could not get it to work. It is evidently more complex and all I was saying that the inferior method I use has never let me down, but whatever. ;)
I would say that these days it matters not if you're worried about 'SE bots' - they aren't the problem, if your email is <anybody> or <dictionary word>@domain name then you're going to get the spam eventually - I have recently had 3 x domains come under fire
With a (validated) form you can have that email go to a <non-dictionary word>@<whatever provider you choose> which can also change whenever you choose, you can shut down/apply new form addresses (which you couldn't do quite so easily if you've had to display them publically) and you can also put some client side validation in place - you might still receive the odd spam mail whichever way you choose to do it, but obfuscation will not help any in this scenario
So now if the email address now *has to be displayed* then that sheds a different light on it for the innocents that is :(
you can no longer hide behind that <random string@webmailprovider.com> not that *you* would be trying to hide, it's a case now of just protecting your inbox and trying to cut down on the junk income. No longer is it just SE's we have to worry about
Assuming the bots don't have a JavaScript parser, no they should not pick up on the email link.
whether that parser is set to read alt text or JS, or.., I'm presuming that the outcome will be that folks have to use "whatever they decide is best" type addresses and weed through the junk mail daily just to catch the odd one or 2 real ones - i.e. back to what it was perhaps?
So what is the answer?
<ot> edited for speeling.. and yes I do know about extensions, but my spell checker has suddenly stopped working - just when I was getting used to it</ot>
[edited by: SuzyUK at 10:23 pm (utc) on Jan. 29, 2007]
IMHO, and I have never used JS obfuscation...
Just for clarification, I don't believe anyone here is proposing JS obfuscation. Though I suppose using JavaScript to write out your mailto links might be interpretted by some to mean obfuscation, "JavaScript Obfuscation" generally refers to changing code variable/function names to be unreadable, or at least very difficult to understand. Just wanted to make that clear before moving on. :-)
... if your email is <anybody> or <dictionary word>@domain name then you're going to get the spam eventually
Good point.
Assuming the bots don't have a JavaScript parser, no they should not pick up on the email link.
Remember.. never ASSuME
I don't disagree with you. The point I was going to make (but forgot to follow up on) was that whether you use document.write or some other JavaScript method to write out your mailto links would be pointless if bots have JavaScript parsing capabilities.
who cares if the SE's(bots) can read them or not, it's the harvesters(bots) the smartest, and most annoying of which are just about guaranteed to have JS parsers - that would my gripe!whether that parser is set to read alt text or JS, or.., I'm presuming that the outcome will be that folks have to use "whatever they decide is best" type addresses and weed through the junk mail daily just to catch the odd one or 2 real ones - i.e. back to what it was perhaps?
So what is the answer?
<ot> edited for speeling.. and yes I do know about extensions, but my spell checker has suddenly stopped working - just when I was getting used to it</ot>
? You need more than a spell checker to make this last bit human readable. :-) I couldn't quite follow what you were saying there.
As for what's the answer, I guess it depends on what the question is? If we think that using JavaScript to create mailto links will no longer fool the spam bots from finding our mailto links, then perhaps the image solution might be what's needed (but then how do you handle accessiblity?)
The point I was going to make (but forgot to follow up on) was that whether you use document.write or some other JavaScript method to write out your mailto links would be pointless if bots have JavaScript parsing capabilities.
Absolutely and I am sure that this will happen eventually, because if nothing else the people who do this are very clever. What I can tell you is that I have been using this type of obfuscation on a couple of sites for about a year and they are still spam free.
The spammers will probably not go to the effort of coming up with a method of beating this until there are enough people using it to justify it. There are plenty of email addresses to be harvested out there without worrying about the few who slip through the net using methods like this.
The spammers will probably not go to the effort of coming up with a method of beating this until there are enough people using it to justify it.
FWIW I think that's probably true
Fotiman,
What I mean is if it did come that harvester bots could could parse both simple JS AND the ALT text on images, it would put those who have to display their addresses in a vulnerable position.
They would then have to go back to trawling their junk to catch maybe one or two real web based queries
One solution might be to set up a disposable gmail/yahoo address or something that goes through a ready made filter first in order to weed out obvious rubbish, but it's not very professional to display a 'non company' domain email.
I agree that JS is probably the way to go for now, in a separate file at that too, was just thinking out loud.
What about Character Entity encoding, does anyone use that or is that too easily parsed?
What I mean is if it did come that harvester bots could could parse both simple JS AND the ALT text on images, it would put those who have to display their addresses in a vulnerable position.
Ok, I follow you now.
Ultimately, I think it will be extremely difficult to have a solution that is both accessible AND spam free.
I think it really depends on the details of the previously mentioned law (which I know nothing about, and which doesn't apply to the U.S.). My initial thought is that it's a foolish law, but that's only based on the obvious doors it opens for spammers.
What about Character Entity encoding, does anyone use that or is that too easily parsed?
appi2:
Thanks for originally bringing up the new law here in the UK.
So the problem after one has made it difficult for the spam bots is to make it easy for the users.
I hate it when I don't see a copyable email address on a site.
info(at)domain.com doesn't quite do it.
An image might satisfy the relevant law, as Suzy and RedTCat have suggested, but not much help if someone wants to copy the address into an email program (e.g. they're at work and don't want to use their works email program).
Fotiman: Ultimately, I think it will be extremely difficult to have a solution that is both accessible AND spam free...
Cheers
nando
details of the previously mentioned law (which I know nothing about, and which doesn't apply to the U.S.).
From Out-Law
A qualifications body discriminated against a blind systems manager when it failed to make its computer-based exam accessible to her. The tribunal ruling is the first to find a US company with no presence in the UK liable under the UK's Disability Discrimination Act.
[out-law.com...]
Fotiman: Ultimately, I think it will be extremely difficult to have a solution that is both accessible AND spam free...
Is this where we're at then?
I'm not sure we're there quite yet. That is, I don't *think* that today's spam bots have JavaScript capabilities. But not knowing anything about how these bots operate or where they come from, it's hard to know for sure.
appi2, very good point. I agree with you entirely.
