Re: base64_encode in URLs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux