From: Thijs K. <ki...@sq...> - 2008-01-06 13:26:23
|
On Sunday 6 January 2008 13:34, Tomas Kuliavas wrote: > Every standalone email client puts user's home IP in email headers. SMTP > servers do that by default. In SquirrelMail "email client" is user's > browser running on his or her machine. SquirrelMail scripts are only > processing actions executed on user's machine. That others do it doesn't mean we shouldn't do better if we can. Because=20 SquirrelMail is not running on the user's machine we have the option of=20 giving them more privacy. So we should. > $encode_header_key encrypts username, remote address, proxy address AND > message id. > Logging facilities depend on OS and require additional setup steps. You > want to increase user's privacy by violating security of webmail admins > position. Good admins will have custom loggers, but beginners won't have > them and their setups can be abused. This code you are talking about has > reference to closed SquirrelMail bug tracker with thoughts about it. Other > related bug tracker is mentioned on first tracker. Don't confuse privacy > with security. By removing IP you are not increasing user's security. If > user's account is hijacked, user won't be able to prove that he or she is > not the one that send bad emails. I think that the current situation breaches privacy in the name of security= ,=20 but does not provide the desired security that it tries to implement. I'm not clear on why logging would require more complicated setup steps tha= n=20 creating webserver writable data- and attachmentdirs, something we already= =20 require from admins to be able to. The current header is false security: it isn't complete but the uneducated= =20 admin you are talking about might think that it is. I'd much more prefer th= at=20 someone sets up logging than think that he is safe because the IP-address i= s=20 in each header. That admin cannot do anything if a user finds out that someone has compromi= sed=20 his account and is reading all his mail. Sending the IP only solves a part = of=20 the possible uses of SquirrelMail. > Every twoway crypto can be cracked. You are free to use stronger crypto, > but X-Squirrel-UserHash header will provide cribs usable for cracking even > stronger crypto. All crypto can be cacked of course - but we currently use a very weak schem= e=20 that is easy to crack. Especially because there's a very real option to get= =20 known plaintexts to get the key. My point here is that the current=20 encodeheader option, that was suggested as a solution to the privacy proble= m,=20 is not a solution to "safely" send out IP's, but merely obscures them. Thijs |