Received headers being removed?

I am evaluating eM Client.
When I look at Full headers or Source of an email I am not seeing all the Received headers that  I usually see in other email clients.
I assume they are being stripped out from all emails except the last one which is the fetch from my mail server.
I find being able to view these headers very useful to be able to see which ciphers my email client and mailserver are using and also for finding IP numbers of mailservers that I wish to block in my own mail server.
Also to check which version of TLS is being used along the route, which begs the question, is emclient TLS 1.3 enabled yet?

Is there any chance the headers could be put back in or have an option not to remove them? and when will emclient be TLS 1.3 enabled?


eM Client will not remove the headers. Maybe something to ask your email provider?

I am my own email provider, I run an email server from my PC.
I checked and it is only when I send to myself that I don’t see the received headers. I hadn’t noticed that my mailserver does that before. I see them when sending to an external email address.

What about TLS 1.3 ?
Any target date for it being implemented?


When you are sending to yourself, are you maybe not just looking at the sent message. That will have basically no headers at all. Turn off conversations using Menu > View > Conversations, then look at the received message and see if your server has added headers. There should be something.

I asked one eM Client employee to comment about TLS 1.3. As far as I know eM Client does support that, but we will need to wait for confirmation.

I’m looking at the received message.

TLS 1.3 is working for me with some email servers and my mailserver supports it, and I have all the TLS 1.3 ciphers from openssl in my mailservers list of ciphers.
So far I haven’t seen TLS 1.3 being used by emclient,

Yes, I had a look at messages sent only on the same internal network, and it appears that the header is a little shorter than otherwise. I guess because the message is not passing through many servers, there is nothing more to add. 

You can of course send a message that will travel outside of your network, and see what headers are added by the other servers. A useful test is to send a message to an echo server, which will return the full header information as a reply message to you. A reliable one is [email protected]

That is useful.

eM Client is using cipher: ECDHE-RSA-AES256-GCM-SHA384 to send to my server which is TLS 1.2
Then server to server it uses: TLS_AES_256_GCM_SHA384:256 which is TLS 1.3 (  thats my server to  )

So eM Client is not using TLS 1.3 for me.

I’m still not sure if TLS 1.3 is enabled yet or whether I’m waasting my time trying to find out


One of the problems of not having a changelog is that, as users, we don’t know what has been implemented without exhaustive testing on every new release. I guess we need to wait and see what eM Client has to say.

An interesting tool to test what servers support is I tested my email provider (takes a while to complete the test) and they don’t support TLS 1.3 (yet).

The main reason for me moving to eM client would be the availability of TLS 1.3. I know it will happen but not when.
In the mean time I could use Thunderbird but it would be a pain to switch and then have to switch again.


Hello Rob,

In eM Client, the TLS 1.3 introduction depends on the availability of the full documentation as well as its support in .NET/Win system. By now, it should be available in the last update of Win 10 so once it’s fully supported by .NET, we can introduce TLS 1.3 in eM Client.


OK, Thanks Russel.
I’ll assume it’s pending for in the not too distant future. I can hang on until then, although I have just discovered that the source code of my current email client has gone open source so I may be able to make that work with TLS 1.3 if it’s not beyond me.