Menu
▾
▴
#413 IP address used in Received header
Right now the IP address used in the Received: header
is the one the user is logging in from via the web. In
some cases the system administrator isn't interested in
using that, but wants all email to look like it's coming
from the email server that it's being sent out from (the
admin's server). If you trust your users, and want to
save them from their bad ISPs -- this is the way to do it.
Logged In: YES
user_id=225877
If admin is not interested in this header and trusts users,
he or she will be toasted some day. If you can't say which
user sends harassing emails to other people, you are guilty
of sending those emails or allows this to happen.
SquirrelMail 1.5.1cvs contains options that disable this
header. Think twice before you enable that option. Header
provides information that can't be forged by end user.
Use bug 847107 to provide your comments
https://sourceforge.net/tracker/index.php?func=detail&aid=847107&group_id=311&atid=100311
Hi,
We have been maintaining a patch against squirrelmail since I think 1.4.2 which solved the Message-ID privacy issue (which you have fixed in http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/branches/SM-1_4-STABLE/squirrelmail/class/deliver/Deliver.class.php?r1=12941&r2=12992&view=patch\), but also this Received header issue. To our users having Squirrelmail put the IP address of the user's home computer in every email they send out is a horrible breach of privacy. We have other mechanisms for dealing with problem users, so disabling this is preferable (we still include the login name of the user so that we can figure out which user is at fault).
1.4 doesn't have any mechanism to do this, and sadly the 1.5 way of doing this (a so-called "encode_header_key" feature) doesn't provide the strength of anonymity that our users require. Its actually quite poor encryption (especially since the padding string is always the same and stored in /etc/, if you really want to know you can get it there, this doesn't work for our policy).
So, our patch prevents *any* home IP address from appearing in the headers, no matter which way you've set your "encode_header_key" option. It does it in somewhat of a hacky way, and I will be the first to admit that this is not the right way to do this. Essentially what it does is make the Received header always say "localhost (127.0.0.1)", which is perfectly fine for us... this patch can be found at http://dev.riseup.net/privacy/webmail
Now I understand why you are uninterested in this feature, and that you think that the 1.5 way of handling this is sufficient. We respectfully disagree and would like to offer you a bounty of $100 to take our patch and integrate it in SM so we no longer have to carry around this delta. We would expect that rather than you just applying our patch, that you would come up with a more elegant way of doing this, perhaps offering the admin the configuration option of either 'encoding the header' with the "encode_header_key" option (make this the default), or allow the admin to completely anonymize the Received header (this would make it do what we do, or perhaps you can offer people the option to set the 127.0.0.1 to whatever value that they want). You can put sufficient warnings all over this so people would be discouraged from doing it, unless they really know waht they are doing, whatever works.
We were hoping that this could be made available in 1.4 as well as 1.5 and forwards so that we can stop porting our patch every release.
ps. This issue is currently closed, and although you say that you should use bug 847107 to provide further comments, that bug is not available on the system (or it is hidden/private?). So probably this issue should be re-opened for the bounty purposes.
Err, I forgot to add one piece to the bounty related to header privacy. The Message-ID solution (I mentioned the commit-id) was the other area that we are concerned about. Although your solution does make it really hard to get the user IP from the hash mechanism you are using, we really dont want to take that risk, so we typically are commenting out these seeds:
$seed_data .= (!empty($REMOTE_PORT) ? $REMOTE_PORT . '.' : '');
$seed_data .= (!empty($REMOTE_ADDR) ? $REMOTE_ADDR . '.' : '');
It would be better if the seed information came from other sources of data that didn't help reveal the user's IP, even with a one-way hash.
Regarding the message ID concern, I'm not sure it is possible to reverse engineer the user-specific data from it, but it is good practice to avoid the use of personal data if at all possible except when necessary/appropriate. Therefore I am considering a patch that changes the "seed" value so that it doesn't use the remote address or port, nor the username. Please see the attached patch for that.
Message ID - no private data in seed
Regarding the received header, you seem to claim that anyone(?) can get the key to decipher the encoded data because it's somewhere in /etc/. Is that because your SM configuration file is in /etc/? If this is your claim, then my question to you is why do you allow world read permission on that file? Better yet, why would your users have filesystem access? If this is your concern, what do you do for any database login credentials in the configuration file(s) for SquirrelMail, its plugins, or any other web application on your system?
...And if your users could get something in /etc/, it may be possible that they could also just go get your log files where the targeted information they are seeking (user IP addresses) isn't even encrypted.
That said, the encryption on the encoded strings is not claimed to be strong. Someone claims to have cracked it in the artifact that you could not find. It is here:
http://sourceforge.net/tracker/index.php?func=detail&aid=847107&group_id=311&atid=423679
We are very hesitant to give the option to entirely remove or hard-code this header, primarily because many admins who really don't know any better and have not taken the time to consider the implications and who don't have any other means of tracking their users who might send abusive messages will quickly and foolishly choose that configuration.
However, I have a fundamental problem with the choice to date not to give our users the tools to do what they want or need. Just because you can get yourself in trouble with certain tools is NOT an argument for abolishing them -- it's an argument for helping make people smarter.
The choice not to allow the removal of this information also ignores the fact that there are many other ways to track this kind of data, including the use of the Squirrel Logger plugin and reasonable web server and mail server log retention -- and these methods offer the added benefit that user data is NOT being broadcast to the world.
Ultimately, the decision to force admins into a certain paradigm is based on a condescending lowest-common-denominator mentality that IMO assumes stupidity on the part of our users (sadly, this assumption is true too much of the time -- but NOT always) and runs contrary to what I feel are values implicit in the concept of FOSS.
So I would like to entertain ideas on how to allow people like zygut to do what they need to without maintaining their own patch (they'll do it anyway!). The only two ways I can think of:
1) Add another configuration possibility to remove or hard code the header as zygut suggests. We'd add all kinds of "DO NOT DO THIS UNLESS YOU KNOW WHAT YOU'RE DOING; DON'T BE FOOLISH" warnings to it in the configuration tool. I'm hesitant to take this route, though, because typically, no matter how harsh the warning, people who should not ignore it will ignore it.
2) Add a hook in the Deliver class (specifically, near the end of the mail() function) that allows last-minute manipulation of the outgoing message. This is very similar to the compose_send hook, but that one is executed before these controversial headers are added. We could mention in the documentation (or even in the configuration utility) that if you want to completely remove or hard-code this header, you'll have to prove that you know what you are doing by making your own plugin to achieve what you want. I would be willing to provide users with the needed plugin as well, but only if asked for it - I wouldn't plan to publish it on SM.org.
I'm leaning toward the plugin solution, because it still makes it hard for novice admins to shoot themselves in the foot, but allows a maintainable open option for those who really do need it. The downside is that maybe that's still too many hoops to jump through for people who legitimately want/need that feature but don't have the time to do the hoop-jumping.
Comments please.
Sorry, I forgot that I had one more idea. The Vadmin plugin has some useful encryption techniques that we could possibly integrate into the SM core -- they allow the use of mcrypt or a built-in RC4 algorithm to encrypt data. We could replace the current encryption with at least the built-in RC4 method, which, while not un-crackable itself, may be stronger than the current method. If PHP has been compiled with mcrypt, we can offer even better methods - any that mcrypt supports such as blowfish, tripledes, etc.
However, note that this idea still does not directly address the fact that some people will STILL want to remove this data from outgoing messages.
Thanks for your thoughtful, and quick! comments on this issue.
Sadly, sourceforge doesn't do quoting, so I am going to attempt to do it manually, I hope this doesn't get screwed up.
you wrote:
> Regarding the received header, you seem to claim that anyone(?) can get the key to decipher the encoded data
> because it's somewhere in /etc/. Is that because your SM configuration file is in /etc/? If this is your claim,
> then my question to you is why do you allow world read permission on that file? Better yet, why would your users
> have filesystem access? If this is your concern, what do you do for any database login credentials in the
> configuration file(s) for SquirrelMail, its plugins, or any other web application on your system?
I'm sorry I didn't make this clear in my initial post. No, nobody can get the key from /etc, without a mistake in our permissions, an intrustion/exploit or some other seizure of the system. However, these are significant concerns, enough so that we would prefer not to have a key that can be compromised, or a system that could be broken (even the best of us have written crypto routines that seem like they fit the bill,only to find out later that we completely missed something obvious or some new math came out that made the method that we were using useless). We have a site policy that prohibits this information, so we Even if it seems strong now, having the option of *not having it at all* is even better, at least for us. Its understandable that this is not for everyone!
We are a service provider, and we face legal pressures from all sides to collect and store detailed information about users and their online activities that may be of great interest to third parties. The USA PATRIOT Act and other recent legislation have also provided the government with expanded powers to request this information. As a result, service providers must deal with requests from law enforcement and lawyers to hand over private user information and logs. This often interferes with our goal of providing users with reliable, secure network services that ensure the privacy and civil liberties of our users.
A key strategy is our data retention policy, which was designed specifically to to minimize the amount of information we collect and store in the first place. Because we are not in a specially regulated industry (such as finance, heath care, aviation, etc.), there is no law in the US that requires us to collect and store information about our users.
> ...And if your users could get something in /etc/, it may be possible that they could also just go get your log files
> where the targeted information they are seeking (user IP addresses) isn't even encrypted.
That is true, but also true is that our site policy prohibits from collecting these log files with personally identifying information.
> We are very hesitant to give the option to entirely remove or hard-code this header, primarily because many
> admins who really don't know any better and have not taken the time to consider the implications and who don't
> have any other means of tracking their users who might send abusive messages will quickly and foolishly choose
> that configuration.
Your concern is completely understandable. I think that we could find a way to make it so people wont make such a configuration choice without understanding the implications first.
[snip]
> The choice not to allow the removal of this information also ignores the fact that there are many other ways to track
> this kind of data, including the use of the Squirrel Logger plugin and reasonable web server and mail server log
> retention -- and these methods offer the added benefit that user data is NOT being broadcast to the world.
That is a good point, I had not thought about that rationale. The key thing is that we are able to track down an abusive user in ways that do not necessitate that user constantly broadcasting their data to the world. People should make sure that they have this capability before they turn something like this on.
> So I would like to entertain ideas on how to allow people like zygut to do what they need to without maintaining their > own patch (they'll do it anyway!). The only two ways I can think of:
True, and we've been doing it for more than 5 years :)
> 1) Add another configuration possibility to remove or hard code the header as zygut suggests. We'd add all kinds
> of "DO NOT DO THIS UNLESS YOU KNOW WHAT YOU'RE DOING; DON'T BE FOOLISH" warnings to it in the
> configuration tool. I'm hesitant to take this route, though, because typically, no matter how harsh the warning,
> people who should not ignore it will ignoreit.
What about doing this, but *not* including the option in the configuration tool, but instead only include it in the actual configuration file. That way a user who is using the tool (which was generated to cater towards those who aren't so used to configuration files) will not see it, but if they really want it, they can find out about it and turn it on by fiddling the right bit in the config file.
> 2) Add a hook in the Deliver class (specifically, near the end of the mail() function) that allows last-minute
> manipulation of the outgoing message. This is very similar to the compose_send hook, but that one is
This is an interesting idea, and seems like a good one. It makes me nervous because it cuts close to the edge ("the info is there, but then it is stripped" is often significantly different in certain contexts from 'the info was never there to begin with")
> you know what you are doing by making your own plugin to achieve what you want. I would be willing to provide
> users with the needed plugin as well, but only if asked for it - I wouldn't plan to publish it on SM.org.
This is starting to seem like some hoop jumping that discourages people, especially since there are plenty of us experienced admins who have never written a SM plugin, so its not necessarily a correct correlation to say that experienced admins are those who have written plugins.... but it could be an alright solution too, we'd be interested in distributing such a plugin on our pages where we catalog these sorts of privacy/anony enhancing patches and tools (
http://riseuplabs.org/privacy/\)
Thanks!
By the way, the correct URL for the related artifact is:
https://sourceforge.net/tracker/index.php?func=detail&aid=847107&group_id=311&atid=423679
A mechanism has now been added that allows you to tell SquirrelMail to skip adding its own Received header altogether. To enable it, you'll need to go read the code comments that were added to class/deliver/Deliver.class.php in this commit (it's a little better documented in 1.5.2).
http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail?view=rev&revision=13804
A mechanism has now been added that allows you to tell SquirrelMail to skip adding its own Received header altogether. To enable it, you'll need to go read the code comments that were added to class/deliver/Deliver.class.php in this commit (it's a little better documented in 1.5.2).
http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail?view=rev&revision=13804