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

Reply via email to