How do I apply updated sieve script without restarting the container?

[WantToLearnJapanese]

How do I apply the updated sieve script without restarting the container?

[casperklein]

I guess dovecot have to be restarted? You can restart individual services instead of the whole container by using: docker exec mailserver supervisorctl restart dovecot

[Waldorf3]

docker exec mailserver sievec /tmp/docker-mailserver/before.dovecot.sieve

Running this command generates or updates a before.dovecot.svbin in the same folder, but doesn't otherwise activate the chage. The file doesnt seem to be used, or at least not necessary, as down/up the stack does not create a .svbin file.

docker exec mailserver supervisorctl restart dovecot

Does not appear to have any effect.

The only way I make it work is by stoping/starting (down/up) the stack. Not even a restart activates it.

I'd appreciate guidance to how it may be possible to activate changed sieve filters without stopping the mailserver.

I'm surprised there is so little information available about sieve on the internet/youtube in general. I'm a degoogled/gmail refugee, and the filtering system was the thing I found most useful in Gmail. I am really surprised not more people seem to be using it.

[polarathene]

but doesn't otherwise activate the change. The file doesnt seem to be used, or at least not necessary

You can look up our start up script for handling this, we use the config volume location to copy the file internally, and then run sievec on the internal location:

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

Lines 76 to 81 in 02415b0

	if [[ -f /tmp/docker-mailserver/before.dovecot.sieve ]]; then
	cp \
	/tmp/docker-mailserver/before.dovecot.sieve \
	/usr/lib/dovecot/sieve-global/before/50-before.dovecot.sieve
	sievec /usr/lib/dovecot/sieve-global/before/50-before.dovecot.sieve
	fi

That method then runs some additional operations, only the chown seems to be applied to this before.dovecot.svbin file, ensuring dovecot:root ownership (probably because ownership would have been root:root as the sievec command was run as root):

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

Lines 89 to 91 in 02415b0

	chown dovecot:root -R /usr/lib/dovecot/sieve-*
	find /usr/lib/dovecot/sieve-* -type d -exec chmod 755 {} +
	find /usr/lib/dovecot/sieve-{filter,pipe} -type f -exec chmod +x {} +

There's also separate logic here that is to ensure the .svbin files have a newer mtime value than their source .sieve files:

docker-mailserver/target/scripts/startup/setup-stack.sh

Lines 26 to 35 in 02415b0

	function _setup_post() {
	# Dovecot `.svbin` files must have a newer mtime than their `.sieve` source files,
	# Modifications during setup to these files sometimes results in a common mtime value.
	# Handled during post-setup as setup of Dovecot Sieve scripts is not centralized.
	find /usr/lib/dovecot/ -iname '*.sieve' -exec touch -d '2 seconds ago' {} +
	find /usr/lib/dovecot/ -iname '*.svbin' -exec touch -d '1 seconds ago' {} +
	# All startup modifications to configs should have taken place before calling this:
	_prepare_for_change_detection
	}

There's handling elsewhere for other .sieve files supported in DMS should that be relevant to know too.

---

The only way I make it work is by stoping/starting (down/up) the stack. Not even a restart activates it.

DMS skips a bunch of initial setup scripts when the container is restarted (avoids various issues that can happen):

docker-mailserver/target/scripts/start-mailserver.sh

Lines 177 to 200 in 02415b0

	# Ensure DMS only adjusts config files for a new container.
	# Container restarts should skip as they retain the modified config.
	if [[ ! -f /CONTAINER_START ]]; then
	_early_supervisor_setup
	_early_variables_setup
	_log 'info' "Welcome to docker-mailserver ${DMS_RELEASE}"
	_register_functions
	_check
	_setup
	_run_user_patches
	else
	# container was restarted
	_early_variables_setup
	_log 'info' 'Container was restarted. Skipping setup routines.'
	_log 'info' "Welcome to docker-mailserver ${DMS_RELEASE}"
	_register_functions
	fi
	# marker to check if container was restarted
	date >/CONTAINER_START

You need to use docker compose down && docker compose up or docker compose up --force-recreate so that the previous DMS instance is destroyed (the containers internal state, has no affect on your bind mount volumes).

---

I'd appreciate guidance to how it may be possible to activate changed sieve filters without stopping the mailserver.

You can reference the commands above for what needs to be done.

This was brought up in another discussion earlier this year, with the option to automate this via the check-for-changes.sh service that would detect updates to files and run the necessary commands for you.

To add that support, the path to monitor on the config volume needs to be added here:

docker-mailserver/target/scripts/helpers/change-detection.sh

Lines 30 to 42 in 02415b0

	# Supported user provided configs:
	local DMS_DIR=/tmp/docker-mailserver
	if [[ -d ${DMS_DIR} ]]; then
	STAGING_FILES+=(
	"${DMS_DIR}/postfix-accounts.cf"
	"${DMS_DIR}/postfix-virtual.cf"
	"${DMS_DIR}/postfix-regexp.cf"
	"${DMS_DIR}/postfix-aliases.cf"
	"${DMS_DIR}/postfix-relaymap.cf"
	"${DMS_DIR}/postfix-sasl-password.cf"
	"${DMS_DIR}/dovecot-quotas.cf"
	"${DMS_DIR}/dovecot-masters.cf"
	)

Followed by a line like this one:

docker-mailserver/target/scripts/check-for-changes.sh

Line 141 in 02415b0

[[ ${CHANGED} =~ ${DMS_DIR}/postfix-aliases.cf ]] && _handle_postfix_aliases_config

So something like this should work:

[[ ${CHANGED} =~ ${DMS_DIR}/before.dovecot.sieve ]] && _run_sievec \
  "${DMS_DIR}/before.dovecot.sieve" \
  '/usr/lib/dovecot/sieve-global/before/50-before.dovecot.sieve'

[[ ${CHANGED} =~ ${DMS_DIR}/after.dovecot.sieve ]] && _run_sievec \
  "${DMS_DIR}/after.dovecot.sieve" \
  '/usr/lib/dovecot/sieve-global/after/50-after.dovecot.sieve'

And add this function snippet into the check-for-changes.sh file for the above snippet to call:

function _run_sievec() {
  local EXTERNAL_SIEVE=${1}
  local INTERNAL_SIEVE=${2}
  local INTERNAL_SVBIN="${INTERNAL_SIEVE%.*}.svbin"

  # Make an internal copy and compile the sieve script:
  install --mode 755 --owner dovecot --group root "${EXTERNAL_SIEVE}" "${INTERNAL_SIEVE}"
  sievec "${INTERNAL_SIEVE}"
  chown dovecot:root "${INTERNAL_SVBIN}"
  
  # Ensure the mtime of the svbin is newer than the input:
  # https://github.com/docker-mailserver/docker-mailserver/pull/3779
  touch -d '2 seconds ago' "${INTERNAL_SIEVE}"
  touch -d '1 seconds ago' "${INTERNAL_SVBIN}"
}

The install command is handling cp + chown + chmod, but the .svbin created with sievec after is going to need at least the chown applied on it as well I think.

If you don't want to modify check-for-changes.sh that _run_sievec function should be all you need (user-patches.sh isn't viable for container restarts, you'd need to make your own script or manually run the individual commands). Just pass it the external (DMS config volume) and internal paths like shown in the prior snippet and you should be good 👍 (you may need to also run dovecot reload afterwards, the check-for-changes.sh approach would do this implicitly)

---

I'm surprised there is so little information available about sieve on the internet/youtube in general.

You can search DMS issues and discussions (remove the default open filter) for keywords like sieve and find various information/tips.

Our docs should have some useful information on the topic too (EDIT: Until v15 is released, you'd want to view the :edge version of the docs where I updated the sieve page).

[Waldorf3]

This was brought up in another discussion earlier this year, with the option to automate this via the check-for-changes.sh service that would detect updates to files and run the necessary commands for you.

Ah, sorry. As you might have guessed from my avatar, I am a senior citizen, I forgot.

In any case, I'm not a developer and the above is way above my paygrade. For the restart I will just proceed to up/down the stack (i.e. the docker-compose) until a better way may be included some day.

Bonus question. Does this implemenentation support "extlists" ?

[polarathene]

In any case, I'm not a developer and the above is way above my paygrade.

No worries, it's added to my public backlog of smaller tasks that someone else may get around to tackling before I do 😎 (most of the work is covered above, just needs some verification and perhaps a test, ideally it'd refactor the existing related scripts too)

---

Bonus question. Does this implementation support "extlists" ?

Is your screenshot from the Dovecot docs? I found this which seems to be about the Dovecot sieve implementation which states that extlists is planned since 2016, but maybe that is outdated?

I did not have much luck finding anything else that says Dovecot supports the extension. AFAIK the Dovecot docs list what sieve extensions are supported by default and the others that they offer which needs the require import to use them. I'm not sure if there's a way in DMS to query what the available sieve extensions available are though.

[Waldorf3]

Is your screenshot from the Dovecot docs?

It's from ChatGPT ;)