[PHP] Email Antispam

Hello,

I'm working on a site that has email addresses on it. I am not wanting
to use mailto links so as to avoid spam harvesters, I'd like another
solution so that mailto links would work but would not work with
spammers. I've tried several javascript-based solutions, but am not
able to get them to be consistent. It seems like once they're used
they revert to coded links. If anyone has any solutions I'd appreciate
it. I'm not sure I can do this in php, generate email addresses
dynamically then pass them to the client, it would be the same as the
spammer hitting the page. I'd prefer something self-hosted and
preferably light on the resources.

Thanks.
Dave.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Is there a reason for you not to build a contact form?

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

"David Mehler" <[email protected]> wrote in message
news:CAPORhP5Cuzd0Hb9gBFLESNe5LofDODN64S2UOAuMWCb=[email protected]..
> Hello,
>
> I'm working on a site that has email addresses on it. I am not wanting
> to use mailto links so as to avoid spam harvesters, I'd like another
> solution so that mailto links would work but would not work with
> spammers. I've tried several javascript-based solutions, but am not
> able to get them to be consistent. It seems like once they're used
> they revert to coded links. If anyone has any solutions I'd appreciate
> it. I'm not sure I can do this in php, generate email addresses
> dynamically then pass them to the client, it would be the same as the
> spammer hitting the page. I'd prefer something self-hosted and
> preferably light on the resources.
>
> Thanks.
> Dave.

Why not just put the contact's name/info on screen and then use the database
behind it all to go get the email address and build the mail? Assuming that
the site is using a db to hold these addresses already.



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Marc Guay <[email protected]> wrote:

>Is there a reason for you not to build a contact form?
>
>--
>PHP General Mailing List (http://www.php.net/)
>To unsubscribe, visit: http://www.php.net/unsub.php

It could be for a company, which in the UK I believe requires several bits of contact information.

There is no php way of doing what you ask, php is all on the server after all. The only solution is javascript, but again, if its for a company, depending on country, you may have a legal requirement to make it accessible, which means basic required details available without script.

Having said that, with a contact form you may be ok. You could use javascript to output the email address link. I wrote one a while back:

http://www.ashleysheridan.co.uk/coding/javascript/Anti-Spam+Email+Script

Hope it helps?

Thanks,
Ash
http://ashleysheridan.co.uk

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

> -----Original Message-----
> From: Jim Giner [mailto:[email protected]]
> Sent: April 17, 2012 4:33 PM
> To: php-general@lists.php.net
> Subject: [PHP] Re: Email Antispam
>
>
> "David Mehler" <[email protected]> wrote in message
> news:CAPORhP5Cuzd0Hb9gBFLESNe5LofDODN64S2UOAuMWCb=[email protected]..
> > Hello,
> >
> > I'm working on a site that has email addresses on it. I am not wanting
> > to use mailto links so as to avoid spam harvesters, I'd like another
> > solution so that mailto links would work but would not work with
> > spammers. I've tried several javascript-based solutions, but am not
> > able to get them to be consistent. It seems like once they're used
> > they revert to coded links. If anyone has any solutions I'd appreciate
> > it. I'm not sure I can do this in php, generate email addresses
> > dynamically then pass them to the client, it would be the same as the
> > spammer hitting the page. I'd prefer something self-hosted and
> > preferably light on the resources.
> >
> > Thanks.
> > Dave.
>
> Why not just put the contact's name/info on screen and then use the
> database behind it all to go get the email address and build the mail?
> Assuming that the site is using a db to hold these addresses already.
>

What about using an AJAX call onclick to pull the email address? Or nesting
ajax calls to hide it more gooder :P

Just thoughts, as I never (almost never) use mailto: tags, and build my own
contact form.

Steve


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

On Tue, 17 Apr 2012 16:04:19 -0400, David Mehler wrote:

>I'm working on a site that has email addresses on it. I am not wanting
>to use mailto links so as to avoid spam harvesters, I'd like another
>solution so that mailto links would work but would not work with
>spammers. I've tried several javascript-based solutions, but am not
>able to get them to be consistent. It seems like once they're used
>they revert to coded links. If anyone has any solutions I'd appreciate
>it. I'm not sure I can do this in php, generate email addresses
>dynamically then pass them to the client, it would be the same as the
>spammer hitting the page. I'd prefer something self-hosted and
>preferably light on the resources.

I don't like this sort of thing, but I have a client who needs it. What
I did for them was to put the email address on the page encoded with
base64, and use client-side script to decode it. i.e. the encoded data
is replaced with the decoded data, once on page load. Hook up the decode
function on the browser-side to your page load scripts. No jQuery
required :)

https://gist.github.com/2409958
--
Ross McKay, Toronto NSW Australia
"All we are saying
Is give peas a chance" - SeedSavers

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

"Ross McKay" <[email protected]> wrote in message
news:[email protected]..
> On Tue, 17 Apr 2012 16:04:19 -0400, David Mehler wrote:
>
>>I'm working on a site that has email addresses on it. I am not wanting
>>to use mailto links so as to avoid spam harvesters, I'd like another
>>solution so that mailto links would work but would not work with
>>spammers. I've tried several javascript-based solutions, but am not
>>able to get them to be consistent. It seems like once they're used
>>they revert to coded links. If anyone has any solutions I'd appreciate
>>it. I'm not sure I can do this in php, generate email addresses
>>dynamically then pass them to the client, it would be the same as the
>>spammer hitting the page. I'd prefer something self-hosted and
>>preferably light on the resources.
>
> I don't like this sort of thing, but I have a client who needs it. What
> I did for them was to put the email address on the page encoded with
> base64, and use client-side script to decode it. i.e. the encoded data
> is replaced with the decoded data, once on page load. Hook up the decode
> function on the browser-side to your page load scripts. No jQuery
> required :)
>
> https://gist.github.com/2409958
> --
> Ross McKay, Toronto NSW Australia
> "All we are saying
> Is give peas a chance" - SeedSavers

So - does that mean you building the site from information contained in a
database?



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

On Tue, 17 Apr 2012 21:11:45 -0400, Jim Giner wrote:

>So - does that mean you building the site from information contained in a
>database?

Yes. Client wanted email addresses on the website, but not available to
SPAM harvesters. And not all addresses are "in the database" as
structured data, many are embedded in page content (I have a WordPress
shortcode that encodes the email address for those).
--
Ross McKay, Toronto, NSW Australia
"Faced with a choice between the survival of the planet
and a new set of matching tableware, most people would
choose the tableware" - George Monbiot

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

"Ross McKay" <[email protected]> wrote in message
news:[email protected]..
> On Tue, 17 Apr 2012 21:11:45 -0400, Jim Giner wrote:
>
>>So - does that mean you building the site from information contained in a
>>database?
>
> Yes. Client wanted email addresses on the website, but not available to
> SPAM harvesters. And not all addresses are "in the database" as
> structured data, many are embedded in page content (I have a WordPress
> shortcode that encodes the email address for those).
> --
> Ross McKay, Toronto, NSW Australia
> "Faced with a choice between the survival of the planet
> and a new set of matching tableware, most people would
> choose the tableware" - George Monbiot

He literally wants the "addresses" visible on the sight? Or just an <a>
using the person's name that would then generate the email by referencing
the data table? This is basic contact form methodology as mentioned by an
earlier post.

As for the missing ones, use that WP thingie to extract them and post them
to a speicifc email addr field in your table.



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

On Wed, 18 Apr 2012 11:08:00 -0400, Jim Giner wrote:

>He literally wants the "addresses" visible on the sight? [...]

Yes, they want the addresses visible and clickable on the website. They
have contact forms, but they also want the email addresses (of their
scientists and other consultants) available to their clients. And they
want the addresses to be shielded against harvesting for spam.

As I said, I don't like doing it this way, but the client gets what they
want after the options have been explained to them.
--
Ross McKay, Toronto, NSW Australia
"Nobody expects the Spanish inquisition" - Cardinal Ximénez

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

On Wed, Apr 18, 2012 at 8:47 PM, Ross McKay <[email protected]> wrote:
> On Wed, 18 Apr 2012 11:08:00 -0400, Jim Giner wrote:
>
>>He literally wants the "addresses" visible on the sight?  [...]
>
> Yes, they want the addresses visible and clickable on the website. They
> have contact forms, but they also want the email addresses (of their
> scientists and other consultants) available to their clients. And they
> want the addresses to be shielded against harvesting for spam.

Ob/Deobfuscation schemes that use javascript are a partial solution.
Many spam harvesters are smart enough these days to know enough about
decoding email addresses even obfuscated with javascript, with or
without the mailto: scheme. Any that do obfuscation by substituting
html entities for the characters are quite easily cracked. (Just
appearance of a string of html entities is often enough to indicate
there is something there to decode.) There is no 100% solution here.
Coming up with clever ways to obfuscate the address on download, and
deobfuscate it afterwards to display to the user will work for a
while, however, the people writing spam harvesters are just as clever
as we are. If the application is going to end up with email addresses
displayed on the screen, some spam harvester is going to be able to
get them. Even if you come up with a method that will stop them now,
it won't stop them forever.

> As I said, I don't like doing it this way, but the client gets what they
> want after the options have been explained to them.

They need to understand the options, but even more important, the
risks of any solution, and of the concept as a whole. After you've
presented the risks, and the lack of a 100% solution, if they still
want to do something against their own policies, you have to decide if
your liability in giving it to them is going to be a problem.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Bastien Koert

On 2012-04-19, at 1:54 AM, tamouse mailing lists <[email protected]> wrote:

> On Wed, Apr 18, 2012 at 8:47 PM, Ross McKay <[email protected]> wrote:
>> On Wed, 18 Apr 2012 11:08:00 -0400, Jim Giner wrote:
>>
>>> He literally wants the "addresses" visible on the sight? [...]
>>
>> Yes, they want the addresses visible and clickable on the website. They
>> have contact forms, but they also want the email addresses (of their
>> scientists and other consultants) available to their clients. And they
>> want the addresses to be shielded against harvesting for spam.
>
> Ob/Deobfuscation schemes that use javascript are a partial solution.
> Many spam harvesters are smart enough these days to know enough about
> decoding email addresses even obfuscated with javascript, with or
> without the mailto: scheme. Any that do obfuscation by substituting
> html entities for the characters are quite easily cracked. (Just
> appearance of a string of html entities is often enough to indicate
> there is something there to decode.) There is no 100% solution here.
> Coming up with clever ways to obfuscate the address on download, and
> deobfuscate it afterwards to display to the user will work for a
> while, however, the people writing spam harvesters are just as clever
> as we are. If the application is going to end up with email addresses
> displayed on the screen, some spam harvester is going to be able to
> get them. Even if you come up with a method that will stop them now,
> it won't stop them forever.
>
>> As I said, I don't like doing it this way, but the client gets what they
>> want after the options have been explained to them.
>
> They need to understand the options, but even more important, the
> risks of any solution, and of the concept as a whole. After you've
> presented the risks, and the lack of a 100% solution, if they still
> want to do something against their own policies, you have to decide if
> your liability in giving it to them is going to be a problem.
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Could this be a place to consider a flash Based solution?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

On Thu, Apr 19, 2012 at 1:01 PM, Bastien <[email protected]> wrote:
>
>
> Bastien Koert
>
> On 2012-04-19, at 1:54 AM, tamouse mailing lists <[email protected]> wrote:
>
>> On Wed, Apr 18, 2012 at 8:47 PM, Ross McKay <[email protected]> wrote:
>>> On Wed, 18 Apr 2012 11:08:00 -0400, Jim Giner wrote:
>>>
>>>> He literally wants the "addresses" visible on the sight?  [...]
>>>
>>> Yes, they want the addresses visible and clickable on the website. They
>>> have contact forms, but they also want the email addresses (of their
>>> scientists and other consultants) available to their clients. And they
>>> want the addresses to be shielded against harvesting for spam.
>>
>> Ob/Deobfuscation schemes that use javascript are a partial solution.
>> Many spam harvesters are smart enough these days to know enough about
>> decoding email addresses even obfuscated with javascript, with or
>> without the mailto: scheme. Any that do obfuscation by substituting
>> html entities for the characters are quite easily cracked. (Just
>> appearance of a string of html entities is often enough to indicate
>> there is something there to decode.) There is no 100% solution here.
>> Coming up with clever ways to obfuscate the address on download, and
>> deobfuscate it afterwards to display to the user will work for a
>> while, however, the people writing spam harvesters are just as clever
>> as we are. If the application is going to end up with email addresses
>> displayed on the screen, some spam harvester is going to be able to
>> get them. Even if you come up with a method that will stop them now,
>> it won't stop them forever.
>>
>>> As I said, I don't like doing it this way, but the client gets what they
>>> want after the options have been explained to them.
>>
>> They need to understand the options, but even more important, the
>> risks of any solution, and of the concept as a whole. After you've
>> presented the risks, and the lack of a 100% solution, if they still
>> want to do something against their own policies, you have to decide if
>> your liability in giving it to them is going to be a problem.
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
> Could this be a place to consider a flash Based solution?

Maybe, though that requires clients to have a flash enabled device.
Since iOS devices still don't support flash, that's not a reasonable
option anymore for me.

In the end, there's no real solution for spam bots, I think that a
good spam filter is still the best option. My mail address is at
several places all over the web, though I hardly get any spam in my
inbox (thanks Gmail!).

- Matijn

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

On Thu, 2012-04-19 at 13:48 +0200, Matijn Woudt wrote:

> On Thu, Apr 19, 2012 at 1:01 PM, Bastien <[email protected]> wrote:
> >
> >
> > Bastien Koert
> >
> > On 2012-04-19, at 1:54 AM, tamouse mailing lists <[email protected]> wrote:
> >
> >> On Wed, Apr 18, 2012 at 8:47 PM, Ross McKay <[email protected]> wrote:
> >>> On Wed, 18 Apr 2012 11:08:00 -0400, Jim Giner wrote:
> >>>
> >>>> He literally wants the "addresses" visible on the sight? [...]
> >>>
> >>> Yes, they want the addresses visible and clickable on the website. They
> >>> have contact forms, but they also want the email addresses (of their
> >>> scientists and other consultants) available to their clients. And they
> >>> want the addresses to be shielded against harvesting for spam.
> >>
> >> Ob/Deobfuscation schemes that use javascript are a partial solution.
> >> Many spam harvesters are smart enough these days to know enough about
> >> decoding email addresses even obfuscated with javascript, with or
> >> without the mailto: scheme. Any that do obfuscation by substituting
> >> html entities for the characters are quite easily cracked. (Just
> >> appearance of a string of html entities is often enough to indicate
> >> there is something there to decode.) There is no 100% solution here.
> >> Coming up with clever ways to obfuscate the address on download, and
> >> deobfuscate it afterwards to display to the user will work for a
> >> while, however, the people writing spam harvesters are just as clever
> >> as we are. If the application is going to end up with email addresses
> >> displayed on the screen, some spam harvester is going to be able to
> >> get them. Even if you come up with a method that will stop them now,
> >> it won't stop them forever.
> >>
> >>> As I said, I don't like doing it this way, but the client gets what they
> >>> want after the options have been explained to them.
> >>
> >> They need to understand the options, but even more important, the
> >> risks of any solution, and of the concept as a whole. After you've
> >> presented the risks, and the lack of a 100% solution, if they still
> >> want to do something against their own policies, you have to decide if
> >> your liability in giving it to them is going to be a problem.
> >>
> >> --
> >> PHP General Mailing List (http://www.php.net/)
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >
> > Could this be a place to consider a flash Based solution?
>
> Maybe, though that requires clients to have a flash enabled device.
> Since iOS devices still don't support flash, that's not a reasonable
> option anymore for me.
>
> In the end, there's no real solution for spam bots, I think that a
> good spam filter is still the best option. My mail address is at
> several places all over the web, though I hardly get any spam in my
> inbox (thanks Gmail!).
>
> - Matijn
>


A Flash solution would also be highly innaccessible, which may make it
impossible to use for certain types of company.

Like Matijn, my email address is on a lot of public forums, so I've
resigned myself to not even attempting to obfuscate my email address on
my website. It's like playing a game of whack-a-mole, there is no real
hope of stopping it being harvested once it's online in a readable form.
If a human can read it, what's to stop a human from adding it to some
"marketing" list?
--
Thanks,
Ash
http://www.ashleysheridan.co.uk

Hello,

Thank you to all who have offered suggestions with this issue. I have
discussed it with the individual I'm working for and a contact form
has been authorized. So, I'm going to go with that option.

Thanks.
Dave.


On 4/19/12, Ashley Sheridan <[email protected]> wrote:
> On Thu, 2012-04-19 at 13:48 +0200, Matijn Woudt wrote:
>
>> On Thu, Apr 19, 2012 at 1:01 PM, Bastien <[email protected]> wrote:
>> >
>> >
>> > Bastien Koert
>> >
>> > On 2012-04-19, at 1:54 AM, tamouse mailing lists
>> > <[email protected]> wrote:
>> >
>> >> On Wed, Apr 18, 2012 at 8:47 PM, Ross McKay <[email protected]> wrote:
>> >>> On Wed, 18 Apr 2012 11:08:00 -0400, Jim Giner wrote:
>> >>>
>> >>>> He literally wants the "addresses" visible on the sight? [...]
>> >>>
>> >>> Yes, they want the addresses visible and clickable on the website.
>> >>> They
>> >>> have contact forms, but they also want the email addresses (of their
>> >>> scientists and other consultants) available to their clients. And they
>> >>> want the addresses to be shielded against harvesting for spam.
>> >>
>> >> Ob/Deobfuscation schemes that use javascript are a partial solution.
>> >> Many spam harvesters are smart enough these days to know enough about
>> >> decoding email addresses even obfuscated with javascript, with or
>> >> without the mailto: scheme. Any that do obfuscation by substituting
>> >> html entities for the characters are quite easily cracked. (Just
>> >> appearance of a string of html entities is often enough to indicate
>> >> there is something there to decode.) There is no 100% solution here.
>> >> Coming up with clever ways to obfuscate the address on download, and
>> >> deobfuscate it afterwards to display to the user will work for a
>> >> while, however, the people writing spam harvesters are just as clever
>> >> as we are. If the application is going to end up with email addresses
>> >> displayed on the screen, some spam harvester is going to be able to
>> >> get them. Even if you come up with a method that will stop them now,
>> >> it won't stop them forever.
>> >>
>> >>> As I said, I don't like doing it this way, but the client gets what
>> >>> they
>> >>> want after the options have been explained to them.
>> >>
>> >> They need to understand the options, but even more important, the
>> >> risks of any solution, and of the concept as a whole. After you've
>> >> presented the risks, and the lack of a 100% solution, if they still
>> >> want to do something against their own policies, you have to decide if
>> >> your liability in giving it to them is going to be a problem.
>> >>
>> >> --
>> >> PHP General Mailing List (http://www.php.net/)
>> >> To unsubscribe, visit: http://www.php.net/unsub.php
>> >>
>> >
>> > Could this be a place to consider a flash Based solution?
>>
>> Maybe, though that requires clients to have a flash enabled device.
>> Since iOS devices still don't support flash, that's not a reasonable
>> option anymore for me.
>>
>> In the end, there's no real solution for spam bots, I think that a
>> good spam filter is still the best option. My mail address is at
>> several places all over the web, though I hardly get any spam in my
>> inbox (thanks Gmail!).
>>
>> - Matijn
>>
>
>
> A Flash solution would also be highly innaccessible, which may make it
> impossible to use for certain types of company.
>
> Like Matijn, my email address is on a lot of public forums, so I've
> resigned myself to not even attempting to obfuscate my email address on
> my website. It's like playing a game of whack-a-mole, there is no real
> hope of stopping it being harvested once it's online in a readable form.
> If a human can read it, what's to stop a human from adding it to some
> "marketing" list?
> --
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php