Message-ID contains local computer name, can it be changed?

Mail
1

I like the eM Client and want to switch from Thunderbird to this software, but there is one thing that really bothers me a lot and keeps me from buying the software and using it in my company for all employees. I found that the message ID is set by the eM Client and includes the local computer name… Why?

Especially in a company, I really don’t want every recipient to know what the employee’s computer is called in my network… Every other email client I’ve tried uses the email domain name, not the local computer name.

Every email I look at in my inbox from other people includes their mail domain in the message ID but not the local computer name. No matter if it’s sent by a webmailer or using a desktop mail client. Also, the local computer name is less unique than the mail domain. I really really hope this can be changed, otherwise I’ll have to look for other mail clients…

In addition, I’ve already experienced that mail servers mark such e-mails as spam because of this name in the message ID.

And to get this straight from the start: No, I can’t just rename all computers in the network. These names are important and make sense, but only internally and they shouldn’t be public…

I would be glad to get an answer. Thanks in advance!

2

@SolusVM See @Gary reply below on the local computer name in the message header.

Setting Message-id - Mail - eM Client

Gary

Jun '19

The standard is .

If you are sending mail through your company’s own mail server, it should be the actual domain and not the host name of your computer. That is what happens for me, but when I send personal mail from home through my ISP, the host name of the computer is used. I always understood that this is the required method.

If you want to change the way this is generated without changing the application, just change the host name of your computer. Otherwise, if you want to change OS and mail clients, some Linux clients do allow you to configure your message-id as you have suggested. :wink:

3

I personally don’t have a problem with my local computer name being shown in the message header. 99.9% of my emails are to my friends anyway and they don’t even know. Only tech peeps would know its even there in the source. I can always change my local computer name if needed as Gary advised.

4

Thank you for the reply. My problem with this is that I send business emails through Google Workspace as my email provider and I don’t want my customers to see such internal hostnames.

If this is the default, I wonder why I keep reading online that it should be the domain and other email clients do it that way too. I never saw this before I tried using the eM Client.

The hostnames of my company’s computers include inventory numbers, among other things, and strictly need to stay that way. Also many things in the network are bound to this hostname and I can’t change hostnames of all of my computers just because an email client specifies it in the message ID…

And as I mentioned: I’ve gone through many of my incoming emails and find only domains, no local computer hostnames in the message IDs…

I also wonder why all other email clients I’ve used so far just don’t use the hostname or don’t specify a message ID so that the mailserver does it. Same mailbox, same mail server --> Google Workspace.

If I’d only email my friends, I might not care either. But that’s not the case with me and my employees. For me, this point is decisive for a purchase of the licenses (or not).

5

Because that is an approved standard.

But even if you specify that the client doesn’t include the hostname, there is no guarantee that the first server the message passes through won’t change it.

Me neither.

6

I don’t know if all other email clients I and all the people who email me use don’t pass a message ID, but as I said: I also only find emails in my inbox with domains in the message ID, not with local computer names. Every email I’ve ever sent with any other email client so far (same mail server → Google Workspace, it’s business mail service) had the domain in the message ID as usual…

I also don’t know why I should change my entire network naming structure in terms of client devices just for this one software. But then I’ll probably not be able to use the eM Client. Too bad, because I wanted to buy licenses for all my employees, because I really like the program concerning the features and the design, but this just bothers me too much. My customers don’t necessarily need to know the internal hostnames, which, as I said, include inventory numbers of these devices, among other things that not everyone needs to know.

I find it very sad, because it would be so easy just to add an option in the settings to prevent this (e.g. don’t pass an own message ID or just let the user choose this).

7

By the way, spam filters don’t like such message IDs either. An example for this is the well-known spam filter “rspamd” that’s used by one of our customers. I wonder how that can be when that’s supposedly the standard. The spam score will be increased by 0.5, just because of this weird message ID :sob: DKIM and SPF only reduce the spam score by a total of 0.4 points. So, an increase by 0.5 points is quite a bit in my opinion.

At least that should be a reason to change it or not? I don’t know, it’s just sad… And this is also consistent with the fact that, as I mentioned, I only see real domain names in the message ID for all my incoming emails. I just can’t understand this…

image

1 Like
8

I don’t think EM Client Devs would worry about a Spam filter increasing by 0.5 due to the local computer name being send in the message id as its normally mean’t to be there.

9

That may be, but it’s not the only argument I’ve mentioned in my posts. But well, if nothing will change, then I’ll have to use another email client in our company. After all, there are enough that set the message ID as I expect (Thunderbird, Outlook, etc.). It’s a pity about the features and the design, but honestly it’s not worth it for me.

The simplest solution would still be an option in the eM Client settings, which should be possible with little effort, I guess. Then the user could decide and everyone would be happy.

10

@SolusVM See reply post from @Olivia_Rust at EMC Support on this subject

Olivia_RustLeader

Oct '16

Hello Ossopite,
it is actually the standard to add the device name to the Message ID to assure the ID is indeed unique and other desktop clients should use this standard.
Sender domain is used when you create/send your message through webmail (because it does not have information about your device name).
If you are concerned about your privacy, perhaps change the device name to something neutral.

Regards,
Olivia

11

Then I’d like to have the source for that, showing that this is the standard. Have you ever looked at the headers of your incoming emails that were not sent to you using the eM Client? Don’t you notice anything there? I can’t imagine that the e-mails sent to you contain only or almost only the local computer name in the message ID.

As I said, I looked through a lot of senders that emailed me and I could only find emails whose message ID included the domain. Isn’t it a bit strange if it’s supposed to be the standard to use the local computer name? And then how do you explain that spam filters rate something like this negatively if it’s “the standard”? For me this makes no sense and I’d be pleased about the source of the corresponding official standard, which says that you should use your local computer hostname in the message ID of mail communication over the public internet.

Apart from the data protection aspect, using the sender’s computer name makes no sense to me - no matter who claim that here on the forums. What I see is hundreds or thousands of emails in my inbox using the domain in the message ID, the spam filter results and also the fact, that all emails I’ve sent with whatever other email client so far contained the domain in the message ID when you look into the headers on the recipient’s side.

Btw, in each case it was exactly the same mail server (Google Workspace) and that counts more for me than such statements here in the forum, which don’t give any sources on which these statements are based. Either official standards or personal experience (over years) with incoming emails.

Again: I don’t know why I should ever change my entire network naming structure in terms of client computer hostnames just for this one software. These names have a meaning and are clearly structured, but should simply not be visible to the outside world. For example, because they contain internal inventory numbers or names of employees. I’ll certainly not completely throw away such a structured system just for the eM Client, I hope you understand that.

In addition, only the computer hostname and not the FQDN would be in the message ID if I would rename them. So still negative classifications of spam filters, because it’s not an FQDN → still no option for me anyway.

If it’s so hard to simply add a small option to the eM Client settings here, if this behaviour shouldn’t be changed by default, then I’d rather use well-known software like Outlook or Thunderbird, which doesn’t include such strange deviations that I haven’t seen before.

I’m sorry, but I think that doesn’t seem to lead to any result here. I’m not going to repeat my arguments anymore. If nothing changes, then I and my employees will not use this software. Too bad, but then that’s the way it is. I’m not going to change my entire client network naming just for this. Apart from the fact that it is then still not an FQDN.

1 Like
12

I would also like to mention this: You can have a look at the English and German Wikipedia article about Message ID (Message-ID - Wikipedia and Message-ID – Wikipedia). The German one is more detailed and you can translate it. In both cases it says that the domain should be used as the right part after the @ in the message ID.

The German Wikipedia article is more detailed, refers directly to the RFC standard and says that it should be a domain or a globally unique IP address. It can be the FQDN of the sending computer, but not the hostname - it should be a fully qualified domain name! The hostname is not an FQDN. Btw, even when you manually set an FQDN on Windows, eM Client still only uses the hostname of the computer.

Quote from the English article:

A common of method of generating such ID is by combining the time and domain name, for example: 950124.162336@example.com.

Quote from the German one, translated to English:

A domain name or globally unique IP address forms the part to the right of the @ sign. This can be the fully qualified hostname of the sending computer, or any other domain for which the sender can guarantee the global uniqueness of the message ID.

It also says that in practice often, but not always, the sender domain is used as the right part of the message ID. As I said: So far I haven’t seen anything else and apparently this is rather the standard than the hostname of the sending computer. Again: Hostname != FQDN. That matches with the fact that the spam filter doesn’t like that too. Have a look at the example on the Wikipedia articles - it’s an FQDN, not just the sender’s hostname (e.g. “Windows-Client-XYZ”).

And even the official RFC 5322 says:

The message identifier (msg-id) itself MUST be a globally unique identifier for a message. The generator of the message identifier MUST guarantee that the msg-id is unique. There are several algorithms that can be used to accomplish this. Since the msg-id has a similar syntax to addr-spec (identical except that quoted strings, comments, and folding white space are not allowed), a good method is to put the domain name (or a domain literal IP address) of the host on which the message identifier was created on the right-hand side of the “@” (since domain names and IP addresses are normally unique), and put a combination of the current absolute date and time along with some other currently unique (perhaps sequential) identifier available on the system (for example, a process id number) on the left-hand side.

That’s what I’ve been talking all the time! It says “domain name” and not “hostname”. Hostname don’t even contain dots, because they aren’t domain names. Btw, what do you think is more unique in a mail system? A public domain or just a simple local Windows hostname, which everyone can assign freely on their LAN (e.g. “Windows-Client-XYZ”)?

Now I would like to read comparable arguments from you. Not just references to posts from people in this forum. I really don’t want to be rude, but when it comes to something like this, I go by official standards. Other people and spam filters too, obviously. So, I can absolutely not understand such posts and the behavior of the eM Client. I would like to hear the opinion of the developers of the eM Client after this post, which I have supported with sources.

2 Likes
13

2 years have passed and things are still there
I offered to make a check boxing for Message-id settings
there probably work for an 1-3 hour - they haven’t done it in 2 years)
they do not want to change anything - even if it is a loss of many potential customers for them

1 Like
14

@Gary and @cyberzork, it’s your personal choice if you don’t have a problem with your local PC names shown in your message IDs, but it seems to me that @SolusVM is right. He quoted the paragraph from RFC 5322 about the required uniqueness of a message ID. Regardless of whether you ‘like’ your PC name to be part of the message ID or not, how do you ensure uniqueness of message IDs if the right part is a computer name that is most probably not unique? My computer name is “PC”; I am not sure whether that is unique worldwide. Even if both options are valid, i.e. domain or local pc name on the right-hand side of the message ID, why not leave the choice to the user? Using the FQDN is certainly valid. Or is there anything that I don’t understand?

1 Like
15

If you don’t want to take this issue up directly with eM Client, then I think that is the best solution.

Going on and on and on serves no purpose other than to create discord among fellow users.

1 Like
17

I won’t get emotional about this, but there is still no pertinent, factual response in this discussion to the issue that was raised. You mentioned above that using the computer name is an “approved standard”. What’s your reference? The domain name is the recommendation in RFC 5322 and a widely used standard, at least used by various major MUAs.

1 Like
18

Yes, that is really a pity. I’ll contact eM Client again directly if this is possible without already buying the Pro version and see if something like this is possible. I also can’t imagine that the effort would be particularly high.

That’s exactly what I mean, thank you. I already wrote an email to the sales department of eM Client, because my purchase decision depends on it. But I guess I’ll contact eM Client again separately if this is possible without already buying the Pro version and ask if such an option in the settings can be implemented or if this behaviour can be changed in general.

Yes, but the reason I kept bringing this up in new replies to my post here is because you wrote that using the local computer name is the standard, but didn’t specify an RFC standard or anything else as a really valid refernece (just the fact that someone else has also written this here before). It’s exactly what @eisbaer said.

1 Like
19

Hi everyone,
using the device name in the Message ID is a standard following the RFC 5322.

The message identifier (msg-id) itself MUST be a globally unique
identifier for a message. The generator of the message identifier
MUST guarantee that the msg-id is unique. There are several
algorithms that can be used to accomplish this. Since the msg-id has
a similar syntax to addr-spec (identical except that quoted strings,
comments, and folding white space are not allowed), a good method is
to put the domain name (or a domain literal IP address) of the host
on which the message identifier was created on the right-hand side of
the “@” (since domain names and IP addresses are normally unique),
and put a combination of the current absolute date and time along
with some other currently unique (perhaps sequential) identifier
available on the system (for example, a process id number) on the
left-hand side. Though other algorithms will work, it is RECOMMENDED
that the right-hand side contain some domain identifier (either of
the host itself or otherwise) such that the generator of the message
identifier can guarantee the uniqueness of the left-hand side within
the scope of that domain.

When the message is created via a desktop client on your device, the device name is the domain name.
The email address domain name is that name when you create the message on webmail, for example.
This is the standard that was used for nearly every email client for many years now (followed by Thunderbird and Outlook in older versions as well) which is why eM Client keeps using it.

I will add the idea to our feature request again so our developers can reconsider this naming convention or adding additional options in the future.

For any pre-purchase questions you can always reach out to [email protected] or [email protected]

Regards,
Olivia

5 Likes
20

Hi Olivia,

thank you for the answer. RFC 5322 is correct and “the domain name (or a domain literal IP address) of the host on which the message identifier was created” is the right point. It says “domain name” and eM Client currently uses the host name, not the domain name. Something like “Peter-PC” is a host name of a computer, but definitely not a domain.

The “domain name of the host” is not the same as the “host name”. If my computer is inside the internal domain int.my-domain.com and eM Client would use my internal domain int.my-domain.com in the message ID, it still wouldn’t be the best choice in my opinion (the external mail domain would be better), but it would be way better than using just the clearly not globally unique host name of the computer. A host name does not contain any dots by design and can therefore never be a domain name or an FQDN.

It’s important not to confuse domain name and host name or “domain name of the host”. The host name is everything but not globally unique and that’s important for the message ID.

Then I wonder why Thunderbird as well as Outlook and other MUAs use my external mail domain in all of my tests. No matter whether it’s my own business mail server or, for example, Google Workspace. And why spam filters like rspamd don’t like Non-FQDN-Message-IDs either. I still remain with my argument that the host name of the computer is never the same as the domain name or the domain name of the host (“of”) - whether it’s an internal or external domain.

I hope that this will change or at least there will be an option for this in the eM Client. The latter would satisfy both sides. Until then, I can’t use the software (unfortunately), but I’ll keep an eye on it and buy the licenses as soon as something has changed here very frequently. Thank you very much for forwarding it to your developers! If something like this will be implemented, I think the eM Client would be perfect and I’d be happy to use it.