greek characters cannot be read (non UTF-8)
Categories
(Thunderbird :: Untriaged, defect)
Tracking
(Not tracked)
People
(Reporter: morfoan, Unassigned)
References
()
Details
(Whiteboard: [Plesk Obsidian])
Attachments
(6 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:132.0) Gecko/20100101 Firefox/132.0
Steps to reproduce:
I send e-mail in html format with greek characters
Actual results:
From 04 November The greek characters cannot be read from the people that receive my e-mail
Expected results:
To work as it used to work
Comment 1•1 year ago
|
||
Please attach a sample email, as .eml
Comment 4•1 year ago
|
||
Attached file TikTok.eml
There is nothing to display. All 8-bit characters have been replaced by the substitute character.
Please take a look at the copy in your Sent folder. Does it look the same?
You have forwarded another e-mail. Was the original e-mail displayed correctly? If the charset was already incorrect (or missing), this would explain the effect.
If the forwarded e-mail was displayed correctly, could you please attach it here?
Please remember that the content here is public.
Hi,
I have the same problem since the last version update (Nov. 6 - version: 128.4.2esr). When I send special characters to someone (in my case it's french characters), the all show up as "?" for the receiver.
Steps to reproduce:
I send an email to myself:
Subject: "Régulier"
Bodytext: "Régulier"
In my SENT folder the email looks normal and all characters are displayed correctly.
The email that I receive however has the "é" character replaced with "?", but only in the Bodytext. In the subject the word is written correctly.
Please see the two screenshots I attached to this issue.
This behaviour started last week. I sent an email to a customer on Nov 6th which was still OK, but starting Nov 7th the characters were screwed up. So I'm guessing this started with the latest version.
As I'm writing mostly in french, this is affecting ALL my emails basically ... so it's kind of urgent :D
I'm available if you have any more questions, or want me to test something.
Best,
Jens.
The e-mail i receive is readable and there is no problem with that.
When i send a new e-mail or when i reply to one or when i forward an e-mail, the Greek characters cannot be read and are replaced by non utf-8 characters as in the emal file i have attached.
I have many clients with the same problem with Thundebird from 04 of November.
Just clarify: in my example the received mail is the one that I sent to MYSELF ... emails that I receive from other sources are fine as well. The problem seems to be with the character encoding of SENT mails.
Try sending an email with greek characters to yourself, I bet they are scrambled as well.
Being a web developer myself, and having to deal with character encodings a lot, I think that Thunderbird somehow messes up the character encoding when sending the email. The only thing that is weird about that is, that the copy placed in my SENT folder is CORRECT, but the characters seem to be falsely encoded for the actual mail that goes out.
As another potential help for the developers I will attach two .eml files, which I'll call "sent" and "received" as well. It will be the same email in both cases, the copy from my "sent" folder, and the actual received one. When I open both of those up un Notepad++, both are reported to be "utf-8" encoded, but for the "received" ones the characters are scrambled (but only in the message part, not the subject).
Comment 10•1 year ago
|
||
Comment 11•1 year ago
|
||
Comment 12•1 year ago
|
||
(In reply to Jens from comment #9)
As another potential help for the developers I will attach two .eml files, which I'll call "sent" and "received" as well. It will be the same email in both cases, the copy from my "sent" folder, and the actual received one. When I open both of those up un Notepad++, both are reported to be "utf-8" encoded, but for the "received" ones the characters are scrambled (but only in the message part, not the subject).
Yes, thank you very much. If the e-mail in the Sent folder is OK, TB has sent it in exactly the same way. Then one of the servers involved has destroyed the 8-bit characters.
To avoid this, you can instruct TB to use only 7-bit encodings. To do this, you must set the Pref mail.strictly_mime to true.
See: https://support.mozilla.org/en-US/kb/config-editor
Comment 13•1 year ago
|
||
Yes - the received copy should be the same as the one in the sent folder (except for some added headers). Some intermediate is modifying the emails wrongly. That may be a server on the route, or some anti-spam solution etc.
Comment 14•1 year ago
|
||
Hi,
thanks (to the both of you) for replying. Before testing the "mail.strictly_mime" setting, I have sent myself another email to check whether the problem still persists, and to my surprise IT WAS FIXED.
So I checked my server (a dedicated Plesk Server which I manage myself) and I saw, that a **Plesk update was applied during the night ** (the update before that was indeed on Nov 7th, so I guess that update introduced the problem).
It was indeed (at least in my case) a Plesk issue, and NOT a Thunderbird issue. Below I'm sending you the link to the Plesk Change Log, the bug was fixed in version "Plesk Obsidian 18.0.65 Update 1 - 11 November 2024" and it states:
"Fixed the issue where, on Plesk servers with the “Outgoing Mail Control” and/or “Fix Incorrectly Set Sender for Outgoing Mails” features enabled, special characters (such as umlauts or accents) in multi-part messages could be replaced with other characters, such as “”. (PPPM-14661)"
https://docs.plesk.com/release-notes/obsidian/change-log/?18065-mu1#18065-mu1
That way, if somebody else has this problem, you can point them in the right direction.
@morfoan: I don't know if this also applies to you?
For me personnaly this issue is closed now, but since I'm not the original poster, I'll not speak for him :)
Best,
Jens.
| Reporter | ||
Comment 15•1 year ago
|
||
Hello
Today works as it use to be.
@jens: the problem was exactly that, when Plesk was updated the problem with the characters stopped
Regards,
Andreas
Updated•1 year ago
|
Description
•