Resolved Email encoding after upgrade to 18.0.65

[Bitpalast]

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.

Yes, please. I support this.
New features are a nice-to-have, but the business is not about new features, but about reliability and trust. This can be achieved better by robustness of servers.

 

[ipapachristoudis]

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.

Well said.

Disabling auto-updates is step one during setup. On our part we follow a simple rule, we install updates about 2-3 weeks after published.

This one time we got hurry and problem emerged. Our new customers' first impressions are not the best. After the problem found we suggested two workarounds, not-workarounds for some though, which makes things worse.

 

[H.W.B]

I can confirm that turning off the 'Fix incorrectly set sender' solves the problem here.

 

[moswak]

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.

Yes, exactly, other than deactivating automatic updates, it's no longer possible. Bugs like this are rare, but something like this happens every now and then and it's just very annoying for many hosting customers.
If nothing changes in this regard in the future, more and more larger hosting providers will no longer use Plesk. Added to this is the price increase which gives the whole thing a very bad aftertaste.

 

[Maarten]

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.

I’ve been telling for years that Plesk should bring back their old Update Release Tiers, where they offered Early Adopter, General, and Late Adopter release options. It seems there’s something at the management level preventing this from happening, as I doubt the developers have much say in it.

I’ve also recommended for years disabling auto-updates and consistently staying at least one full release behind to avoid unexpected issues. It’s a setup that offers a bit more stability and allows time to assess any bugs that may emerge.

Could someone from Plesk please respond here and explain why there’s such a strong insistence on the current release update schedule? We keep seeing the same issues in this forum, with frustrated responses each time. What is it that makes Plesk unable—or unwilling—to acknowledge this ongoing feedback?

 

[ipapachristoudis]

Any updates???

 

[Hangover2]

Minor bug fix releases are normally published on Tuesdays.

 

[Sebahat.hadzhi]

Any updates???

The case is still under investigation. The issue is inconsistent and our team has several theories on what exactly is causing it. If you haven't already please consider disabling “Fix incorrectly set sender for outgoing mail“ and/or "Turn on limitations on outgoing email messages" until we can bring more clarity.

Could someone from Plesk please respond here and explain why there’s such a strong insistence on the current release update schedule? We keep seeing the same issues in this forum, with frustrated responses each time. What is it that makes Plesk unable—or unwilling—to acknowledge this ongoing feedback?

I will discuss this matter with our team on Wednesday and I will provide more details on the current release scheme and our future release plans.

 

[oskar.szafraniec]

https://support.plesk.com/hc/en-us/articles/27449227377303-Unicode-special-characters-in-messages-sent-from-Plesk-server-are-displaying-incorrectly-after-the-upgrade-to-Plesk-Obsidian-18-0-65-Failed-to-build-output-message-as-bytes-ascii-codec-can-t-encode-characters-in-position-X-ordinal-not-in-range-128

I will just leave it here for someone looking for solution... like me...

 

[H.W.B]

Hello,

Here the answer fron the support:

Our developers have confirmed the behavior as bug PPPM-14661 and the resolution is under way, although there's no ETA . The issue is related to the standard Python library email.

For the moment, the current workaround is to disable Outgoing Mail Control feature using the following steps:

1. Login into Plesk
2. Navigate to Tools & Settings > Mail Server Settings menu.
3. Uncheck Turn on limitations on outgoing email messages and Fix incorrectly set sender for outgoing mail options

 

[Ddungu]

Hello, any update regarding this problem as most of our clients are having a challenge.

 

[Sebahat.hadzhi]

Hello, any update regarding this problem as most of our clients are having a challenge.

If possible, please apply the workaround previously pointed in this thread. We are currently working on releasing a hotfix, which is scheduled for the 12th of November. Please note that I cannot confirm on a 100% the fix will be released as some unpredictable complications may arise.

 

[JVG]

Is there a way to enable/disable the limitations on outgoing email messages with a script? I would like to only disable it during office hours until the the bug has been fixed.

 

[bgptbg]

Das Problem, dass Umlaute und Sonderzeichen durch Fragezeichen ersetzt werden, tritt bei mir ausschließlich auf, wenn Thunderbird als E-Mail-Client verwendet wird und eine E-Mail mit Anhang gesendet wird. Outlook-Nutzer sind von diesem Fehler nicht betroffen. In den Mailservereinstellungen war die Option „Falsch festgelegten Absender für ausgehende E-Mails beheben“ bereits deaktiviert. Ich habe diese Funktion einmal aktiviert und dann wieder deaktiviert, um den Workaround zu aktivieren. In Kombination mit der vorübergehenden Deaktivierung der Begrenzung für ausgehende E-Mails scheint dies derzeit die einzige funktionierende Lösung zu sein.

Ubuntu 22.04.5 LTS, sowie Ubuntu 20.04.6 LTS

 

[Sebahat.hadzhi]

Is there a way to enable/disable the limitations on outgoing email messages with a script? I would like to only disable it during office hours until the the bug has been fixed.

You can enable/disable the settings with the following commands:

1. Turn on limitations on outgoing email messages:
   
   

   plesk bin mailserver --enable-outgoing-antispam
   
   plesk bin mailserver --disable-outgoing-antispam

   
   
2. Fix incorrectly set sender for outgoing mail:
   
   

   plesk bin mailserver --set-outgoing-messages-fix-sender true
   
   plesk bin mailserver --set-outgoing-messages-fix-sender false

Full documentation

What I can think of is creating bash scripts and configuring cron jobs for the desired times to enable and respectively disable the options.

 

[JVG]

You can enable/disable the settings with the following commands:

1. Turn on limitations on outgoing email messages:
   
   
   
   
2. Fix incorrectly set sender for outgoing mail:
   

Full documentation

What I can think of is creating bash scripts and configuring cron jobs for the desired times to enable and respectively disable the options.

Thanks, I'll do that.

 

[austriadesign]

Oh men (and ladies), I've wasted hours and days finding a solution with the support guys from the billing company Fastbill and my hosting provider HostEurope and both told me they can't see a problem in their billing php code or server wide until the guys from Danami sent me this conversation.

I hope the guys from Plesk could fix this next week. Wish you guys luck

 

[computermobil]

Yes, it seems that the bug is only with Thunderbird as email client, and also the workaround semms to work in the moment as you can see in the screenshot.
But still hoping for an update.
Thank you!

 

[austriadesign]

Yes, it seems that the bug is only with Thunderbird as email client, and also the workaround semms to work in the moment as you can see in the screenshot.
But still hoping for an update.
Thank you!

Ps.: Looking for a hotel in Austria? ;-)

It's not only a Thunderbird issue as the mail encoding issue also exists in Apple Mail, Roundcube, Gmail. Maybe Office365/Outlook/Live handles the En/Decoding more ›failsafe‹.

 

[computermobil]

It's not only a Thunderbird issue as the mail encoding issue also exists in Apple Mail, Roundcube, Gmail. Maybe Office365/Outlook/Live handles the En/Decoding more ›failsafe‹.

Thank you, i only tested with this Windows inbuildt Mail, there it worked. Any, should be fixed asap.