• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:
    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.

Resolved Email encoding after upgrade to 18.0.65

M

manteca

New Pleskian
Server operating system version
Ubuntu 22.04.5 LTS
Plesk version and microupdate number
Plesk Obsidian 18.0.65
Hello,

This morning we updated to version 18.0.65 and the emails sent with the phpMailer library have started to arrive with strange characters when everything worked correctly before.

Here are some examples:
Tel��fono
Asunto: Informaci��n
Pa��s
 
After the update to version 18.0.65 i got a problem with sending emails.
I send messages to Germany in German and so a many special characters are used.
I did not change anything in the sending software.
But after the update to 18.0.65 these characters are not shown good anymore.

2024-10-30_20-28-14.png
This was yesterday.
Today it is shown :
2024-10-30_20-27-51.png
You can see the differnce.

Looks like the encoding is wrong, but how can i change this, or is this a BUG??

Henk
 
Can confirm.
We've also got the problem with incorrect email (html, multipart) encoding of umlauts and special chars after updating to 18.0.65.
It's obviously a serious bug.
 
I can confirm this problem/bug on at least our Debian 11 servers (maybe a side effect of the PPPM-14624 fix?)

Did not dig to much into the details yet, but seems to also happens on receiving emails, when they get forwarded to a second mail address. (on same server)
 
I have the same problem. I was in the wrong forum when I posted it.

Issue - After upgrading to 18.0.65 charset mail problems

Hello, This morning we updated to version 18.0.65 and the emails sent with the phpMailer library have started to arrive with strange characters when everything worked correctly before. Here are some examples: Tel��fono Asunto: Informaci��n Pa��s
talk.plesk.com talk.plesk.com
 
Hey, everyone. We are sorry to hear about the issue you are all experiencing. I discussed the case with our team and we are currently investigating it. I will keep you posted on the matter.
 
Hello
1. We use Postfix
2. Problem existed for emails sent both from mail clients like thunderbird and online php forms. From webmail things are better, we think there is no problem there.
3. We have no clue about this.

Some more info: yesterday when the problem arose, we thought it was a thunderbird issue in combination with the email signature and the email's format. In thunderbird, we found that when the email was sent both as html and plain text the problem arose. So when we changed the setting to only send emails as html to problem disappeared. My conclusion was that a problem exists in multipart emails, international characters and encoding. (Sorry for my bad english)
 
This bug also indicates that Plesk Obsidian does not appear to be the server admin panel of choice for Plesk’s own team when managing their services. Otherwise, this bug would have been identified by Plesk immediately, rather than by its users. It’s disappointing to see.
 
For one of our customers we solved the problem at roundcube only when we set roundcube to use MIME encoding for 8-bit characters. So my main conclusion is that "default values" about encoding have changed somewhere into email functionality since the last update. It is really annoying, some customers may have the problem and may have not noticed it yet, we cannot find a proper workaround for everyone and we are in the dark.
 
Hangover2 said:
This bug also indicates that Plesk Obsidian does not appear to be the server admin panel of choice for Plesk’s own team when managing their services. Otherwise, this bug would have been identified by Plesk immediately, rather than by its users. It’s disappointing to see.
Click to expand...

That's a bit harsh. Let's give the developers a chance to identify the bug and understand what’s causing the issue before jumping to conclusions. Plesk is a complex system, and sometimes unexpected issues pop up in specific setups. A bit of patience could go a long way here.
 
Hello, everyone. The investigation is still ongoing. All I can say for now is that the issue is most likely related to the outgoing mail control being unable to re-encode the mail. As a possible workaround, could you please try disabling Tools & Settings > Mail Server Settings > "Turn on limitations on outgoing email messages" if it is enabled. I cannot guarantee that will solve the issue, but we observed it does for some users.
 
But there will be a solution for enabled outgoing mail limits, right? This is an essential feature for standard operations.
 
I can confirm this Problem. But the wrong characters only appear for me when the email is sent with an attachment. Without an attachment this problem doesn't exist. As a workaround, switching off "Turn on limitations on outgoing email messages" helped.
 
Maarten said:
That's a bit harsh. Let's give the developers a chance to identify the bug and understand what’s causing the issue before jumping to conclusions. Plesk is a complex system, and sometimes unexpected issues pop up in specific setups. A bit of patience could go a long way here.
Click to expand...
Yes, maybe a bit harsh, but Plesk is ignoring the community’s desire for a more stable update management. There are already several threads about this. The hosting business needs stability first, stability second, and stability third.

Currently, Plesk does not have a stable release line that only receives bug fixes. Each month, new features are mixed with patches, leading to severe issues multiple times per year. Additionally, there is no way to roll back an upgrade if the version is unstable.

For that reason, we are still using Plesk Obsidian 18.0.63 Update #4. We feel like beta testers for the software we pay for. Ideally, I would like a stable release line that only receives bug fixes. New features could be bundled into a yearly or semi-annual feature release, while the stable release remains supported for at least six months to a year.

Alternatively, instead of releasing a new version every month, Plesk could test each version on its own infrastructure first, using release candidates (RCs).

Currently, we’ve opted to disable Plesk auto-updates to avoid losing clients, as the hosting business doesn’t tolerate mistakes. We typically begin our internal testing of a release only after Update #3, when no major bugs are reported in the Plesk forum.

Another issue is that we don’t even have an open list of bugs and problems introduced with new versions. Greater transparency here would help us assess whether new bugs impact our client base.
 
You must log in or register to reply here.
Back
Top