Re: [Evolution] Bug 738247 - unwanted information disclosure in message headers

[Milan Crha <mcrha redhat com>]

On Mon, 2017-09-25 at 17:30 -0400, d18jf98rw use startmail com wrote:
> local IP is better.

        Hi,
maybe. It still exposes some details about the network, like what
internal IP range is in use.

I just tried with a Google account and the first Received header
contains "localhost.localdomain" with an IP of my ADSL router, not my
local address, neither my computer name, thus the server can change the
information too, possibly according to reverse DNS lookup. When you
look at this message, then it also doesn't show my local address,
neither the local computer name.

> Simplest example is when a corporate user sends an email using public
> email server like yahoo/google/aol etc, their fully qualified host
> name may show up in helo part which is not always what they may want.

Right, most people probably do not care, or do not know, but some
people do care. That's okay.

> > Looking around, the SMTP transport uses the name only if
> > g_resolver_lookup_by_address() returns anything for the address
> > returned by g_socket_connection_get_local_address().
> > There is no option to skip this lookup.
>
> I strongly disagree with this statement because thunderbird does not
> do host name lookup and always uses IP address in helo part.

I did not speak of Thunderbird, I said what Camel (part of evolution-
data-server) does in the SMTP provider.

> According to gnome bugzilla there was a bug 702703 with exactly the
> same unwanted information disclosure complain and was fixed by you,
> Milan, four years ago.

That was for Message-ID header, not for Received header. As far as I
can tell, that header can be influenced only with SMTP. I do not think
there's anything when using sendmail or an Exchange connector (neither
I tried NNTP).

Just to make it clear, I didn't say it cannot be changed, I even gave
pointers to involved functions in the SMTP Camel provider code, I only
think it's not that important for others as it is for you.

The bug 738247 has only the reporter, no duplicates, no CC'ed other
than Andre, whom takes care of bug triage, thus he doesn't count (I'm
sorry, Andre). Being there higher demand, it is fixed earlier probably,
but you see it's almost 3 years old and nobody else had been interested
to support the idea. In any case, feel free to propose a patch, that
may speed things up and you get credits for the fix. It might be as
simple as not resolve the local address. Then you can also try whether
it'll make any difference for the findings from the very top of this
email, because it's possible the change will not change anything (at
least for some servers).
        Bye,
        Milan