Resolved Spoofed mail gets DKIM signed

[ToastingTechnology]

Server operating system version

Debian 12

Plesk version and microupdate number

Obsidian 18.0.61 Update 6

Hello,
I may have found a bug with the signing of DKIM. This occurs if the spoofed sender and the recipient are on the same server, then the mail is signed by Plesk via DKIM.

To explain it better an example: ([email protected] is a valid mailbox on the server.)
If a mail is send from any other device with the recipient [email protected] and the sender [email protected], for example with the following command:
echo "Message body" | mail -s "Subject" -r "<[email protected]>" [email protected]
The mail will be in the mailbox with a valid DKIM signature. This also works when sender and receiver are different, but still on the same server.

If this is intended behavior, I don't quite understand why it should be like this. Because a spam mail appears to be valid, apart from an SPF fail.

 

[Kaspar@Plesk]

Any system user with SSH access (expect chrooted user) can sent email via sendmail from any domain on the server and get it DKIM signed. Like with the command line example you posted. There is no authentication. This is a feature, not a bug

However when sending mail from a subscription (for example with PHP) using a different domain from another subscription as a sender the message won't get DKIM signed. You can even prohibit the sending of mail from a different domain altogether by enabling the "Fix incorrectly set sender for outgoing mail" option in the Mail Server Settings.

 

[ToastingTechnology]

I mean that this command can be executed from any PC that is not the server. For example, I could execute the command from a PC at home which has nothing to do with mails.

I hope it's clear what I mean... English is sometimes not so easy!

 

[Kaspar@Plesk]

I assume that would mean that you have a mail server running locally which also signs the message with DKIM? If it does that with a valid private key then that DKIM authentication would be valid too. However that's outside the control of Plesk.

 

[ToastingTechnology]

No, the PC has nothing to do with a mail server. I have just created a new Debian VM for testing purposes, in which I have only installed sendmail and mailutils. I did not change any configuration or DKIM keys in the domain or on the server. Nevertheless, I was able to send a mail which then had a valid signature when it was received.

 

[Kaspar@Plesk]

I am not familiar with mailutils. How does that sent out the message? And how does the message get DKIM signed? I would assume that the message still gets routed trough the Plesk server (or any other server) via SMTP that signs it with a DKIM signature.

Without more details it's hard to comprehend what's precisely happening.

 

[Mark_NLD]

Perhaps it would be best to share an example e-mail using the Newsletters spam test by mail-tester.com method?

 

[ToastingTechnology]

Mailutils provides the mail command, as far as I know, it then uses sendmail internally.

And the flow is as follows: A mail is sent from a PC/Server without SMTP login, or any DKIM signing possibilities. The sender and the recipient of the mail are on the Plesk server. This mail is signed in the mailbox of the recipient.

If the sender address does not exist in Plesk or the sender Domain hasn't DKIM activated, it will not be signed.

This mail is also not routed through other servers, it goes directly from the PC to the Plesk server.

I hope it's clear by now what I mean, because I don't know how to describe it better. Maybe someone could try out what I am describing.

And I'm not sure, how the spam test could be helpful. Since the problem is exclusively in the mailbox on the Pleskserver.

 

[Kaspar@Plesk]

This puzzels me. Can you maybe help me with a list of all the exact steps to replicate the issue? For example like:

1) Install Debian on VM without Plesk
2) Install mailutils with sudo apt install mailutils
ect

 

[ToastingTechnology]

Sure:

1. Create a Debian VM with the latest version
   1. I used the installer in text mode
   2. The computer name must be an FQDN
   3. No desktop environment or standard system tools installed
2. Login as root
3. Install sendmail and mailutils: apt install sendmail mailutils
4. Send test mail and exchange [email protected] for the real mail address
   echo "Body" | mail -s "Subject" -r "<[email protected]>" [email protected]

 

[Kaspar@Plesk]

Thank you @ToastingTechnology, much appreciated.

A couple of questions about your setup:

• [email protected] would be an mailbox on the Plesk server and DKIM should be enabled for the test.de domain, right?
• There are no mail servers (posttfix, Qmail, ect) installed in the Debian VM. Is that correct?
• Both the Debian VM and the Plesk are on a differen network, is that right?

 

[ToastingTechnology]

Thanks for trying it out, I hope you can reproduce it.

• That is correct.
• None installed by me. I have not checked whether any are installed during the installation of sendmail and mailutils.
• That is correct.

 

[Kaspar@Plesk]

We've been able to replicate this behavior thanks to the details you provided and internally created issue report PPPM-14524 and SEC-61355 for it. Much appreciated. The message gets signed with the DKIM signature on the Plesk server upon receiving the email due to the order in which received emails are currently handled.

The first and most important recommendation to mitigate this issue is to use strict and proper SPF and DMARC policies to prevent emails being accepted from unauthorized servers. As an additional method of prevention you can consider enabling the mail_dmarc_reject_at_smtp option. Depending on the DMARC policy this will reject any email at SMTP level if the DMARC policy is set to reject or, when a different DMARC policy is used, will fail Authentication-Results of the message (but DKIM signature still gets added to the received message).

To enable the mail_dmarc_reject_at_smtp option you can run:

plesk bin settings -s mail_dmarc_reject_at_smtp=true
plesk repair mail -y

Another option to completely mitigate this issue (if you wanted to) would be to switch to qmail as the MTA in Plesk.

 

[ToastingTechnology]

Thanks for the feedback and suggestions. I will adjust the SPF settings.

For me, this topic can be marked as solved.