• Debian 11 is approaching its end-of-life (vendor EOL date - August 31, 2026). Plesk Obsidian 18.0.80 will be the last release to support it.
    If you are running Plesk Obsidian on Debian 11, we recommend you upgrade those servers to Debian 12 using our dist-upgrade tool.
  • We plan to deprecate and remove the support for XML RPC protocol versions earlier than 1.6.9.1 in Plesk Obsidian 18.0.82. We strongly recommend that you update all existing integrations using earlier versions of the XML RPC protocol to comply with the version 1.6.9.1 specification.

Issue Reproducible Plesk Autoresponder crash – Poco::Net::MessageException / SIGABRT

dwoderso

New Pleskian
Server operating system version
Debian 11
Plesk version and microupdate number
Plesk Obsidian 18.0.80 #3
First of all, I have to point out that I find Plesk's current support policy extremely frustrating and, frankly, unacceptable.


I am a paying Plesk customer, yet I apparently have no straightforward way to report a reproducible bug in Plesk itself simply because my license was obtained through a reseller.


I fully understand that a reseller may be responsible for customer support regarding the services they provide. But this issue has absolutely nothing to do with the reseller. The problem is a reproducible crash in Plesk's own autoresponder component.


The reseller did not develop the Plesk autoresponder, cannot fix a Poco::Net::MessageException inside /opt/psa/handlers/hooks/autoresponder, and has no meaningful way to investigate or correct a defect in Plesk's software.


Nevertheless, I am being told that I have to contact the reseller in order to report this issue.


So, to put it bluntly: I am paying for Plesk, I have identified and documented a reproducible bug in Plesk itself, and yet Plesk apparently provides me with no direct way to report that bug unless I either go through a third party who has nothing to do with the defect or purchase an additional support subscription.


I find that extremely difficult to understand.


I am not asking for help configuring my mail server. I am not asking the reseller to troubleshoot a customer-specific configuration. I am reporting a reproducible software defect in Plesk itself, including the exact exception, the affected Plesk component, and the resulting process crash.


There should be a direct mechanism for paying customers to report reproducible software defects to Plesk, regardless of whether the license was purchased directly from Plesk or through a reseller.


I therefore hope that someone from Plesk can forward this report to the appropriate development team.

--- START OF BUG REPORT---

Hello,

I believe I have found a reproducible bug in the Plesk mail autoresponder.

This is NOT a configuration question. The Plesk autoresponder process itself crashes while processing a successfully accepted and delivered email.

Environment:

Plesk Obsidian 18.0.80 Update 3
Web Host Edition
Debian 11 (Update planned!!)

The autoresponder is enabled and configured correctly for the affected mailbox.

A normal email delivered directly to the Plesk mailbox works correctly and triggers the autoresponder.

However, when an email is sent to a GMX.de mailbox and subsequently forwarded by GMX.de to the Plesk mailbox, the email is delivered successfully, but the Plesk autoresponder crashes.

Relevant log:

postfix-local: autoresponder: stderr:
terminate called after throwing an instance of
'Poco::Net::MessageException'

postfix-local: autoresponder: stderr:
what(): Malformed message

postfix-local:
_mh_fork(/opt/psa/handlers/hooks/autoresponder):
The child process was killed by signal 6

The message is subsequently delivered successfully:

status=sent (delivered via plesk_virtual service)

The same Plesk mailbox and autoresponder work correctly when the message is delivered directly without the GMX forwarding step.

The problem was originally observed on Plesk 18.0.79.

The server has since been upgraded to:

Plesk Obsidian 18.0.80 Update 3

The problem is still fully reproducible after the update.

The forwarded message has the expected characteristics of a forwarded email: the SMTP envelope sender differs from the original From header.

The important point is that Plesk accepts and delivers the message successfully. The crash occurs specifically inside:

/opt/psa/handlers/hooks/autoresponder

The process terminates with SIGABRT due to:

Poco::Net::MessageException
Malformed message

This happens with multiple independently forwarded messages.

Expected behavior:

The autoresponder should process the forwarded email normally and generate the configured automatic response.

Actual behavior:

The autoresponder process crashes and no automatic response is generated.
 
Hi, @dwoderso . First, to acknowledge your complaint. I understand why this situation can be frustrating, particularly when you have identified what appears to be an issue with Plesk itself. The distinction here is not about whether Plesk considers the issue important or whether a reseller could technically fix it. It is about how support is provided for licenses purchased through different sales channels. When a Plesk license is purchased directly from Plesk, direct Plesk technical support is part of that purchase. When a license is purchased through a Plesk reseller, the reseller is the customer's first point of contact for support. A reseller does not need to be the developer of the affected component in order to act as the support channel. If an issue requires investigation by Plesk, the reseller can escalate it to Plesk. Please note that this model is not unique to Plesk. Software vendors commonly distinguish between licenses purchased directly from the vendor and licenses supplied through a partner or reseller, with the partner providing the customer's first-line support.

At the same time, Plesk does provide other ways for users to report potential product defects through the official community channels - the forum (which you already found) and the Facebook group.

Secondly, regarding the report - thank you for bringing the potential issue to our attention. I personally was, unfortunately, unable to attempt to replicate the behavior, because regardless of what I tried (3 devices/2 different networks, Corporate VPN on/off, Personal (German-based location) VPN on/off) I was unable to create a mailbox at gmx.de. Nevertheless, I have opened an internal case for our engineers to further review the matter. I hope they won't bump into the same issue as me. I will follow up with more details as soon as possible. Your patience is appreciated in the meantime.
 
Back
Top