On 3. Sep 2026, at 10.14, Patrick Cernko via dovecot <dovecot@dovecot.org> wrote:

From our point of view, this setting has a clear security benefit like this:

...

security: we only allow specific doveadm commands via doveadm-server and some more when coming from localhost

doveadm_allowed_commands = user,who local 127.0.0.1/8 { doveadm_allowed_commands = user,who,"sieve list","sieve get","sieve put","sieve activate" }

It limits the allowed commands in general to who and user which are read-only. Only if the connection is comming from localhost, we additionally grant some sieve commands for our web interface to manage and test sieve rulesets (https://gitlab.mpi-klsb.mpg.de/pcernko/sieveweb). All other commands are not allowed at all, e.g. it is not possible to delete mails or use dsync via the HTTP API. This policy matches our general security policy to only grant what's needed.

So, Timo, I would like to ask, why this setting has to get removed (I assume in the next release) or if it can be restored again in the main branch?

Having this setting is bad, because it can provide false sense of security. It's not at all obvious which commands are safe and which aren't. Using your list as an example: The doveadm user command already is risky because it supports -e parameter, which supports %variable expansion. If mail_lua plugin is loaded, you can run a function in a Lua script that exists somewhere on the filesystem. In the future it's possible that we add a %function that allows directly executing some commands or reading some files on the system. Also, you can already use %{env:x} to look at environment variables, which may contain secrets in some installations.

There are also commands that already allow arbitrary code execution via -p parameter: doveadm sync, backup, import.

If you need actual security would be better to have some proxy in the middle, which sends only safe commands with safe parameters towards doveadm.