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

[Milan Crha <mcrha redhat com>]

        Hi,
I'm adding evolution-list back into the loop. We had several private
exchanges with Josh, initiated by him. I'm not going to copy here all
we exchanged, most of that was just a noise. I have a plea for the
evolution-list members at the end, which is the 'why' for going back
into the public. I do that also to clarify something I wrote earlier
into the thread, which wasn't accurate.

On Tue, 2017-10-10 at 09:21 -0400, d18jf98rw use startmail com wrote:
> The sample you provided on email list had localhost.localdomain
> because your workstation hostname wasn't set.

Wrong! My machine has set a host name and it is *not*
localhost.localdomain.

But to be fair, I just gave it a try again and Google does use the info
from the EHLO in the Received header. The interesting part is that what
name will be used depends on the connection to the server. In case it
connects through the VPN, the VPN name is used (if found), but if it
connects directly, then local machine name (as I do not have public
name) is used.

> Again, I personally would not blindly follow any RFC if RFC is
> clearly causes "unwanted information disclosure".

Okay, the RFC [1] doesn't dictate to send FQDN, there is no 'MUST'.

> and "unwanted information disclosure" is a well defined term among
> security professionals.
> software developers in the company where I work are bitten very badly
> if "unwanted information disclosure" is found in their code.

Yes, I can understand it.

The thing is, for me personally, and I'm no networking expert, exposure
of the local IP is more problem than the machine name. The thing is
that I am, theoretically, able to address that machine by IP in the
internal network, while I cannot do the same when I know just the local
machine name. That's much bigger security concern for me. Again, I'm no
networking expert, thus it can be a nonsense.

Anyway, I would like to ask other evolution-list members to join the
bug [2] and express their opinion there, if they have any, want to and
can. I agree with Josh that the local machine name exposure is not
always expected, even just in the tracking headers, which can be used
to search for spammers (yes, I did use that information to track such
people in the past), but I also do not want to change the Camel SMTP
behavior in a wrong way. I also made a suggestion in the bug for kind
of a workaround, when to use the resolved name and when not (long story
short: the resolved name has less than two dots => do not use it),
which can satisfy both the RFC recommendations and the bug request in
most cases, I believe. To believe is not enough here, that's why I want
your help.

        Thanks and bye,
        Milan

[1] https://tools.ietf.org/html/rfc5321#section-4.1.1.1
[2] https://bugzilla.gnome.org/show_bug.cgi?id=738247