Question Backup task notification email from PMMCli-Daemon always in Junk folder

Wolfgang Reidlinger · Nov 30, 2023

Hi there,
got some problems with the Backup task notification email from PMMCli-Daemon.
This emails are always inside the Junk folder (Webmail or EMail Client).
The sender email address is the same as the receiver email address.
This address it the administrator email address.
The domain used is also hosted (mail service) on this PLESK instance. So the email is actually never leaving the server.

Already tried the following:

adding the sender (PMMCli-Daemon) to the global whitelist inside the Spam Filter Set
adding the sender to the contacts inside the webmail

Please also have a look at the email source.

Code:

Content-Type: multipart/mixed; boundary="===============3167549208581624220=="
MIME-Version: 1.0
From: PMMCli-Daemon <[email protected]>
To: [email protected]
Date: Sun, 26 Nov 2023 05:03:15 +0100
Subject: Backup task notification
Message-Id: <[email protected]>

Anybody got some ideas?

Peter Debik · Dec 1, 2023

X-Spam-Status: No, score=-100.0 required=7.0 tests=NO_RELAYS,

A "-100" indicates that the mail was exempt from spam checking, e.g. whitelisted. SpamAssassin cannot have moved it into the junk folder. But maybe you have a filter defined in your mail client that reacts on certain keywords in the subject or body?

Kaspar · Dec 1, 2023

The email gets moved to the junk/spam folder because DMARC validation failed and the domain policy is to quarantine the message. This is indicated in the header of your email with the line below.

Wolfgang Reidlinger said:

From the headers of the email you posted it isn't entirely clear to me what causes the DMARC validation to fail. The FROM address and the Return-Path address seem to align (i.e are the same). Which is good. Perhaps DMARC fails because the message isn't signed with DKIM, but I am not sure.

You could try to ament the DMARC DNS record for the domain to include adkim=r. Meaning the DMARC check will validate the DKIM alignment 'relaxed' and won't fail the whole DMARC validation if the DKIM alignment fails.

If DKIM signing is enabled for the sending domain, you might want to adjust the DKIM Policy Record _domainkey.supertopleveldomain.org value from o=- to o=~ too. This will indicate that "some, but not all mails from this domain are signed". Which seems to to apply to your case, as the backup notification isn't DKIM signed.

I hope any of this helps.

Wolfgang Reidlinger · Dec 2, 2023

Thanks @Peter Debik for clarifying what the status

X-Spam-Status: No, score=-100.0 required=7.0 tests=NO_RELAYS,

actually mean. Very good to know for future troubleshooting!

Regarding the mentioned Filters, I did not set any Filters inside the Roundcube Webmail Service.

Wolfgang Reidlinger · Dec 2, 2023

Here you can see the Filters in Roundcube Webmail Service.

And here the Spam Filter Settings. No Black list or White list addresses.

Wolfgang Reidlinger · Dec 2, 2023

Thanks @Kaspar for the very good and technical analysis. Yes you are absolutely right.
Just did not think about this as an error because the emails is just "local".
This domain is currently under DEV and it looks like we have to adjust the SPF, DMARC and DKIM Records further.
Just changed the DMARC and DKIM policy record.

Bash:

_DMARC.supertopleveldomain.org. 300 IN    TXT     "v=DMARC1; p=none; sp=none; adkim=r; aspf=r"

Bash:

_domainkey.supertopleveldomain.org. 300 IN TXT    "o=~"

Will do some further testing and let you know if I was able to fix the problem.

Wolfgang Reidlinger · Dec 3, 2023

Just a brief update, event after the changes in dem DMARC / DKIM Records, the dmarc=fail status is still present.
Another backup task notification, this time caused by me to trigger the email notification.

Code:

Authentication-Results: hosting.supertopleveldomain.org;
    dmarc=fail (p=NONE sp=NONE) smtp.from=supertopleveldomain.org header.from=supertopleveldomain.org
Return-Path: <[email protected]>
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
    hosting.supertopleveldomain.org
X-Spam-Level:
X-Spam-Status: No, score=-0.0 required=7.0 tests=NO_RELAYS,
    T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: by hosting.supertopleveldomain.org (Postfix, from userid 0)
    id 79E24604A3; Sun, 3 Dec 2023 02:03:19 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============7260710710403931599=="
MIME-Version: 1.0
From: PMMCli-Daemon <[email protected]>
To: [email protected]
Date: Sun, 03 Dec 2023 02:03:19 +0100
Subject: Backup task notification
X-PPP-Message-ID:
    <170156539935.226692.17911255527926789761@hosting.supertopleveldomain.org>
X-PPP-Vhost: hosting.supertopleveldomain.org
Message-Id: <[email protected]>

Kaspar · Dec 3, 2023

Wolfgang Reidlinger said:
Just a brief update, event after the changes in dem DMARC / DKIM Records, the dmarc=fail status is still present.
Another backup task notification, this time caused by me to trigger the email notification.

Does the email still end up in the junk/spam folder? Because if you've set p=none to the DNS record, the email message should not get quarantined.

Wolfgang Reidlinger · Dec 3, 2023

Sorry @Kaspar I missed this part. You are right, the email is now delivered to the inbox. So to say the problem that the email gets to junk folder is fixed. Thanks for your help.
Just wondering, about the dmar=fail status.

Kaspar · Dec 3, 2023

Wolfgang Reidlinger said:
Sorry @Kaspar I missed this part. You are right, the email is now delivered to the inbox. So to say the problem that the email gets to junk folder is fixed. Thanks for your help.
Just wondering, about the dmar=fail status.

Thats good to read. I am not sure why the DMARC validation fails. Does the domain have a SPF record?

Wolfgang Reidlinger · Dec 4, 2023

Kaspar said:
Thats good to read. I am not sure why the DMARC validation fails. Does the domain have a SPF record?

Here is my SPF record:

v=spf1 a mx a:hosting.supertopleveldomain.org a:monitor.supertopleveldomain.org a:somecloud.supertopleveldomain.org mx:supertopleveldomain.org ip4:<IP of PLESK> ip4:<IP other email service> ~all

the MX record has an A record pointing to the PLESK server
hosting.supertopleveldomain.org as an A record pointing to the PLESK server

Just wired, because another notification email from PLESK informing me about the scheduled backup error.
This time not send by the PMMCli-Daemon by instead by the PLESK Admin - both uses the same sender email address.

Interesting enought, that this time the status is dmarc=pass, without changing anything on the DNS records or PLESK settings.

Code:

Authentication-Results: hosting.supertopleveldomain.org;
    dmarc=pass (p=NONE sp=NONE) smtp.from=supertopleveldomain.org header.from=supertopleveldomain.org;
    dkim=pass header.d=supertopleveldomain.org
Return-Path: <[email protected]>
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
    hosting.supertopleveldomain.org
X-Spam-Level:
X-Spam-Status: No, score=-0.2 required=7.0 tests=DKIM_SIGNED,DKIM_VALID,
    DKIM_VALID_AU,DKIM_VALID_EF,NO_RELAYS,T_SCC_BODY_TEXT_LINE
    autolearn=ham autolearn_force=no version=3.4.4
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: by hosting.supertopleveldomain.org (Postfix, from userid 999)
    id 7D3B26073C; Mon, 4 Dec 2023 02:50:27 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=supertopleveldomain.org; s=2023; t=1701654627;
    bh=Ye/Kf/jvbeV7jepmUl4If1Wg2nMaWO1VIFmXZa9AGoM=; h=To:Subject:From;
    b=kFyDzTQXSYkcQ8GtlJxE48vJazvgRo+p4t/lhhqGYkahbIXmDPxEfRKgtxwbW/nXh
    ****************************************************
    ltD5mFmu2nnzg==
To: [email protected]
Subject: =?UTF-8?Q?<hosting.supertopleveldomain.org>=20An=20error=20?=
    =?UTF-8?Q?occurred=20during=20the=20scheduled=20backup.?=
Date: Mon, 04 Dec 2023 02:50:27 +0100
From: =?UTF-8?Q?Hosting=20Admin?= <[email protected]>
Sender: <[email protected]>
Reply-To: =?UTF-8?Q?Hosting=20Admin?= <[email protected]>
X-Mailer: =?UTF-8?Q?PHP/8.2.12?=
MIME-Version: 1.0
Content-Type: text/plain;
    charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-PPP-Message-ID:
    <170165462737.838749.5234357422637439044@hosting.supertopleveldomain.org>
X-PPP-Vhost: hosting.supertopleveldomain.org
Message-Id: <[email protected]>

Looks like this time some additional email header fields like Sender: and Reply-To: got used.
Maybe the fact that this fields are missing in the emails send by the PMMCli-Daemon is causing the dmarc=failed status!?
Is it possible to add this email header fields in the notification emails send by the PMMCli-Daemon?

Kaspar · Dec 4, 2023

The Sender and Reply-To headers aren't part of the DMARC validation. So that isn't the reason DMARC fails.

DMARC needs either a valid DKIM or SPF check. Neither of those seems to have been checked on your first email (as both aren't mentioned in the headers). I am not sure why that is. It seems a bit odd to me, as with Plesk DMARC validation cannot be enabled without enabling SPF validation. Perhaps some one else on the forum knows?

However the the second email (of which you posted the headers) is DKIM singed (and validated). That's why DMARC validation does pass on that email message.

Wolfgang Reidlinger · Dec 5, 2023

Kaspar said:
The Sender and Reply-To headers aren't part of the DMARC validation. So that isn't the reason DMARC fails.

DMARC needs either a valid DKIM or SPF check. Neither of those seems to have been checked on your first email (as both aren't mentioned in the headers). I am not sure why that is. It seems a bit odd to me, as with Plesk DMARC validation cannot be enabled without enabling SPF validation. Perhaps some one else on the forum knows?

However the the second email (of which you posted the headers) is DKIM singed (and validated). That's why DMARC validation does pass on that email message.

Thanks again @Kaspar for your technical explanation. Since the SPF Record is correct (because the DMARC Check passend in the previous email) it must be the failed DKIM check. Is is possible to configure the PMMCli-Daemon to use a DKIM signature. A DKIM signature is already there and working for this email address it is just currently not used from the program logic.
To me it looks like it works as designed, means that is was never thought of that the PMMCli-Daemon using a DKIM signature.
Maybe somebody from DEV or product management can clarify this assumption?!

Kaspar · Dec 5, 2023

Wolfgang Reidlinger said:
[...] Since the SPF Record is correct (because the DMARC Check passend in the previous email) it must be the failed DKIM check. [...]

No no, that's incorrect. Sorry if I have caused any confusion here. The DMARC validation on your second email passed because the email is signed with a valid DKIM signature. Not because of SPF. Even though you have a SPF record for the domain, on both of your emails SPF has not been checked (otherwise SPF validation would have been mentioned in the headers).

Your first email failed DMARC validation because it's not DKIM singed, nor has there been a validation for SPF. DMARC need al least one of these checks to be valid. And your first email has none. I am not sure why that is. Might be a limitation with Plesk, might be a missing or wrong configuration. I am not sure.

If you need a more in-depth analysis the best suggestion I can offer is to contact Plesk support. They can investigate the issue on your server.

I hope this helps a bit.

Wolfgang Reidlinger · Dec 5, 2023

Kaspar said:
No no, that's incorrect. Sorry if I have caused any confusion here. The DMARC validation on your second email passed because the email is signed with a valid DKIM signature. Not because of SPF. Even though you have a SPF record for the domain, on both of your emails SPF has not been checked (otherwise SPF validation would have been mentioned in the headers).

You first email failed DMARC validation because there it is not DKIM singed, nor has there been a validation for SPF. DMARC need al least one of these checks to be valid. And your first email as none. I am not sure why that is. Might be a limitation with Plesk, might be a missing or wrong configuration. I am not sure.

If you need a more in-depth analysis my best suggestion would be to contact Plesk support. They can investigate the issue on your server.

I hope this helps a bit.

Thanks for the clarification @Kaspar and sorry that I misunderstood some details.
Definitely I see your point and learned a lot so far.
Sure I will try to reach out to support and let you know if we have some progress an this issue.

Question Backup task notification email from PMMCli-Daemon always in Junk folder

Wolfgang Reidlinger

Basic Pleskian

Peter Debik

Community Manager until 3/2024

Kaspar

API expert

Wolfgang Reidlinger

Basic Pleskian

Wolfgang Reidlinger

Basic Pleskian

Wolfgang Reidlinger

Basic Pleskian

Wolfgang Reidlinger

Basic Pleskian

Kaspar

API expert

Wolfgang Reidlinger

Basic Pleskian

Kaspar

API expert

Wolfgang Reidlinger

Basic Pleskian

Kaspar

API expert

Wolfgang Reidlinger

Basic Pleskian

Kaspar

API expert

Wolfgang Reidlinger

Basic Pleskian

Similar threads