GNOME Bugzilla – Bug 702703
Be able to overwrite domain in Message IDs
Last modified: 2017-10-23 16:32:50 UTC
message-id field generated by evolution-data-server always uses actual host name regardless of email domain configured. several other mailers were tested and all use email domain in message-id field, thus local host name is never disclosed in message-id field. host name could be disclosed in received field but it is a completely different story. actual host name must not be used in message-id field. file: evolution-data-server-3.x.x/camel/camel-mime-utils.c function: camel_header_msgid_generate (void)
Please see the end of [1], where is discussed a recommended way of creating message IDs. Evolution does exactly that. I know it can annoy some people, but why would you set your machine name in an obscure way? Note the Received headers also expose whole path from your machine to the destination. [1] http://tools.ietf.org/html/rfc5322#section-3.6.4
the end of [1] does not mandate, it suggests. if evolution solution was the smartest then the rest would follow. in fact all the mail clients I have investigated over the years use originating email domain instead of `hostname` for the message id field. look at thunderbird or apple mail for example. my proposed patch is not by any way a candidate for production. the limited time and knowledge did not allow me to propagate destination domain name to camel_header_msgid_generate (void) method without major rewriting.
> actual host name must not be used in message-id field. Why? And how exactly can that "disclosed information" be abused?
> > actual host name must not be used in message-id field. > > Why? And how exactly can that "disclosed information" be abused? No mail client besides evolution uses host name in the message-id field. Is that argument sufficient enough?
No it isn't, as you don't describe what the actually created, existing problem is, except for that you think that uniqueness is. "No mail client besides Evolution uses "Evolution" as the X-Mailer field value" sounds pretty similar.
scenario: one works at redhat.com and sometimes communicates via his/her gmail.com account from the same email client. evolution: when email is sent from gmail.com address message-id uses hostname.redhat.com. thunderbird: when email is sent from gmail.com address message-id uses gmail.com It it clear now? you may say that Received: headers may still disclose redhat.com office IP address. There are well known tools to hide IP address but there are no current tools to hide hostname in evolution.
I chose two approaches, one for master, with Camel API change, and one for stable, without the API change. Created commit 5772fd6 in eds master (3.13.3+) [1] Created commit cef3b32 in evo master (3.13.3+) [2] Created commit 50be494 in evo evolution-3-12 (3.12.4+) [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=5772fd6 [2] https://git.gnome.org/browse/evolution/commit/?id=cef3b32
*** Bug 774855 has been marked as a duplicate of this bug. ***
Excuse me for revisiting an old issue. I think it would be easier and safer to hardcode the domain used for Evolution/Camel message id's to a domain the Evolution team control themselves and therefore can guarantee the uniqueness of. In other words, I suggest to rip out all the code to find cached_hostname and domain and make *all* message-ids on the format <some-unique-hash@camel.gnome.org> PS. It might be a good idea to tell the hostmaster at gnome.org about this and ask them to add "camel.gnome.org. MX 0 ." to DNS just in case someone wants a wildcard record *.gnome.org in the future (the specific "null-route" MX will take precedence.
Message IDs are currently generated as: <time_t>.<pid>.<counter>.camel@<email.domain> This had been used for ESource UIDs as well, which I changed only recently, with this change [1], which uses even more information to make the ID unique, but then hides this information by computing a SHA1 hash of it, thus there is no leak of the local information to the outside. I've been thinking to use the same function in Camel's Message-ID generation, thus I'm in a favour of the proposal. The change to use hashes conforms to [2], thus there would be no problem too, and as long as the previous Message-ID generator (the one where local host name had been used) generated unique IDs, then the additional hashing of that ID keeps it unique as well. I like the camel.gnome.org as well, even, at least from my point of view, it doesn't guarantee more uniqueness as using the same domain as the sender's email domain (because of multiple machines at the same time and so on), thus either the camel.gnome.org can be used, or the email domain instead of it, like it is now. In other words, it would be either: f0317ae4c02c1e245f75ce60296410b748486c1d@camel.gnome.org or f0317ae4c02c1e245f75ce60296410b748486c1d.camel@example.com [1] https://git.gnome.org/browse/evolution-data-server/commit/src/libedataserver/e-data-server-util.c?id=8e876b1df327e93025020a2793833d714b92280e [2] https://tools.ietf.org/html/rfc5322#section-3.6.4
I made this only for the development version and it's the variant of <hash>.camel@<domain> where the <domain> is taken from the argument (can be provided by the caller). Created commit 3be50a11c in eds master (3.27.2+)