"System mails" are not DKIM-signed

[ralfbergs]

Contribution guidelines

• I've read the contribution guidelines and wholeheartedly agree

I've found a bug and checked that ...

• ... I understand that not following the below instructions will result in immediate closure and/or deletion of my issue.
• ... I have understood that this bug report is dedicated for bugs, and not for support-related inquiries.
• ... I have understood that answers are voluntary and community-driven, and not commercial support.
• ... I have verified that my issue has not been already answered in the past. I also checked previous issues.

Description

I added a domain to mailcow and configured it to send DKIM-signed emails. That works well, I'm checking it with Thunderbird's "DKIM Verifier" extension.

The problem is that when I send email to all users, using the "System mails" function built into mailcow, those messages are not DKIM-signed, so Thunderbird shows a "red" warning. I checked in the envelope that DKIM headers are indeed not present.

Logs:

Log snippets don't help, DKIM-signing activity doesn't show up in Postfix logs, so I would be able to demonstrate the difference between DKIM-signed "regular" messages and non-DKIM-signed "System mails."

Steps to reproduce:

1. Log into mailcow "admin" interface.
2. Follow clickpath "System" -> "Configuration" -> "System mails"
3. Enter subject of "Test", text of "Test"
4. Click "Activate 'Send' button"
5. Click "Send" button to send mass email to all active users on system.

Which branch are you using?

master

Which architecture are you using?

x86

Operating System:

Debian 12.7

Server/VM specifications:

AWS m5.large: 8 GB RAM, 2 vcores

Is Apparmor, SELinux or similar active?

no

Virtualization technology:

AWS EC2

Docker version:

27.3.1

docker-compose version or docker compose version:

v2.29.7

mailcow version:

2024-08a

Reverse proxy:

none

Logs of git diff:

diff --git a/data/conf/postfix/main.cf b/data/conf/postfix/main.cf
index 6a87f2ec..5a040bbc 100644
--- a/data/conf/postfix/main.cf
+++ b/data/conf/postfix/main.cf
@@ -173,3 +173,27 @@ parent_domain_matches_subdomains = debug_peer_list,fast_flush_domains,mynetworks

 # DO NOT EDIT ANYTHING BELOW #
 # Overrides #
+
+postscreen_dnsbl_sites = wl.mailspike.net=127.0.0.[18;19;20]*-2
+  hostkarma.junkemailfilter.com=127.0.0.1*-2
+  list.dnswl.org=127.0.[0..255].0*-2
+  list.dnswl.org=127.0.[0..255].1*-4
+  list.dnswl.org=127.0.[0..255].2*-6
+  list.dnswl.org=127.0.[0..255].3*-8
+  ix.dnsbl.manitu.net*2
+  bl.spamcop.net*2
+  bl.suomispam.net*2
+  hostkarma.junkemailfilter.com=127.0.0.2*3
+  hostkarma.junkemailfilter.com=127.0.0.4*2
+  hostkarma.junkemailfilter.com=127.0.1.2*1
+  backscatter.spameatingmonkey.net*2
+  bl.ipv6.spameatingmonkey.net*2
+  bl.spameatingmonkey.net*2
+  b.barracudacentral.org=127.0.0.2*7
+  bl.mailspike.net=127.0.0.2*5
+  bl.mailspike.net=127.0.0.[10;11;12]*4
+
+
+# User Overrides
+myhostname = [REDACTED]
+

Logs of iptables -L -vn:

Not relevant

Logs of ip6tables -L -vn:

Not relevant

Logs of iptables -L -vn -t nat:

Not relevant

Logs of ip6tables -L -vn -t nat:

Not relevant

DNS check:

Not relevant, but anyway...

# docker exec -it $(docker ps -qf name=acme-mailcow) dig +short stackoverflow.com @172.22.1.254
104.18.32.7
172.64.155.249

[DerLinkman]

Hello, that is intended, not a bug.

[ralfbergs]

Hello, that is intended, not a bug.

Hi Niklas. Thank you for your response.

Would you please explain what the motivation is behind intentionally not DKIM-signing such messages?

"System Messages" will usually be very important for the users of a mail system. In my view it would make sense to enable DKIM to assign some trust to such messages, otherwise users may consider the message forged and just ignore it.

[DerLinkman]

These system messages are directly send to dovecot from the server, not via postfix and therefore they are not dkim signed, as they are locally delivered.

[ralfbergs]

These system messages are directly send to dovecot from the server, not via postfix and therefore they are not dkim signed, as they are locally delivered.

Hi Niklas. Yes, I figured so -- but (sorry for insisting) my question should have been more precisely "why was it designed like this?" I can see that this reduces the overall load on the mail system, but was it considered that this was not the best decision with regards to "user trust?"