On 6. Jul 2026, at 11.47, Patrick Cernko <pcernko@mpi-klsb.mpg.de> wrote:
Hi Timo,
On 2026-07-05 18:27:51, Timo Sirainen wrote:
On 1. Jul 2026, at 15.11, Patrick Cernko via dovecot <dovecot@dovecot.org> wrote:
Hi Dovecot Devs,
I'm currently setting up Dovecot 2.4 as frontend proxy to our backends. The frontends simply use an LDAP attribute of the user to connect to the assigned IMAP backend server. That works fine so far.
According to the documentation <https://doc.dovecot.org/2.4.4/core/man/doveadm- kick.1.html>, I should be able to disconnect a user with
doveadm kick USERNAME
or all sessions to a specific backend with
doveadm kick -h BACKEND_IP
or simply ALL sessions with
doveadm kick '*'
However the command reports the expected amount of connections kicked and exitcode 0, but all sessions stay connected. I also tried 'doveadm proxy kick ...' but as the the corresponding documentation states, this is only an alias for 'doveadm kick ...' and thus shows the same behavior.
Looks like kicking proxied connections works only in login processes' "high performance mode": https://doc.dovecot.org/2.4.4/core/config/login_processes.html#high-performa... <https://doc.dovecot.org/2.4.4/core/ config/login_processes.html#high-performance-mode <https://doc.dovecot.org/2.4.4/core/%20config/login_processes.html#high-performance-mode>> I'll get it fixed for the default "high security mode" as well, hopefully for v2.4.5 still.
thank you!
In the meantime, I have tried to debug and fix this myself. Maybe my findings help you: When handling proxy logins, the
current_userfield ofmaster_serviceis not set. As a consequence,sig_service_kick_user_match()will return 0 which leads to ignoring the KILL-USER command from anvil. I tried to fix this by settingmaster_service_set_current_user(master_service, client->virtual_user)in login-proxy.c, similar to mail-storage-service.c, see my attached patched. I can provide this fix also as a pull request via Github, if you like!
Ah, I didn't think you were in a hurry to get a fix with the workaround being available :) But yes, I've a pretty similar fix waiting in our internal gitlab. Will be public in github after internal review.
On 6. Jul 2026, at 11.47, Patrick Cernko <pcernko@mpi-klsb.mpg.de> wrote:
Hi Timo,
On 2026-07-05 18:27:51, Timo Sirainen wrote:
On 1. Jul 2026, at 15.11, Patrick Cernko via dovecot
<dovecot@dovecot.org> wrote:
Hi Dovecot Devs,
I'm currently setting up Dovecot 2.4 as frontend proxy to our
backends. The frontends simply use an LDAP attribute of the user to
connect to the assigned IMAP backend server. That works fine so far.
According to the documentation
<https://doc.dovecot.org/2.4.4/core/man/doveadm- kick.1.html>, I
should be able to disconnect a user with
doveadm kick USERNAME
or all sessions to a specific backend with
doveadm kick -h BACKEND_IP
or simply ALL sessions with
doveadm kick '*'
However the command reports the expected amount of connections
kicked and exitcode 0, but all sessions stay connected. I also tried
'doveadm proxy kick ...' but as the the corresponding documentation
states, this is only an alias for 'doveadm kick ...' and thus shows
the same behavior.
Looks like kicking proxied connections works only in login processes'
"high performance
mode": [1]https://doc.dovecot.org/2.4.4/core/config/login_processes.html#high-performance-mode
<[2]https://doc.dovecot.org/2.4.4/core/
config/login_processes.html#high-performance-mode>
I'll get it fixed for the default "high security mode" as well,
hopefully for v2.4.5 still.
thank you!
In the meantime, I have tried to debug and fix this myself. Maybe my
findings help you:
When handling proxy logins, the `current_user` field of `master_service`
is not set. As a consequence, `sig_service_kick_user_match()` will
return 0 which leads to ignoring the KILL-USER command from anvil. I
tried to fix this by setting
`master_service_set_current_user(master_service, client->virtual_user)`
in login-proxy.c, similar to mail-storage-service.c, see my attached
patched. I can provide this fix also as a pull request via Github, if
you like!Ah, I didn't think you were in a hurry to get a fix with the workaround being available :) But yes, I've a pretty similar fix waiting in our internal gitlab. Will be public in github after internal review.
References
Visible links