Applicable to:
- Plesk Obsidian for Linux
- Plesk Onyx for Linux
Symptoms
-
Emails are not signed with DKIM in case they are sent using
mail()PHP function or mail utility, below information can be found in/var/log/maillog:CONFIG_TEXT: dk_sign[28686]: Starting the dk_sign filter...
dk_sign[28686]: DKIM error: DKIM Feed: Syntax error
plesk sendmail[28683]: Error during 'dd51-domainkeys' handler
postfix/pickup[27254]: 024B213A0AE6: uid=10000 from=<mail@example.com>OR
CONFIG_TEXT: check-quota[1337]: cannot get sender domain
check-quota[1337]: Unable to intialize check-quota mail handler
plesk sendmail[1381]: Error during 'check-quota' handler
postfix/pickup[6145]: 04655870621: uid=10000 from=<user@example.com> -
As a result mail is delivered to spam folder
Cause
Product issue:
-
#PPPM-6690 "Mail sent via the mail command is now signed with DKIM/Domainkeys if the sender’s domain name is the same as the server’s hostname and DKIM/Domainkeys are enabled for it."
Fixed in:- Plesk Obsidian 30 August 2021 (Linux)
Resolution
Workaround
If update is not possible for some reason you may try the following
As a workaround, specify email headers manually or submit a message directly through SMTP server. One of the following PHP scripts can be used as an example:
Comments
22 comments
It looks like the SMTP.php file is working pretty nice.
This heavy bug is still not fixed and can cause a lot of trouble if using your own mailserver,
Just one bug in the SMTP.php file i found, you forget to add the subject into the fputs.
Fix:
adding after: fputs($smtp_conn,"DATA\r\n");
This lines:
fputs($smtp_conn,"Subject: $YOURSUBJECT\r\n");
$data = get_data($smtp_conn);
Hello Daniel,
Thank you for your notice. SMTP.php has been updated with Subject line.
The same happens with emails that are being sent from the server when auto-reply is enabled in an email account. The email is being sent but not signed with DKIM. I just test it with Plesk Onyx Version 17.8.11 Update #38 on CentOS 6.10.
Do you think it is the same issue or should i post it on a new thread?
@George Klissiaris,
Hello! Seems like a different issue. Please check /var/log/maillog and use errors from there to find an appropriate article.
If no solution is found, you may contact support according to the article: https://support.plesk.com/hc/en-us/articles/213608509
This bug is from 2017. When will it finally be fixed?
Hello @Lars,
Currently, there is no ETA for this issue.
After fix being released this article will be updated.
Also, the information will be available at Plesk change log.
@Ivan
This is a huge bug, i mentioned a few times at the forum already and talked with developers on your help center months ago.
It really deserves a LOT more attention.
Your unable to use your own mailserver over PLESK for sending newsletter/order mails or even simple mails.
Some mailservers block not dkim signed messages or mark them as spam. For sure you wont have success like that if you dont implement a workaround.
Then just tell us: why so long? It's such a basic feature with big consequences.
Hello @Daniel and @Koert!
Thank you both for the feedback. Indeed the functionality is useful and vital for you.
Currently, the Development Team is concentrated on other functionality improvements and bugs. However, this issue is not abandoned and will be resolved, for now without the exact ETA.
any updates on this ?
@tech,
We still have no ETA about the update.
Follow the article to be notified once it's updated.
I can not understand why this bug has not been fixed until today.
We have over 5 servers with PLESK in operation and sendmail is an essential function for us and our customers.
Hello Max Bauer
According to Sendmail in particular, such emails are signed by DKIM since Plesk 18.0.22.
Hella Ivan Postnikow
Many thanks. We have upgraded to 18.0.27. Now sendmail DKIM seems to be working too.
What about for Postfix if you are not using Sendmail for the MTA? Seems not to be signing email. We have installed 18.0.28.
Hello Peter Ilias the issue occurs if you have Postfix mail server running and
mail()PHP function to send mail.Just realized I have this problem - using postfix and mail()
The SMTP.php script above along with links to 2 different articles detailing how to use a script with PEAR is a bit confusing. Is there a better description somewhere about how to use this? I have a VERY long and complex mail script that generates 2 different emails - one comes to us so I don't care how it's sent, but the other email goes to customers and those are now landing in the spam folder since I moved this domain onto my Plesk server.
Hello Kathy Sechrist
These instructions are everything we have available as this task is generally to be done by the website developer.
In case you have issues with the script, I suggest creating a topic at StackOverflow. Due to its huge community, there're high chances that you'll be provided with correct hints.
Dear Ivan Postnikov I can confirm this bug still happens when sending mails from the command line, which sometimes cannot be avoided. The duration it takes to fix such bugs is clearly something which needs to be improved - or otherwise make part of your software open source so that we developers can do it ourselves (or rely more on open source components, e.g. for DKIM signing).
B Pfleging
Indeed, this bug isn't fixed yet.
Thank you for the feedback, it will be delivered. RnD is resolving bugs in accordance with their impact and reoccurrence among the customers.
Still not resolved after more than 4 years albeit preventing the use of DKIM (as it is unknown if any customer might be using scripts that would trigger this bug, and you don't want to get yourself in trouble). This is sad...
From the changelog: "Mail sent via the
mailcommand is now signed with DKIM/Domainkeys if the sender’s domain name is the same as the server’s hostname and DKIM/Domainkeys are enabled for it. (PPPM-6690)"When you have a server hosting several customers' domains, how often will the server's hostname be the same as the sender's domain name? Probably zero times. This doesn't look like a reasonable fix =(
Please sign in to leave a comment.