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, [email protected] 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 [email protected] To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
