Migrating from v12.1.0 to v14.0.0 (opendkim => rspamd)

[curiousercreative]

Has anyone successfully migrated from v12 to v14? I've got v14 up and running, however I cannot for the life of me get rspamd DKIM signing for outbound to work as expected. I don't need to use rspamd per se, but docs urged me to and I'd love for better incoming spam protection. Below is roughly what I've done expecting that I'd be able to continue signing with previous DKIM keys.

1. Updated env file (relevant below)

   $ cat mailserver.env
   ...
   ENABLE_RSPAMD=1
   # ClamAV is compatible with Rspamd. Optionally enable it for anti-virus support:
   ENABLE_CLAMAV=1
   
   # Rspamd replaces the functionality of all these anti-spam services, disable them:
   ENABLE_OPENDKIM=0
   ENABLE_OPENDMARC=0
   ENABLE_POLICYD_SPF=0
   ENABLE_AMAVIS=0
   ENABLE_SPAMASSASSIN=0
   
   # Enables ClamAV, and anti-virus scanner.
   #   1   => Enabled
   # **0** => Disabled
   ENABLE_CLAMAV=1
   
   # When enabled,
   #
   # 1. the "[autolearning][rspamd-autolearn]" feature is turned on;
   # 2. the Bayes classifier will be trained when moving mails from or to the Junk folder (with the help of Sieve scripts).
   #
   # **0** => disabled
   # 1     => enabled
   RSPAMD_LEARN=1
   ...
   

2. Added rspamd conf

   $ cat docker-data/dms/config/rspamd/override.d/dkim_signing.conf
   # documentation: https://rspamd.com/doc/modules/dkim_signing.html
   
   enabled = true;
   
   sign_authenticated = true;
   sign_local = true;
   try_fallback = true;
   
   use_domain = "header";
   use_redis = false; # don't change unless Redis also provides the DKIM keys
   use_esld = true;
   allow_username_mismatch = true;
   
   check_pubkey = true; # you want to use this in the beginning
   
   selector = "mail";
   # The path location is searched for a DKIM key with these variables:
   # - `$domain` is sourced from the MIME mail message `From` header
   # - `$selector` is configured for `mail` (as a default fallback)
   path = "/tmp/docker-mailserver/rspamd/dkim/keys/$domain/$selector.private";
   

3. Copied DKIM keys from old location to new

   $ sudo cp -r docker-data/dms/config/opendkim/keys docker-data/dms/config/rspamd/dkim/
   $ ls docker-data/dms/config/rspamd/dkim/keys/*/ 
   docker-data/dms/config/rspamd/dkim/keys/domainN.com/:
   mail.private  mail.txt
   
   docker-data/dms/config/rspamd/dkim/keys/domainN.com/:
   mail.private  mail.txt
   
   docker-data/dms/config/rspamd/dkim/keys/domainN.com/:
   mail.private  mail.txt
   
   docker-data/dms/config/rspamd/dkim/keys/domainN.com/:
   mail.private  mail.txt
   
   docker-data/dms/config/rspamd/dkim/keys/domainN.com/:
   mail.private  mail.txt
   
   docker-data/dms/config/rspamd/dkim/keys/domainN.com/:
   mail.private  mail.txt
   
   docker-data/dms/config/rspamd/dkim/keys/domainN.com/:
   mail.private  mail.txt
   

4. docker compose pull

5. docker compose down

6. docker compose up

   ...
   INFO  start-mailserver.sh: Welcome to docker-mailserver v14.0.0
   INFO  start-mailserver.sh: Checking configuration
   INFO  start-mailserver.sh: Configuring mail server
   WARN  start-mailserver.sh: (Rspamd setup) Rspamd DKIM private key file '/tmp/docker-mailserver/rspamd/dkim/keys/$domain/$selector.private' is configured for usage, but does not appear to exist
   INFO  start-mailserver.sh: Starting daemons
   INFO  start-mailserver.sh: mail.domain.com is up and running
   ...
   

7. Send a test email via dkimvalidator.com

   • ER: DKIM pass
   • AR: DKIMfail, Details: OpenSSL error: data too small for key size

[curiousercreative]

Probably a known issue for another day, but I was surprised that DKIM key generation doesn't appear to read the rspamd configuration file whatsoever (at least not the global defaults?).

$ docker compose exec -ti mailserver setup config dkim -vv
2025-02-10 12:26:40-05:00 TRACE rspamd-dkim: Enabled trace-logging
2025-02-10 12:26:41-05:00 INFO  rspamd-dkim: Creating DKIM keys of type 'rsa' and length '2048' with selector 'mail' for domain 'domain.com'
2025-02-10 12:26:41-05:00 TRACE rspamd-dkim: Creating Rspamd error log
2025-02-10 12:26:41-05:00 TRACE rspamd-dkim: Running 'grep --quiet --ignore-case --fixed-strings Permission denied /tmp/tmp.2DhOXn5CAW' as user '_rspamd'
2025-02-10 12:26:41-05:00 INFO  rspamd-dkim: Successfully created DKIM keys
2025-02-10 12:26:41-05:00 DEBUG rspamd-dkim: Public key written to '/tmp/docker-mailserver/rspamd/dkim/rsa-2048-mail-domain.com.public.txt'
2025-02-10 12:26:41-05:00 DEBUG rspamd-dkim: Private key written to '/tmp/docker-mailserver/rspamd/dkim/rsa-2048-mail-domain.com.private.txt'
2025-02-10 12:26:41-05:00 DEBUG rspamd-dkim: Permissions on files and directories seem ok
2025-02-10 12:26:41-05:00 INFO  rspamd-dkim: '/tmp/docker-mailserver/rspamd/override.d/dkim_signing.conf' exists, not supplying a default ('--force' does not overwrite this file, manual adjustment required)
2025-02-10 12:26:41-05:00 TRACE rspamd-dkim: Transforming DNS zone format to DNS record content now
2025-02-10 12:26:41-05:00 INFO  rspamd-dkim: Here is the content of the TXT DNS record mail._domainkey.domain.com that you need to create:

v=DKIM1; k=rsa; p=redacted

rspamd: stopped
rspamd: started
2025-02-10 12:26:41-05:00 TRACE rspamd-dkim: Finished DKIM key creation

[curiousercreative]

Oh, now this becomes more painful because I now want to add a new domain. I'll need to manually move/rename the files generated here for new domains...

[polarathene]

I'll need to manually move/rename the files generated here for new domains...

I've proposed a better approach to make it easier for users with selector_map, but no one has had time to contribute it yet.

You should be able to use the same DKIM key if you like across all domains, but until the selector_map config approach for rspamd is adopted, you'd have the more verbose config approach currently used. I don't have much involvement with rspamd support in DMS myself and it's been a while since I went over my notes on the topic, so you may be able to manually use the selector_map config yourself based on what I detailed.

For generating DKIM keypairs, you can avoid the setup CLI tooling that is opendkim/rspamd specific and generate the keys in an agnostic way as I detail here. Again that's a feature I'd like to get into DMS, but I'm often swamped with work that I haven't been able to get back to tackling it yet 😓

[curiousercreative]

@polarathene In the end, DMS appears to be picking up the keys that I generated in v12 without the need for specifying per domain, so that's a win. I hadn't considered the possibility of using the same key for all domains. I suppose it matters little to me, I just want to run a single command for generating keys that will automatically be used for signing without any additional effort. The output of the command is great, just doesn't put the keys in the spot configured (as global fallback).

[curiousercreative]

Serious rubber duck moment, it's passing all of a sudden. Maybe the trick was in bringing destroying containers and recreating them after config changes? I don't know, but startup warning message along with key config output were serious decoys for me.

[polarathene]

Maybe the trick was in bringing destroying containers and recreating them after config changes?

Yeah, we should have that improved with v15 (will release this month), there was a slight regression with v14 related to this when we tried to improve the container restart compatibility.

We document this caveat fairly early on: https://docker-mailserver.github.io/docker-mailserver/v14.0/config/debugging/

[curiousercreative]

Good to hear, this is the first time I've run an image that behaved differently on first container boot vs subsequent container boots. I've only ever seen state persisted in a mounted volume to indicate the need for migrations, etc.

[polarathene]

Yeah it should be a rare issue, but containers do persist state internally when they're stopped/restarted.

DMS runs multiple services in a single container (some consider this an anti-pattern, but the rule is one logical service) and that does complicate it a bit, but the bigger cause is the start-up scripts providing a configuration abstraction (via ENV and config files volume) that rely on modifying config files before starting the third-party services.

Normally a container provides a service and you can directly mount a config, you can change that config manually and restart and all is well. One of the biggest issues in our restart support is the trying to map our config layer changes onto the actual config files used by services which often relies on regex replacements or concatenation.