If Content-Transfer-Encoding header is missing, body is shown as attachment

I’ve noticed that exclusively in eM Client some emails show their bodies as attachment.txt or attachment.htm and it’s confusing. I can’t tell which email really does have attachment.
I’ve tracked this issue to Content-Transfer-Encoding header. If it’s missing, body is shown as attachment.

According to RFC1341:

“Content-Transfer-Encoding: 7BIT” is assumed
if the Content-Transfer-Encoding header field is not present.

Message source that shows an attachment:

Resent-To: (...)
Resent-Message-Id: (...)
Resent-Date: (...)
Received: (...)
From: (...)
Date: (...)
Subject: (...)
Message-Id: (...)
To: (...)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8

Hello, this will be an attachment.

If I however add this line, then it won’t be an attachment.

Content-Transfer-Encoding: 7bit

I think it has more to do with the content, the way it is encoded, than that specific header. I tried this on a number of different messages, and without the Content-Transfer-Encoding header, I cannot reproduce this problem.

Are these messages sent from a specific email client?

No, but it may be perhaps related to IMAP provider seznam.cz being incompatible with eM Client? This happens quite often, for example from every email sent by popular platform Stack Exchange. 

I’ve tried writing C# program that sends emails through SMTP. Emails would always show attachment unless I added the Content-Transfer-Encoding header, this indicates eM Client treats emails with and without the header differently even though according to RFC1341 it should be identical.

If you have a Pro License, please open a support ticket directly with eM Client. They will be able to comment further.