Re: [PHP] Re: Email Antispam

2012-04-25 Thread David Mehler
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 a...@ashleysheridan.co.uk wrote:
 On Thu, 2012-04-19 at 13:48 +0200, Matijn Woudt wrote:

 On Thu, Apr 19, 2012 at 1:01 PM, Bastien phps...@gmail.com wrote:
 
 
  Bastien Koert
 
  On 2012-04-19, at 1:54 AM, tamouse mailing lists
  tamouse.li...@gmail.com wrote:
 
  On Wed, Apr 18, 2012 at 8:47 PM, Ross McKay ro...@zeta.org.au 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



Re: [PHP] Re: Email Antispam

2012-04-19 Thread Bastien


Bastien Koert

On 2012-04-19, at 1:54 AM, tamouse mailing lists tamouse.li...@gmail.com 
wrote:

 On Wed, Apr 18, 2012 at 8:47 PM, Ross McKay ro...@zeta.org.au 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



Re: [PHP] Re: Email Antispam

2012-04-19 Thread Matijn Woudt
On Thu, Apr 19, 2012 at 1:01 PM, Bastien phps...@gmail.com wrote:


 Bastien Koert

 On 2012-04-19, at 1:54 AM, tamouse mailing lists tamouse.li...@gmail.com 
 wrote:

 On Wed, Apr 18, 2012 at 8:47 PM, Ross McKay ro...@zeta.org.au 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



Re: [PHP] Re: Email Antispam

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

 On Thu, Apr 19, 2012 at 1:01 PM, Bastien phps...@gmail.com wrote:
 
 
  Bastien Koert
 
  On 2012-04-19, at 1:54 AM, tamouse mailing lists tamouse.li...@gmail.com 
  wrote:
 
  On Wed, Apr 18, 2012 at 8:47 PM, Ross McKay ro...@zeta.org.au 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] Re: Email Antispam

2012-04-18 Thread Jim Giner

Ross McKay ro...@zeta.org.au wrote in message 
news:795so7t0avn28a5m8i373h9tursk15c...@4ax.com...
 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



[PHP] Re: Email Antispam

2012-04-18 Thread Ross McKay
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



Re: [PHP] Re: Email Antispam

2012-04-18 Thread tamouse mailing lists
On Wed, Apr 18, 2012 at 8:47 PM, Ross McKay ro...@zeta.org.au 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



[PHP] Re: Email Antispam

2012-04-17 Thread Jim Giner

David Mehler dave.meh...@gmail.com wrote in message 
news:CAPORhP5Cuzd0Hb9gBFLESNe5LofDODN64S2UOAuMWCb=zoh...@mail.gmail.com...
 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



RE: [PHP] Re: Email Antispam

2012-04-17 Thread Steven Staples
 -Original Message-
 From: Jim Giner [mailto:jim.gi...@albanyhandball.com]
 Sent: April 17, 2012 4:33 PM
 To: php-general@lists.php.net
 Subject: [PHP] Re: Email Antispam
 
 
 David Mehler dave.meh...@gmail.com wrote in message
 news:CAPORhP5Cuzd0Hb9gBFLESNe5LofDODN64S2UOAuMWCb=zoh...@mail.gmail.com...
  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



[PHP] Re: Email Antispam

2012-04-17 Thread Ross McKay
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



[PHP] Re: Email Antispam

2012-04-17 Thread Jim Giner

Ross McKay ro...@zeta.org.au wrote in message 
news:b4vro79ftp9423k74bnj41o1o9e3dk9...@4ax.com...
 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



[PHP] Re: Email Antispam

2012-04-17 Thread Ross McKay
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