bug report: opendkim/SigningTablen contained wildcard

[defnull]

📝 Preliminary Checks

• I tried searching for an existing issue and followed the debugging docs advice, but still need assistance.

👀 What Happened?

Unsure how this happened, but my config/opendkim/SigningTable file contained *@* mail._domainkey.mydomain.net as the first line, which caused OpenDKIM to sign all mails with that key and ignoring others keys for other domains. This is not an issue with most email providers, but some (e.g. GMX) are more strict and only accept mails if the DKIM domain used to sign the mail actually matches the domain in the FROM header.

👟 Reproduction Steps

I may have called setup config dkim domain * at some point, but I am not sure. It would be nice to catch this user error and never create a SigningTable entry with a wildcard domain.

🐋 DMS Version

latest

💻 Operating System and Architecture

Debian 12

⚙️ Container configuration files

No response

📜 Relevant log output

No response

Improvements to this form?

No response

[polarathene]

Thanks for reporting that!

The OpenDKIM and Rspamd DKIM support is due for some rework after we've upgraded from Debian 11 to Debian 12 with a v14 release.

I haven't gone over the OpenDKIM config generation yet, but you can see advice here on how to generate a keypair for DKIM to use, along with the DNS record (zone file) and for rspamd the dkim_signing.conf:

#3630 (comment)

---

Ideally as a breaking change:

• This would unify the DKIM config location at /tmp/docker-mailserver with a single setup config dkim script (there's pressently two similar ones for opendkim/rspamd generation).
• We would copy the private key for internal usage, probably relying on a dkim/$domain/$selector.private filename convention.
• The configs could likewise be generated at runtime if they don't already exist based on these files AFAIK.

We'd still want to prevent * as a valid domain candidate though 😅 So thanks for drawing attention to that 👍