Posted by Joe Harman on 05/11/05 08:54

HA... Thanks for your thoughts...

I am actually using this for a broadcast email system... I just use a
PHP image generator to make a 1 x1 gif... the image generator script
takes a variable for color then I added another one for email address
to keep stats on who has opened the message

ex. image_script.php?color=000000&email=somebody@yourdomain.com

but I am using base64_encode to encode the email address.... and call
the variable something besides email... I suppose i didn't have to do
this, but thought it would be a good practice to do it...

the end result looks something like this :
image_script.php?color=000000&key=jtzOjM6IkpvZSI7czo5OiJsYXN0X2

also this is embedded in the body of an HTML email... so, i think it's
pretty safe any how the script just updates the stats and returns a
1x1 gif...

Cheers!
Joe



On 5/11/05, Richard Lynch <ceo@l-i-e.com> wrote:
> On Tue, May 10, 2005 8:50 pm, Joe Harman said:
> > Hey just curious if it's okay to encode variables that are passed in
> > URLs with base64_encode??? since, I am going to pass a email address
> > in the URL, I would like to protect the email address from typical
> > people
>
> I dunno if every character that can be output by base64_encode is URL-safe
> or not, but you could do: urlencode(base64_encode($email)) and be 100%
> certain that it is safe, and that the data you want will come through.
>
> That said, I don't think base64_encode will offer much protection from
> humans who want to snag emails, and you presumably aren't listing these
> URLs somewhere for web-bot harvesters to find... Though that would fool
> them, at least in the present.
>
> ARAIK, almost *any* obfuscation of email addresses foils the harvest bots..
>
> This seems unbelievable, but I liken it to fishing: If every time you
> cast a line in the water, you come up with a million fish, how hard will
> you work to change your bait?
>
> That is the current state of affairs in the "arms race" of email
> harvesting -- The spammers have SO MANY fish "biting" that they simply
> don't need to bypass obfuscation.
>
> Sooner or later, however, that will change, especially if the harvesters
> ever care about "quality" of their fish.
>
> While I'm not running around fixing all my old obfuscation code, I'm
> pretty much not using email obfuscation on any new sites/code.
>
> Instead, I build a FORM that will send the email "blind" to the recipient,
> and have a "throttle choke" that limits a given IP
> ($_SERVER['REMOTE_ADDR']) to N emails sent in H hours.
>
> Certainly, a script could be written to re-connect and get a new IP, but
> that in itself would take enough time on the end of the spammer that I
> doubt they'll want to bother any time soon.
>
> And it's all wrapped up in a 'spaminator' function that I can replace with
> something more robust if I need to.
>
> I figure this way, I'm 2 steps ahead in this arms race, so when the bad
> guys start decoding the obfuscation emails, I'll be ready for 'em.
>
> Now if I could just figure out a way to get my OWN email out of their
> lists so I wasn't getting 10,000 spams per day (literally) I'd be a Happy
> Camper.
>
> --
> Like Music?
> http://l-i-e.com/artists.htm
>
>


--
Joe Harman
---------
Do not go where the path may lead, go instead where there is no path
and leave a trail. - Ralph Waldo Emerson

[Back to original message]