Hiding e-mail address with php

[donecweb]

I thought spiders can't read things on the page that are there due to being there via PHP includes. If this is true then why not use a PHP include to hide your e-mail address.

[Sharron]

I thought spiders can't read things on the page that are there due to being there via PHP includes. If this is true then why not use a PHP include to hide your e-mail address.


huh? I'm not aware of that. Once a web page in live, the text that is delivered to a web page via the php code then becomes text in a html format

Just go to any site like JWJ's and view the source code. You won't see any php code, but you will see the results of the code.

[Car Guy]

I found a simple javascript to stop email harvesting.

<SCRIPT TYPE="text/javascript">
<!--
emailE=('xxx@' + 'xxx.com')
document.write('<A href="mailto:' + emailE + '">' + emailE + '</a>')
//-->
</script>

Just replace the "X"s with your email address, and paste into your page code.

Richard

[webado]

I thought spiders can't read things on the page that are there due to being there via PHP includes. If this is true then why not use a PHP include to hide your e-mail address.

php code is not displayed so not read.

But for anything to be a page, it has to be produce html - that's what's read.

If you want to use mailto: that needs to be output as html code.
So that will get seen.

You can have mailto: and no email address, let use fill it out manually. But if you do put out an email address then it's very visible. Unless obfuscated by JavaScript or turned to unicode.

[-=Seth=-]

do you have to have the +

<SCRIPT TYPE="text/javascript">
<!--
emailE=('myemail@' + 'domain.com')
document.write('<A href="mailto:' + emailE + '">' + emailE + '</a>')
//-->
</script>


i tried using css to write the address backward so the harvesters would get the wrong email address, unfortunately when genuine users try to copy and paste it, it comes out backward, not ideal may as well just have a .gif, but i might try your javascript idea

[webado]

Better try this:

http://oyoy.eu/page/jscode/

(scroll down)

[-=Seth=-]

thats a cool little tool

is it possible to Encrypt the email address you use in forms as well

[webado]

Depends how you use the form.

If the form is submitted using mailto: and the email address and the contents of the form, then sure, it's the same as just mailto: alone with the email address that opens the email client.

If the form has an external action script that performs the collection of form data and prepares an email and sends it using server-side mail funcitns, then you don't need to encrypt the email address (cannot do it even). However you should never ever keep the email address of the recipient in the form fields to pass to the action script, let it be coded into the action script itself whihc canot be seen by robots or any users.

[donecweb]

I may be way off here, but I thought bots read the HTML on the server and did not parse the page like a browser does. This would mean they would see the PHP include but would not see the text stored on the server to be placed within the page.

[webado]

Who "they"?

php code is executed on the server and only if it outputs html code (including plain text and javascript) is anything shown in the browser.

Bots read the html code that is OUTPUT by the server the same way it is output to a browser.

Bots like browsers cannot see any php code whatsoever - if they do, the server is badly misconfigured and doesn't work - meaning php is not installed and functional at all.

Look at any of my websites, what evidence of php do you see? none.

Yet every one of my pages is created using several php scripts.

[donecweb]

Who "they"? The bots.

[webado]

Who "they"? The bots.

LOL! Oh yeah, those ;)

[-=Seth=-]

If the form is submitted using mailto: and the email address and the contents of the form, then sure, it's the same as just mailto: alone with the email address that opens the email client.

If the form has an external action script that performs the collection of form data and prepares an email and sends it using server-side mail funcitns, then you don't need to encrypt the email address (cannot do it even). However you should never ever keep the email address of the recipient in the form fields to pass to the action script, let it be coded into the action script itself whihc canot be seen by robots or any users.

i'm not sure i'm guessing its the second one, i just created the form in dreamweaver then inserted the code which the people who rent me my server space gave me, they just call it 'Form to Email,' however if you look at the source code you can see the email address i'm using, and i do have to change the email address every so often because its my biggest source of spam

[webado]

Then I suggest you edit the action script you are using to not use the email address from the html form but rather one that's hard coded in the script itself, and do away with the one from the html form.

Of course I assume you have the action script on your account. If using a third party script then you need to pass it that value.

Encryptin of the email address then might be possible using the mailto obfuscator program which replaces any character string you give it by its unicode equivalent. It might work... but not sure how the action script handles it in that case.

http://www.awes.com/obfuscator/

[-=Seth=-]

wow that seems to work, thanks Christina,

ive changed email addresses for my forms again, hopefully that will cut out a lot of spam, i must admit i'm sitting here grinning at that idea, cheers Chris thats another beer i owe you

[webado]

wow that seems to work, thanks Christina,

ive changed email addresses for my forms again, hopefully that will cut out a lot of spam, i must admit i'm sitting here grinning at that idea, cheers Chris thats another beer i owe you

Seth, I can only at most handle on beer a week :)

But I can invite some friends over to help with the surplus ;)

[-=Seth=-]

thats because Canadian have Molson , come to Europe and by comparison it will be like drinking champagne for ya

[webado]

thats because Canadian have Molson , come to Europe and by comparison it will be like drinking champagne for ya

LOL! Well I prefer light beer, like 4% or less, don't you know? Not ale and nothing like that black Guinness or any bitter stuff.

Ah, just gimme champagne, I'll manage on that ;)

[donecweb]

I just had a thought about fighting spam bots that harvest email addresses. It is multi fold but I don't see why it wouldn't work quite well and give us some revenge. On top of that it validates and works whether Javascript is enabled or not or whether images are enabled or not.

Use an obfuscator for the link and for the text fake email address then use CSS to not show the fake email address of the text. Example:
<a href="mailto:%79o%75%72%65%6D%61il@%65%6D%61il%73%65r%76 ic%65%2Eco%6D">youremail@<span class="obfuscateinternal" style="display : none;">spam@spammail.com</span>emailservice.com</a>

It does register as hidden text but in this case I am thinking that is OK.

[webado]

The trouble is unicode is not that hard for spambots to decode. It's more for human visitors really who peek at the source. Of course if they click the email link they see the true email address in their email client in any case. But harvesting email addresses manualy is not efficient.

I favor using the javascript method but making it an external javascript.

Even email forms, however well secured, will not protect against spam unless you also use CAPTCHA, and make sure your contact/order form does not get into any search engine index from the start.

In some of my email forms I test for usage of a proxy and refuse to accept the message. This has worked fine but verifying if it's a proxy or not is tedious and imprecise.

But I have just about 0 spam to my normal email addresses. I have spam to those email addresses we are supposed to have, on the sites where I have them: postmaster@ and abuse@.

[coombes]

I may be way off here, but I thought bots read the HTML on the server and did not parse the page like a browser does. This would mean they would see the PHP include but would not see the text stored on the server to be placed within the page.

If that were the case the googleability of pages using includes would go right down the toilet.

[donecweb]

I see your point and had not thought of that. Thanks

[donecweb]

Thanks mac_jsn I'll check it out.