POP3 UTF-8 Support Issue with Courier Mail Server

When retrieving emails via POP3 from my Courier mail server, some messages encoded in UTF-8 are not displayed correctly in eM Client. Instead, the email content is provided only as a file attachment, and the following message appears in the body of the email:

This E-mail message was determined to be Unicode-formatted
but your E-mail reader does not support Unicode E-mail.

Please use an E-mail reader that supports POP3 with UTF-8
(see RFC 6856 - Post Office Protocol Version 3 (POP3) Support for UTF-8).

This can also happen when the sender’s E-mail program does not
correctly format the sent message.

The original message is included as a separate attachment
so that it can be downloaded manually.

Expected behavior:
UTF-8 encoded messages should be displayed directly in the email body without requiring manual extraction from attachments.

Findings:
From my research, eM Client does support UTF-8 in general. I suspect that the client may not be correctly negotiating UTF-8 support with the mail server during POP3 retrieval—possibly by not issuing the command specified in RFC 6856.

Request:
Please investigate whether eM Client properly signals UTF-8 capability when retrieving messages via POP3, and implement the necessary adjustments if not. While POP3 usage may be less common today, I believe other users may also encounter this issue.

When retrieving emails via POP3 from my Courier mail server, some messages encoded in UTF-8 are not displayed correctly in eM Client. Instead, the email content is provided only as a file attachment.

That usually means the senders email is eg: “non standard in some way”, whether that be due to “the senders mail client” composing the message, or “something else in the senders email” that’s making it non standard to then not be able to display normally within the body of the email.

So suggest to find out why it’s not displaying correctly only as an attachment, go to “Menu / File / Export” and save and example email with the issue to a .eml file on your computer, and then if you have a current active paid Pro or Personal or Business version, go to the VIP support page and login and lodge a support ticket and “attach the saved .eml file” to be investigated.

Include “your version of eM Client” in the ticket, and if you are using Windows or Mac.

Also If you know “what mail client the sender uses”, include that in your ticket as well.

From my research, eM Client does support UTF-8 in general. I suspect that the client may not be correctly negotiating UTF-8 support with the mail server during POP3 retrieval—possibly by not issuing the command specified in RFC 6856.

From reading this forum threads back in 2011, @Filip_Navara from eM Client advised it sends in UTF-8 standard format, so I imagine it also reads standard incoming UTF-8 emails, and relies on the sending client to send in standard format.

I haven’t seen anything about how eM Client handles POP3 negotiating with UTF-8 on servers “when receiving mail” on this community forum, but someone from support may respond to that on this thread.

If it is a specific Courier Mail Server POP 3 UTF-8 authentication handling issue with eM Client “as you summised”, then eM Client support will advise you on what to do once investigated.

But I personally suspect if you are already using eM Client V9 or V10, “it’s more to do with the senders email client” or “something within the message itself” causing it and not eM Client.

1 Like