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 <ash@xxxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 2012-04-19 at 13:48 +0200, Matijn Woudt wrote: > >> On Thu, Apr 19, 2012 at 1:01 PM, Bastien <phpster@xxxxxxxxx> wrote: >> > >> > >> > Bastien Koert >> > >> > On 2012-04-19, at 1:54 AM, tamouse mailing lists >> > <tamouse.lists@xxxxxxxxx> wrote: >> > >> >> On Wed, Apr 18, 2012 at 8:47 PM, Ross McKay <rosko@xxxxxxxxxxx> 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
