• 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

Hangover2 said:
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.
Click to expand...
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.
 
Hangover2 said:
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.
Click to expand...
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.
 
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.
Click to expand...

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.
 
Hangover2 said:
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.
Click to expand...

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 said:
Any updates???
Click to expand...
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.

Maarten said:
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?
Click to expand...
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.
 
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 said:
Hello, any update regarding this problem as most of our clients are having a challenge.
Click to expand...


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.
 
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.
 
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
 
JVG said:
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.
Click to expand...

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
    Click to expand...

  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
    Click to expand...

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.
 
  • Like
Reactions: JVG
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
 
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!
 

Attachments

  • plesk-screen.png
    plesk-screen.png
    81.5 KB · Views: 6
Last edited by a moderator:
computermobil said:
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? ;-)
Click to expand...
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‹.
 
austriadesign said:
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‹.
Click to expand...
Thank you, i only tested with this Windows inbuildt Mail, there it worked. Any, should be fixed asap.
 
You must log in or register to reply here.
Back
Top