[PHP] Re: Email Antispam
"David Mehler" 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
[PHP] Re: Email Antispam
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
"Ross McKay" 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
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
[PHP] Re: Email Antispam
"Ross McKay" 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 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
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
> -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" 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
Re: [PHP] Re: Email Antispam
On Wed, Apr 18, 2012 at 8:47 PM, Ross McKay 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
Re: [PHP] Re: Email Antispam
Bastien Koert On 2012-04-19, at 1:54 AM, tamouse mailing lists wrote: > On Wed, Apr 18, 2012 at 8:47 PM, Ross McKay 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
On Thu, Apr 19, 2012 at 1:01 PM, Bastien wrote: > > > Bastien Koert > > On 2012-04-19, at 1:54 AM, tamouse mailing lists > wrote: > >> On Wed, Apr 18, 2012 at 8:47 PM, Ross McKay 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
On Thu, 2012-04-19 at 13:48 +0200, Matijn Woudt wrote: > On Thu, Apr 19, 2012 at 1:01 PM, Bastien wrote: > > > > > > Bastien Koert > > > > On 2012-04-19, at 1:54 AM, tamouse mailing lists > > wrote: > > > >> On Wed, Apr 18, 2012 at 8:47 PM, Ross McKay 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
Re: [PHP] Re: Email Antispam
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 wrote: > On Thu, 2012-04-19 at 13:48 +0200, Matijn Woudt wrote: > >> On Thu, Apr 19, 2012 at 1:01 PM, Bastien wrote: >> > >> > >> > Bastien Koert >> > >> > On 2012-04-19, at 1:54 AM, tamouse mailing lists >> > wrote: >> > >> >> On Wed, Apr 18, 2012 at 8:47 PM, Ross McKay 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
