SquirrelMail

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

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

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!

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.

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.

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.

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.

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.

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