DMS+DKIM: Is a container rebuild and restart required ...

[g40]

when DKIM signing is added to a new domain?

From what I can tell via the log file and headers, it would appear so.

Thanks!

[polarathene]

@georglauterbach might be able to answer this better than I can. I don't deploy DMS myself and haven't yet updated the test suite to have better coverage on DKIM signing.

There are plans to unify DKIM key generation via step crypto, and derive config for that at runtime (if none is provided via config volume).

If you have an easy way to verify with shell commands, I can probably work from that to assist further. Chances are the check-for-changes.sh service would just need to watch and handle some additional files, maybe reload config for an additional service if postfix reload is not sufficient.

OpenDKIM does copy from external config volume to an internal location at startup, so this would require being extracted into a helper script that the change detection service mentioned could run when content from that location is updated:

docker-mailserver/target/scripts/startup/setup.d/dmarc_dkim_spf.sh

Lines 23 to 25 in 025a38d

	# check if any keys are available
	if [[ -e /tmp/docker-mailserver/opendkim/KeyTable ]]; then
	cp -a /tmp/docker-mailserver/opendkim/* /etc/opendkim/

@georglauterbach would be more familiar with rspamd DKIM support, last I recall it was relying on direct reference to the DMS config volume, instead of making an internal copy which was planned (if not already done). At a glance of the rspamd config I shared here there is a config volume reference for the selector map, nothing that suggests that rspamd would need a reload, nor triggering an internal copy of anything to keep working. Thus if you were to use DKIM with the rspamd feature, I think presently that will work without requiring a restart.

---

For OpenDKIM (the current default), you won't be able to just restart the container as that would skip the main startup scripts. It'll need to be a new container instance (docker compose up --force-recreate). Someone would need to contribute change detection support to fix that.

[georglauterbach]

IIRC a restart is not required; you can run `supervisorctl restart rspamd´ inside the container if you want to be on the safe side.

We do not currently copy keys for Rspamd; this is something for future-me or someone else to implement.