Thank you for the feedback! I implemented both suggested changes.

LGTM! Thanks for taking time to make a contribution to DMS ❤️

It seems that an rspamd test has been broken. Unclear if that's the fault of this PR, we don't have extensive test coverage with LDAP so it would be with the file based provisioner 🤔

ok 78 [Rspamd] (DKIM) setting all arguments to a custom value works in 1241ms

not ok 79 setup_file failed
# (from function `refute_output' in file test/test_helper/bats-assert/src/refute_output.bash, line 189,
#  from function `setup_file' in test file test/tests/parallel/set1/spam_virus/rspamd_full.bats, line 68)
#   `refute_output --partial 'inet:localhost:11332: Connection refused'' failed
# 2025-12-26 00:58:42+00:00 INFO  start-mailserver.sh: mail.example.test is up and running
# -- output should not contain substring --
# substring (1 lines):
#   inet:localhost:11332: Connection refused
# output (628 lines):

There is quite a few lines like:

postfix/smtpd[1590]: warning: connect to Milter service inet:localhost:11332: Connection refused

I've tried re-running the test but it failed again. Until it's confirmed that this is due to something other than this PR I don't think I can go ahead and merge 😓

Unfortunately we don't have an ability to pin the version of rspamd supplied from upstream (I requested it and offered to implement but they declined), it's possible that some upstream change pulled in also contributes to this failure, in which case any PR will trigger it.

Since I am completely new to this codebase i just poked a bit around.
I reverted my last commit but that did not change anything. Therefore I also assume it is due to an upstream change.
I then found out, that rspamd seems to be running according to supervisorctl but the rspamd logs show, that the rspamd_proxy is only started after that:

#1351(main) <3b3991>; main; rspamd_fork_worker: prepare to fork process rspamd_proxy (0); listen on: 127.0.0.1:11332
#1351(main) <3b3991>; main; rspamd_fork_worker: prepare to fork process rspamd_proxy (1); listen on: 127.0.0.1:11332

The test rspamd_full waits for the service to be running and then immediately tries to trigger rspamd, which has not yet spawned it's workers.
I don't know how this was handled in the past but I assume, that the workers were ready when rspamd reported as running. Maybe rspamd startup times were also faster in before. Therefore maybe we should also add somthing like _wait_for_rspamd_port_in_container?

There still seems to be an issue in rspamd_dkim which randomly fails while restarting rspamd with exit code 7

 ✗ [Rspamd] (DKIM) argument 'keytype' is applied correctly [2811]
   (from function `assert_success' in file test/test_helper/bats-assert/src/assert_success.bash, line 42,
    in test file test/tests/parallel/set1/spam_virus/rspamd_dkim.bats, line 116)
     `assert_success' failed
   
   -- command failed --
   status : 7
   output (17 lines):
     2025-12-26 11:14:04+00:00 TRACE rspamd-dkim: Options given to this script: 'keytype ed25519'
     2025-12-26 11:14:04+00:00 DEBUG rspamd-dkim: Keytype set to 'ed25519'
     2025-12-26 11:14:04+00:00 INFO  rspamd-dkim: Creating DKIM keys of type 'ed25519' with selector 'mail' for domain 'example.test'
     2025-12-26 11:14:04+00:00 TRACE rspamd-dkim: Creating Rspamd error log
     2025-12-26 11:14:04+00:00 TRACE rspamd-dkim: Running 'rspamadm dkim_keygen -s mail -d example.test -t ed25519 -k /tmp/docker-mailserver/rspamd/dkim/ed25519-mail-example.test.private.txt' as user '_rspamd'
     2025-12-26 11:14:04+00:00 TRACE rspamd-dkim: Running 'grep --quiet --ignore-case --fixed-strings Permission denied /tmp/tmp.C1bcrlXEnG' as user '_rspamd'
     2025-12-26 11:14:04+00:00 INFO  rspamd-dkim: Successfully created DKIM keys
     2025-12-26 11:14:04+00:00 DEBUG rspamd-dkim: Public key written to '/tmp/docker-mailserver/rspamd/dkim/ed25519-mail-example.test.public.txt'
     2025-12-26 11:14:04+00:00 DEBUG rspamd-dkim: Private key written to '/tmp/docker-mailserver/rspamd/dkim/ed25519-mail-example.test.private.txt'
     2025-12-26 11:14:04+00:00 TRACE rspamd-dkim: Running 'ls /tmp/docker-mailserver/rspamd/dkim' as user '_rspamd'
     2025-12-26 11:14:04+00:00 TRACE rspamd-dkim: Running 'cat /tmp/docker-mailserver/rspamd/dkim/ed25519-mail-example.test.private.txt' as user '_rspamd'
     2025-12-26 11:14:04+00:00 DEBUG rspamd-dkim: Permissions on files and directories seem ok
     2025-12-26 11:14:04+00:00 INFO  rspamd-dkim: Supplying a default configuration (to '/tmp/docker-mailserver/rspamd/override.d/dkim_signing.conf')
     2025-12-26 11:14:04+00:00 DEBUG rspamd-dkim: Restarting Rspamd as initial DKIM configuration was supplied
     rspamd: ERROR (not running)
     rspamd: ERROR (abnormal termination)
     2025-12-26 11:14:04+00:00 ERROR rspamd-dkim: Unexpected error occurred :: script = /usr/local/bin/rspamd-dkim  | function = _setup_default_signing_conf | command = supervisorctl restart rspamd | line = 260 | exit code = 7
   --

Randomly meaning that in every test run one or more of the tests fail, but it could be any of them.

The test rspamd_full waits for the service to be running and then immediately tries to trigger rspamd, which has not yet spawned it's workers.
I don't know how this was handled in the past but I assume, that the workers were ready when rspamd reported as running. Maybe rspamd startup times were also faster in before.

Could be, or could be a change in the CI environment being slower too. I used to run tests in cheap VPS instances that revealed other issues in the past that didn't show up with our CI on Github.

If that were the case though our current release image (without a fresh build) should similarly fail, otherwise it'd need to be some recent change somewhere.

Therefore maybe we should also add somthing like _wait_for_rspamd_port_in_container?

We have a generic port helper method to wait on, that might be sufficient. Or we could potentially monitor logs (rspamd logs are a separate log file due to verbosity).

EDIT: Oh I see you already contributed that helper. I'm alright with that 👍

There still seems to be an issue in rspamd_dkim which randomly fails while restarting rspamd with exit code 7

Yeah I've caught that one before too and have detailed it here: #4579

I just rarely having time spare for DMS lately beyond quick support tickets and reviews.

The project could do with more contributors, we lack the momentum alternative mail solutions have in that regard so I'm not sure how relevant DMS will remain beyond it's main differentiator of a single container for simple deployment and configuration.