Re: Bug 738247 - unwanted information disclosure in message headers

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Bug 738247 - unwanted information disclosure in message headers

Milan Crha
        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, [hidden email] 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
_______________________________________________
evolution-list mailing list
[hidden email]
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
Reply | Threaded
Open this post in threaded view
|

Re: Bug 738247 - unwanted information disclosure in message headers

Pete Biggs

>
> 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.
>

Two things I note about this. First, the bug saw no activity for 3
years, there are no dupes and no supporting comments. It's not the big
issue that the OP seems to think it is and I worry about doing
something because someone was shouting loud about it.

Second, the statement in the bug of "actual host name must not be used
in helo" is actually wrong, the RFC states that it should be used.
(should, not must)

I personally wouldn't be excessively worried either way (which is why I
don't really want to comment on the bug) but would err on the side of
leaving things as they are - it just looks less spammy. (spamassassin
tests for lots of issues with the HELO string - one of them is for a
"bare IP" address, another for "numeric HELO".)

The OP did say that it was an issue of leaking information about, say,
his work environment when replying to private mail through gmail. With
my admin hat on, I would say that if it is an issue for you or your
work, then you shouldn't be using a work machine at all.

P.

ps a workaround I've just thought is to use sendmail on the local
machine, not SMTP. sendmail / postfix / exim / whatever are much more
configurable in what they send and I suspect that that is the proper
place for the adjustments to be made.


_______________________________________________
evolution-list mailing list
[hidden email]
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
Reply | Threaded
Open this post in threaded view
|

Re: Bug 738247 - unwanted information disclosure in message headers

Milan Crha
        Hi,

On Tue, 2017-10-10 at 17:59 +0100, Pete Biggs wrote:
> I personally wouldn't be excessively worried either way (which is why
> I don't really want to comment on the bug) but would err on the side
> of leaving things as they are - it just looks less spammy.

Is 'err' a typo? I'm afraid I do not follow, if not.

> (spamassassin tests for lots of issues with the HELO string - one of
> them is for a "bare IP" address, another for "numeric HELO".)

This is exactly the type of the information I'm looking for. I do not
know all the consequences which the change would cause.
        Thanks and bye,
        Milan
_______________________________________________
evolution-list mailing list
[hidden email]
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
Reply | Threaded
Open this post in threaded view
|

Re: Bug 738247 - unwanted information disclosure in message headers

Patrick O'Callaghan
On Tue, 2017-10-10 at 19:56 +0200, Milan Crha wrote:
> > I don't really want to comment on the bug) but would err on the side
> > of leaving things as they are - it just looks less spammy.
>
> Is 'err' a typo? I'm afraid I do not follow, if not.

"To err" is correct English for "to make a mistake". In this case Pete
is saying that it's preferable to leave things as they are, even though
that might (in theory) be wrong, because changing them might (in
theory) lead to worse results.

English grammar is fun :-)

"To err is human, to forgive divine" - Alexander Pope

poc
_______________________________________________
evolution-list mailing list
[hidden email]
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
Reply | Threaded
Open this post in threaded view
|

Re: Bug 738247 - unwanted information disclosure in message headers

Paul Smith-43
On Tue, 2017-10-10 at 19:10 +0100, Patrick O'Callaghan wrote:

> On Tue, 2017-10-10 at 19:56 +0200, Milan Crha wrote:
> > > I don't really want to comment on the bug) but would err on the
> > > sideĀ of leaving things as they are - it just looks less spammy.
> >
> > Is 'err' a typo? I'm afraid I do not follow, if not.
>
> "To err" is correct English for "to make a mistake". In this case
> Pete is saying that it's preferable to leave things as they are, even
> though that might (in theory) be wrong, because changing them might
> (in theory) lead to worse results.
>
> English grammar is fun :-)
>
> "To err is human, to forgive divine" - Alexander Pope

Also, "err on the side of ..." is a common idiom:

http://idioms.thefreedictionary.com/err+on+the+side+of


_______________________________________________
evolution-list mailing list
[hidden email]
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
Reply | Threaded
Open this post in threaded view
|

Re: Bug 738247 - unwanted information disclosure in message headers

Pete Biggs
In reply to this post by Milan Crha
On Tue, 2017-10-10 at 19:56 +0200, Milan Crha wrote:
>
>
> > (spamassassin tests for lots of issues with the HELO string - one of
> > them is for a "bare IP" address, another for "numeric HELO".)
>
> This is exactly the type of the information I'm looking for. I do not
> know all the consequences which the change would cause.

There were some comments I've seen that said the debian version of
spamassassin at some point had numeric Helo as a score of 4.0 which is
very high. It's been reduced now, possibly to 0.0. But it has obviously
been on their radar.

P.

_______________________________________________
evolution-list mailing list
[hidden email]
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list