• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Issue psa-pc-remote: Error during 'dd51-domainkeys' handler

Greg Sims

Basic Pleskian
I'm running: 12.5.30 Update #61 on CentOS 7

We are using mailman for a subscription mailing list under Plesk -- "enable mailing lists" is set with three subscription lists created.

We turned on "Use DomainKeys spam protection system to sign outgoing email messages" for the domain last night. We have a large number of the following in the maillogs:

Mar 15 02:35:05 ray06 /usr/lib64/plesk-9.0/psa-pc-remote[19111]: Error during 'dd51-domainkeys' handler
Mar 15 02:35:05 ray06 dk_sign[16724]: DK_STAT_SYNTAX: Message is not valid syntax. Signature could not be created/checked

It appears that DomainKeys is working:

The Port25 Solutions, Inc. team
==========================================================
Summary of Results
==========================================================
SPF check: pass
DomainKeys check: pass
DKIM check: neutral
SpamAssassin check: ham

What needs to be done to address this? Thanks
 
Hi Greg Sims,

pls. check your DomainKey with for example: => https://protodave.com/tools/dkim-key-checker/
You are able to inspect the key - length, when you test the selector ( i.e. "default" ), which should meet 1024-bits - length.
You might experience the described error, if you upgrade from a previous Plesk version, where 768-bits - keys were generated. Try to switch off and back on the DomainKeys - signing for the domain and check again the key-length afterwards.

Even if it might sound strange for you, but a "reboot" of your server could solve as well the described issue.
 
Hi Greg Sims,

pls. check your DomainKey with for example: => https://protodave.com/tools/dkim-key-checker/
You are able to inspect the key - length, when you test the selector ( i.e. "default" ), which should meet 1024-bits - length.
You might experience the described error, if you upgrade from a previous Plesk version, where 768-bits - keys were generated. Try to switch off and back on the DomainKeys - signing for the domain and check again the key-length afterwards.

Even if it might sound strange for you, but a "reboot" of your server could solve as well the described issue.

Key length is good using => https://protodave.com/tools/dkim-key-checker/

KEY LENGTH (BITS): 1024
VERSION: DKIM1
KEY TYPE: rsa

Rebooting the server is a bit drastic. Perhaps we can try this when the load is load in the early morning. I sure wish there was another solution.

What is this error log entry telling us?
 
Hi Greg Sims,

What is this error log entry telling us?
well... eeehm.... sorry, but the error message is kind of insufficient, because it doesn't point to the root cause here. It might help to switch to debug - logging here, which could put some lights on the root cause.

Debug / verbose flags for postfix can be added as for example ( => /etc/postfix/master.cf ):
Code:
    smtp    inet    n    -    y    -    -    smtpd    -v
    smtps   inet    n    -    y    -    -    smtpd    -v
    pickup  fifo    n    -    -   60    1    pickup   -v
    cleanup unix    n    -    y    -    0    cleanup  -v
( the argument "-v" does the trick here. :) )​


Consider as well to use the command "plesk repair mail -y -v", if you don't want to restart the server at the moment, which "might" solve your issue.
 
Hi Greg Sims,

Consider as well to use the command "plesk repair mail -y -v", if you don't want to restart the server at the moment, which "might" solve your issue.

We restarted the server last night. We still have the same issue in the maillog. This seems to only happen for email sent by mailman. Is this a useful clue?
 
Hi Greg Sims,

you might be interested in reading: => https://sites.google.com/site/oauthgoog/mlistsdkim


If you desire to declare the current behaviour as a bug, pls. feel free to report this at: => https://talk.plesk.com/forums/reports.746/ ( and pls. don't forget to include eMail - headers from the sending eMail AND from the forwarded eMails to the mailing - list - members ).

From my point of view, I would rather suggest a feature request at => https://plesk.uservoice.com ( and again, pls. try to include as much as possible informations and include as well a buisiness case description. )
 
Hi Greg Sims,

you might be interested in reading: => https://sites.google.com/site/oauthgoog/mlistsdkim


If you desire to declare the current behaviour as a bug, pls. feel free to report this at: => https://talk.plesk.com/forums/reports.746/ ( and pls. don't forget to include eMail - headers from the sending eMail AND from the forwarded eMails to the mailing - list - members ).

From my point of view, I would rather suggest a feature request at => https://plesk.uservoice.com ( and again, pls. try to include as much as possible informations and include as well a buisiness case description. )

Hi UFHH01,

I noticed that you marked this thread as "Resolved". When software places two records into /var/log/maillog for each email sent, the system is Screaming for Help. I can't imagine that we can consider this thread to be resolved.

I've talked to the developers at mailman about this issue. It seems that the DomainKeys software you are using in Plesk is not pulling the correct information from the headers of the emails generated by mailman. This was not an issue on our RHEL 6 server with Plesk but it is here. This seems to be a regression in the way Plesk functions going from RHEL 6 to CentOS 7. Please note that we did NOT use the migration tools -- the CentOS server was built one domains at a time on a fresh install of the OS and Plesk.

With this additional information, perhaps you will see this issue as a "bug" and not a "feature request" -- as I do. I will repost this data to the link you have given above. In the mean time -- I would appreciate if you would change the status is the thread back to "Issue". I hope you agree that it is a more appropriate status.

Thanks, Greg

PS. The repost is now available on the referenced list above. I also changed the status of this thread back to "Issue".
 
Last edited:
Hi Greg Sims,

actually, I did some more research here and noticed as well some additional "default" settings at: => /usr/lib/mailman/Mailman/Defaults.py

Code:
# Some list posts and mail to the -owner address may contain DomainKey or
# DomainKeys Identified Mail (DKIM) signature headers <http://www.dkim.org/>.
# Various list transformations to the message such as adding a list header or
# footer or scrubbing attachments or even reply-to munging can break these
# signatures.  It is generally felt that these signatures have value, even if
# broken and even if the outgoing message is resigned.  However, some sites
# may wish to remove these headers.  Possible values and meanings are:
# No, 0, False -> do not remove headers.
# Yes, 1, True -> remove headers only if the list's from_is_list setting is 1.
# 2 -> always remove headers.
REMOVE_DKIM_HEADERS = No

You might consider to remove the DKIM_HEADERS from sending eMails, because you might experience issues here ( untested ), in combination with the own DKIM - signing.


I noticed that you marked this thread as "Resolved".
It IS indeed resolved, due to current situations and configurations and possible feature updates/upgrades. If the mentioned suggestion above might not help as well, there is actually nothing to solve, because "mailman" itself is a third party software and this forum is a "plesk-related Community". Even that you stated
I've talked to the developers at mailman about this issue. It seems that the DomainKeys software you are using in Plesk is not pulling the correct information from the headers of the emails generated by mailman
... please consider to add some facts here, which can be investigated, i.e. possible debug - logs from mailman, because the statement "It seems that the DomainKeys software you are using in Plesk is not pulling the correct information from the headers of the emails generated by mailman" is rather a guess, than anything else ( sorry ).
The "DKIM - signing" and "DKIM - checking" itself are done with vendor packages, only the hooks to get relevant informations for your logs for example are from Plesk.
 
Hi Greg Sims,

actually, I did some more research here and noticed as well some additional "default" settings at: => /usr/lib/mailman/Mailman/Defaults.py

Code:
# Some list posts and mail to the -owner address may contain DomainKey or
# DomainKeys Identified Mail (DKIM) signature headers <http://www.dkim.org/>.
# Various list transformations to the message such as adding a list header or
# footer or scrubbing attachments or even reply-to munging can break these
# signatures.  It is generally felt that these signatures have value, even if
# broken and even if the outgoing message is resigned.  However, some sites
# may wish to remove these headers.  Possible values and meanings are:
# No, 0, False -> do not remove headers.
# Yes, 1, True -> remove headers only if the list's from_is_list setting is 1.
# 2 -> always remove headers.
REMOVE_DKIM_HEADERS = No

You might consider to remove the DKIM_HEADERS from sending eMails, because you might experience issues here ( untested ), in combination with the own DKIM - signing.



It IS indeed resolved, due to current situations and configurations and possible feature updates/upgrades. If the mentioned suggestion above might not help as well, there is actually nothing to solve, because "mailman" itself is a third party software and this forum is a "plesk-related Community". Even that you stated

... please consider to add some facts here, which can be investigated, i.e. possible debug - logs from mailman, because the statement "It seems that the DomainKeys software you are using in Plesk is not pulling the correct information from the headers of the emails generated by mailman" is rather a guess, than anything else ( sorry ).
The "DKIM - signing" and "DKIM - checking" itself are done with vendor packages, only the hooks to get relevant informations for your logs for example are from Plesk.

I reviewed the mailman error logs -- per your suggestion. There are a hand full of unrelated errors over the last week that have to do with Robots hitting our Mailman lists -- this is not really an error, it is just informational. There is nothing in the mailman error logs that points to a DomainKeys issue. It seems that Mailman is creating email headers that it believes are in a correct format -- this has been reviewed by mailman development. We still do not understand, psa-pc-remote and dk_sign do not like the header format of the email that comes from mailman. I am not aware of a way to capture the email that is passed from mailman to the balance of the system. If you can tell be how to obtain this date, I would gladly post it. If you would like for me to provide something else specific for your review -- please just ask.

As I understand your suggestion above, "REMOVE_DKIM_HEADERS = No" will result in DomainKeys being seen for the ISPs as Neutral. I do not see this as a solution as we don't have an implementation that has DomainKeys enabled for Mailman generated email. This is the goal -- one that was achieved for RHEL 6/Plesk. Something has changed.

I'm doing my best to document an issue for the community. I putting a good deal of energy into this -- and so are you. I'm doing my best here. One question, have you asked Plesk development about any of the data we have to date? Perhaps the current maillogs could have all the information we need. They seem fairly detailed.

Thanks again, Greg
 
Last edited:
Hi Greg Sims,

As I understand your suggestion above, "REMOVE_DKIM_HEADERS = No" will result in DomainKeys being seen for the ISPs as Neutral. I do not see this as a solution as we don't have an implementation that has DomainKeys enabled for Mailman generated email. This is the goal -- one that was achieved for RHEL 6/Plesk. Something has changed.
No, sorry... I was imprecise here. The standart setting is set to "REMOVE_DKIM_HEADERS = No", which results in NO elimination of the previous DKIM - headers from the eMails of your subscribers. But this indead could interfear with the SIGNING of your own eMails, sent from your server, due to the fact that there are then double DKIM - entries, which can result in issues/errors/problems. This is the cause why I suggested to set this to: "REMOVE_DKIM_HEADERS = Yes", which will result in removing the DKIM - headers from your subscribers, but will certainly not interfere with the DK - Check and and DK - Signing on your server. :)
( I hope this more clear now - if not, pls. don't hesitate to reply on it ).

We still do not understand, psa-pc-remote and dk_sign do not like the header format of the email that comes from mailman.
Pls. note again, that "psa-pc-remote" doesn't "check or sign", it hands over the eMails... in this case, either to DK - CHECK, or DK - SIGN - and if DK - CHECK declares an error, DK - SIGN will refuse to sign ( both packages can as well being found as combined python packages = python-dkim ).


One question, have you asked Plesk development about any of the data we have to date?
No, I haven't contacted the Plesk developer, you might consider to ask such a question at a Plesk-Team-Member, ( i.e. @IgorG ) as I'm "only" a Plesk-Guru. :)


In addition:

Pls. use the command:

plesk sbin mail_handlers_control --list

... to list mail handlers queues and have a look at the additional informations from @VNick , to inform yourself about the Plesk configurations on your server:
Here's some info on the mail handler queues in Plesk. Note that the information below is actual for Plesk Onyx, although it is also mostly applicable to previous Plesk versions (with some small differences).

The following queues are available:
  1. before-data (0) — handlers are called before DATA in SMTP session is available (obviously, this triggers only within SMTP session);
    1. on QMail invoked from qmail-queue (no real difference from before-queue except these handlers are executed before before-queue ones);
    2. on Postfix invoked from Plesk milter (which is registered in Postfix as smtpd_milters, service name is pc-remote);
  2. before-queue (1) — handlers are called after DATA is available and before mail gets into mail queue (also SMTP session only);
    1. on QMail invoked from qmail-queue;
    2. on Postfix invoked from the Plesk milter;
  3. before-remote (3) — handlers are called before mail leaves this server (though they may be called in other cases as well), triggered for mail sent both via SMTP and sendmail;
    1. on QMail invoked from qmail-remote;
    2. on Postfix this is effectively equivalent to placing a handler both into before-queue and before-sendmail (except these handlers will be executed after handlers in both of these queues);
  4. before-sendmail (4) — handlers are called before mail is actually passed to sendmail (triggers only for mail sent via the sendmail utility);
    1. regardless of MTA handlers are invoked from Plesk sendmail wrapper which is actually called when the sendmail utility is used;
  5. before-local (2) — handlers are called before mail is delivered locally;
    1. on QMail invoked from qmail-local;
    2. on Postfix invoked from virtual_transport (called plesk_virtual, which calls postfix-local Plesk utility).
I think this should be enough to understand the behavior you're getting. Basically in your case, before-remote is called when mail gets into queue, before-local is called before mail is delivered.
 
Last edited by a moderator:
For the domain under study, this command yields the following:
  • name = dd51-domainkeys
  • type = sender-domain
  • queue = before-remote
This appears to be as expected. This seems to re-enforce asking Plesk developer to review the maillog data we have.

Perhaps @IgorG can help -- please see the log entries in #1. Thanks!
 
Back
Top