[SM-DEVEL] IP-address in mailheader

[Thijs K. <ki...@sq...>]

On Saturday 5 January 2008 08:24, Fredrik Jervfors wrote:
> > There is already a config setting that allows you to encrypt this
> > information ($encode_header_key; see conf.pl SMTP or Sendmail setting
> > details-->"Header encryption key"). =A0I think it should remain in plac=
e.
> > If the config setting is only in DEVEL, then I think the
> > better thing to do is port it to STABLE. =A0I do not support the wholes=
ale
> > removal of this information.
>
> Since this is a configurable setting (by the system administrator), I too
> is in favour of keeping it. It should be up to the system owner to decide
> if he wants to include the IP address used by the OP in the headers or not
> (i.e. only have it in the logs). There are situations when having the IP
> in the headers is quite useful, so SquirrelMail should definitely keep the
> option to have it that way.

I'm not fond of this for a couple of reasons:
1) It is not a substitute for proper logging anyway.
2) It's off by default, while I think we should only be broadcasting this k=
ind
   of data when the administrator explicitly wants that.
   The way it's implemented does not allow for an easy way to make us
   turn it on by default since a unique key is needed in the config.
3) We use a onetimepad function with a static key, so there's nothing oneti=
me
   about it anymore making it quite easy to crack. The onetimepad function =
is
   useful for something like the cookie where we generate a new pad every
   time.
   Our own config tool says it:
    print "Warning: used encryption function is not bulletproof. When used\=
n";
    print "with static encryption keys, it provides only minimal security\n=
";
    print "measures and information can be decoded quickly.\n";
4) The IP-address is used twice, also in the message ID for no reason.
   The message ID has a much wider distribution than the Received header.

I propose that we look at it the other way round. What problem do we want t=
o=20
solve? And then, which technology is the best way to solve it?

Stated problem:
   An adminstrator wants, in the case of abuse, to be able to determine whi=
ch
   username took a malicious action, and from which IP this user did that.

To solve this, we need to store somewhere who does what from which IP. We c=
an=20
store in one place at the server side, or we can put it in every email sent.

Advantages of putting it in every mail:
=2D Tracable by the receiver.
=2D Already works.
Disadvantages:
=2D Has a privacy concern.
=2D May not be available to the server administrator, depends on third part=
y to=20
get this info.
=2D Is not sufficient. A breakin where all of a user's emails are deleted c=
annot=20
be solved by this method, so additional logging is required anyway.
Encoding may partially resolve this but needs to be implemented much=20
differently from how it is now.

Advantages of storing it server-side:
=2D All needed information available to the server administrator.
=2D All needed information *only* available to the server administrator.
=2D For IP-address, already works (webserver logs).
Disadvantages:
=2D Needs some way to store username aswell. Available as a plugin.

Concluding from these options, I see that the main drawback of the serversi=
de=20
storage is the need for an extra plugin to store the username, otherwise it=
=20
seems superior to the broadcast method.

One may reason that the username is in a number of cases already publically=
=20
known. So it would already be an improvement to just remove the IP from the=
=20
headers and depend on existing logging as a replacement for that.

To completely solve this, it would be best if we included logging by defaul=
t.=20
=46or a serious email application, logging stuff does not seem like a bad=20
thing. We could "corelize" logging functionality with possible plugins to=20
handle different styles (syslog, textfile, sql).



Thijs