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@xxxxxxxxxxxxxx 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@xxxxxxxxx> 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
