GNOME Bugzilla – Bug 738155
Wish: Do not send real hostname via SMTP when sending mail (Patches supplied)
Last modified: 2021-06-01 22:42:48 UTC
Created attachment 288047 [details] Patches that enable new "Send custom hostname" option under smtp dialog (and implementation under send.c) I've been hired to modify balsa source code, in a concern of privacy to avoid or have another aproach instead of sending the real hostname when sending an email via SMTP. I made it by adding a new option which could allow user to specify a custom hostname to be sent (in both message-id and EHLO command via TLS smtp for example). As I think also that is an important matter in privacy I propose my patches to be studied and, if applicable, merged to balsa in further versions. Patches are made against 2.5.1 release of balsa. Thanks
Also note that, this newly added option, can also be disabled to use original function and send real hostname if desired by user, so it should not be considered intrusive (also, it is disabled by default)
Created attachment 288220 [details] ebuild and directory tree for putting inside an overlay For those using gentoo or its derivates, I add the folder/files neccesary to put them into an overlay in order to compile/install it with my patches applied.
Thanks for the suggestion! As I read it, the custom hostname would be used in two places: in the dialog with an SMTP server, and in generating the message-ID. However, Balsa could, with some minor modifications, generate a unique message-ID that does not contain the hostname, without requiring the user to provide a custom hostname. It's not clear that using a custom hostname provides privacy in the SMTP dialog, as the user's IP address is known to the server, and typically encapsulated in an 'originating-IP' header. If the client avoids that, perhaps by using an anonymizing server, then the hostname would presumably also be omitted from all headers. We're glad to see that you take privacy seriously, and we'd like to work with you to achieve your goal! Peter
RFC 5321 [1], Sect. 3.7.2. states that "when forwarding a message into or out of the Internet environment, a gateway MUST prepend a Received: line [...]". RFC 5321, Sect. 4.4, explicitly states that the 'TCP-info' element of the Received: header shall be "[...] derived by server from TCP connection, not client EHLO". IOW, a RFC 5321-compliant MTA receiving the message must include the client's IP address and/or resolvable host name. And it's up to the next hop MTA which information is added to the envelope, *not* to the sending MUA or MTA. The "fake" host name will simply be ignored. [1] <https://tools.ietf.org/html/rfc5321>
(In reply to comment #4) > RFC 5321 [1], Sect. 3.7.2. states that "when forwarding a message into or out > of the Internet environment, a gateway MUST prepend a Received: line [...]". > > RFC 5321, Sect. 4.4, explicitly states that the 'TCP-info' element of the > Received: header shall be "[...] derived by server from TCP connection, not > client EHLO". IOW, a RFC 5321-compliant MTA receiving the message must include > the client's IP address and/or resolvable host name. And it's up to the next > hop MTA which information is added to the envelope, *not* to the sending MUA or > MTA. The "fake" host name will simply be ignored. > > [1] <https://tools.ietf.org/html/rfc5321> I understand that points, however, with a sending IP address is just more than enough for a workstation (not for a server though). The option I just added, is very useful to be used in a workstation, so both, have the privacy of not getting your internal hostname revealed in mail headers, and [2] Despite it will be ignored, it can still be viewed in headers, so it is better to allow advanced users to choose the hostname they want to be shown. Also, other mail programs also do have this option already (like kmail for example) that is why I was asked to implement it. So, as it is an optional config option, then I suggest it to be merged, or implemented properly if you wish, anyway it do not do any harm, and just add more privacy (no downsides :) )
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/balsa/-/issues/ Thank you for your understanding and your help.