- dovecot - dovecot.org

Problem with authentication in dovecot
by Freek de Kruijf 21 May '26

21 May '26

I have the following dovecot.conf, striped from comment: dovecot_config_version = 2.4.2 dovecot_storage_version = 2.4.0 protocols = imap auth_allow_cleartext = yes auth_mechanisms = plain auth_verbose = yes mail_plugin_dir = /usr/lib64/dovecot/modules namespace inbox { inbox = yes mail_driver = maildir mail_path = ~/Maildir prefix = INBOX. mailbox Drafts { special_use = \Drafts } mailbox Junk { special_use = \Junk } mailbox Trash { auto = subscribe special_use = \Trash } mailbox Sent { special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } } passdb pam { service_name = dovecot } userdb passwd { use_worker = yes } service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0666 user = postfix } } ssl = yes ssl_server { cert_file = /etc/letsencrypt/live/<mydomain>/fullchain.pem dh_file = /etc/dovecot/dh.pem key_file = /etc/letsencrypt/live/<mydomain>/privkey.pem } sieve_script personal { active_path = ~/.dovecot.sieve driver = file path = ~/sieve } When connecting my email client to dovecot, the connection succeeds, but after awhile it disconnects. In /var/log/dovecot I get: May 18 17:36:15 imap-login: Warning: Auth process not responding, delayed sending initial response (greeting): user=<>, rip=192.168.178.6, lip=192.168.178.15, session=<2IMbUhlS8K3AqLIG> May 18 17:36:45 imap-login: Info: Login aborted: Connection closed (disconnected before auth was ready, waited 40 secs) (auth_process_not_ready): user=<>, rip=192.168.178.6, lip=192.168.178.15, session=<2IMbUhlS8K3AqLIG> May 18 17:36:45 imap-login: Error: auth-client: conn unix:login: connect(login) in directory / failed: Permission denied (euid=473(<getpwuid() error>) egid=473(<getgrgid() error>) missing +x perm: /, we're not in group 474, dir owned by 0:474 mode=0750) May 18 17:36:45 imap-login: Error: auth-client: conn unix:login: connect(login) in directory / failed: Permission denied (euid=473(<getpwuid() error>) egid=473(<getgrgid() error>) missing +x perm: /, we're not in group 474, dir owned by 0:474 mode=0750) 473 is connected with account/group dovenull an 474 is connected with account/group dovecot I can't find a solution when searching the internet. -- fr.gr. member openSUSE Freek de Kruijf I have the following dovecot.conf, striped from comment: dovecot_config_version = 2.4.2 dovecot_storage_version = 2.4.0 protocols = imap auth_allow_cleartext = yes auth_mechanisms = plain auth_verbose = yes mail_plugin_dir = /usr/lib64/dovecot/modules namespace inbox { inbox = yes mail_driver = maildir mail_path = ~/Maildir prefix = INBOX. mailbox Drafts { special_use = \Drafts } mailbox Junk { special_use = \Junk } mailbox Trash { auto = subscribe special_use = \Trash } mailbox Sent { special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } } passdb pam { service_name = dovecot } userdb passwd { use_worker = yes } service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0666 user = postfix } } ssl = yes ssl_server { cert_file = /etc/letsencrypt/live/<mydomain>/fullchain.pem dh_file = /etc/dovecot/dh.pem key_file = /etc/letsencrypt/live/<mydomain>/privkey.pem } sieve_script personal { active_path = ~/.dovecot.sieve driver = file path = ~/sieve } When connecting my email client to dovecot, the connection succeeds, but after awhile it disconnects. In /var/log/dovecot I get: May 18 17:36:15 imap-login: Warning: Auth process not responding, delayed sending initial response (greeting): user=<>, rip=192.168.178.6, lip=192.168.178.15, session=<2IMbUhlS8K3AqLIG> May 18 17:36:45 imap-login: Info: Login aborted: Connection closed (disconnected before auth was ready, waited 40 secs) (auth_process_not_ready): user=<>, rip=192.168.178.6, lip=192.168.178.15, session=<2IMbUhlS8K3AqLIG> May 18 17:36:45 imap-login: Error: auth-client: conn unix:login: connect(login) in directory / failed: Permission denied (euid=473(<getpwuid() error>) egid=473(<getgrgid() error>) missing +x perm: /, we're not in group 474, dir owned by 0:474 mode=0750) May 18 17:36:45 imap-login: Error: auth-client: conn unix:login: connect(login) in directory / failed: Permission denied (euid=473(<getpwuid() error>) egid=473(<getgrgid() error>) missing +x perm: /, we're not in group 474, dir owned by 0:474 mode=0750) 473 is connected with account/group dovenull an 474 is connected with account/group dovecot I can't find a solution when searching the internet. -- fr.gr. member openSUSE Freek de Kruijf

2 1

dovecot 2.4 Restricting Access - journal/log differences for failed login?
by David C Rankin 21 May '26

21 May '26

All, I have restricted access for several users using the Restring Access documentation https://doc.dovecot.org/2.4.0/howto/restrict_access.html This was to cut down on the brute-force attempts against dovecot for certain users whose usernames/e-mails are routinely used. I have a very simply passdb config: passdb passwd-file { passwd_file_path = /etc/dovecot/deny.%{protocol} deny = yes } passdb pam { driver = pam } userdb pam { driver = passwd } I created the /etc/dovecot/deny.imap file with one username per-line. But what confuses me is the server logs the exact same failure for unsuccessful login after restricting access as it did before restricting access. E.g. 2026-05-20T07:22:43.039585-05:00 valkyrie auth[28618]: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=janice(a)mydomain.com rhost=70.186.179.37 2026-05-20T07:22:51.578711-05:00 valkyrie auth[28618]: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=janice(a)mydomain.com rhost=70.186.179.37 May 20 07:25:36 valkyrie dovecot[1015]: imap-login: Login aborted: Inactivity (auth failed, 2 attempts in 177 secs) (auth_failed): user=<janice(a)mydomain.com>, method=PLAIN, rip=70.186.179.37, lip=192.168.6.14, TLS, session=<ouXP2T5SJpZGurMl> Is this normal, or should dovecot respond to restricted users in some way that differs from a normal login failure? All could be working fine, I'm just not certain about the log entries. -- David C. Rankin, J.D.,P.E.

1 0

undocumented changed behavior of 2.4.3 (possible bug report)
by Patrick Cernko 20 May '26

20 May '26

Hello Dovecot-Devs, hello list, while upgrading my Dovecot 2.4.2 setup to 2.4.3 I observed two instances of changed behavior. I could not find notes about those issues in the corresponding documentation (https://doc.dovecot.org/2.4.3/installation/upgrade/2.4-to-2.4.x.html) or release notes: 1. I had to change userdb_ldap_iterate_filter = (&(objectClass=posixAccount)%{if(protocol,"eq","pop3","(istIsMemberOf=POP3-users)","")}) to userdb_ldap_iterate_filter = (&(objectClass=posixAccount)%{if(protocol,"eq","pop3","(istIsMemberOf=POP3-users)","")|safe) otherwise the characters '()=' in the "true"-case of the condition got somehow "quoted" with escaped ASCII codes, which led to a broken LDAP filter string. Maybe you could add some documentation (in "Upgrading" as well as "Settings Variables") about that? 2. The behavior of sieve matches using ":matches" has changed: Example email (only the relevant header): List-Id: Dovecot Mailing List <dovecot.dovecot.org> Example Sieve script: if header :matches "List-Id" "*<dovecot*.dovecot.org>" { fileinto "dovecot"; } In 2.4.2 (and earlier) the example email matched the condition and got stored in the dovecot folder, while in 2.4.3 the condition does NOT match. As a workaround I added a '*' at the end of the match ("*<dovecot*.dovecot.org>*") to get my mails stored correctly again. Is this changed behavior for Sieve intentional or a bug? In case of a bug, could you please provide a fix? In case of intentional behavior: * Could you please explain the intention? Why was it necessary? * What would be the correct fix for the sieve example to match a List-Id header that ENDS WITH ".dovecot.org>"? * I assume, that other users on my servers will run into similar problems once I upgrade their servers. Is it possible to detect such problematic matches in Sieve scripts? E.g. "all matches without a trailing '*' are affected", ... This would give me a chance, to inform my users or even fix their scripts in advance. Best regards, -- Patrick Cernko <pcernko(a)mpi-klsb.mpg.de> +49 681 9325 5815 Joint Scientific IT and Technical Service Max-Planck-Institute für Informatik & Softwaresysteme

2 3

NFC normalization rename errors after 2.3 to 2.4 upgrade (mdbox)
by Jan Münnich 20 May '26

20 May '26

Hi, We just upgraded from 2.3 to 2.4.3 and are now getting errors like this for any mailbox with German umlauts in the name: "Error: Failed to rename mailbox 'Anträge' for NFC normalization: Mailbox doesn't exist: Anträge" The mailboxes work fine otherwise, doveadm mailbox status shows them with correct message counts. The errors show up on IMAP access but don't seem to break anything. We're using mdbox. On disk the directory is stored as mUTF-7: Antr&AOQ-ge doveadm mailbox list gives back the name with c3 a4 for the ä, which is already NFC. We double-checked with python3 unicodedata and it confirms the name is NFC. So it seems like dovecot is trying to rename something that doesn't need renaming, and then failing. Is there a way to turn off this automatic rename? Or is this a known issue with mdbox and mUTF-7 directory names? Any help would be appreciated to find out if this is a bug or a configuration issue on our side! Thanks, Jan

4 6

Building on FreeBSD 14.4
by Frank Volf 19 May '26

19 May '26

Hi, I'm trying to build dovecot-2.4.4 on FreeBSD 14.4 and I get a strange error message. What I did is download and extract dovecot-2.4.4.tar.gz and then run ./configure without any arguments. After typing make the build started without any problems until this point: .... Making all in auth CC test_auth_cache-auth-cache.o CC test_auth_cache-test-auth-cache.o CC auth-main.o CC auth-auth.o CC auth-auth-cache.o CC auth-auth-client-connection.o CC auth-auth-master-connection.o CC auth-auth-policy.o CC auth-auth-penalty.o CC auth-auth-request.o CC auth-auth-request-fields.o CC auth-auth-request-handler.o CC auth-auth-request-var-expand.o CC auth-auth-sasl-mech-apop.o CC auth-auth-sasl-mech-dovecot-token.o CC auth-auth-sasl-mech-oauth2.o CC auth-auth-sasl.o CC auth-auth-settings.o CC auth-auth-fields.o CC auth-auth-token.o CC auth-auth-worker-connection.o CC auth-auth-worker-server.o CC auth-db-oauth2.o CC auth-db-sql.o CC auth-db-passwd-file.o CC auth-passdb.o CC auth-passdb-blocking.o CC auth-passdb-bsdauth.o CC auth-passdb-cache.o CC auth-passdb-oauth2.o CC auth-passdb-passwd.o CC auth-passdb-passwd-file.o CC auth-passdb-pam.o CC auth-passdb-sql.o CC auth-passdb-static.o CC auth-userdb.o CC auth-userdb-blocking.o CC auth-userdb-passwd.o CC auth-userdb-passwd-file.o CC auth-userdb-prefetch.o CC auth-userdb-static.o CC auth-userdb-sql.o CC auth-db-ldap.o CC auth-db-ldap-sasl.o CC auth-db-ldap-settings.o CC auth-passdb-ldap.o CC auth-userdb-ldap.o CC auth-db-lua.o CC auth-passdb-lua.o CC auth-userdb-lua.o make[3]: don't know how to make -L/usr/local/lib. Stop make[3]: stopped making "all" in /home/volf/dovecot-2.4.4/src/auth *** Error code 1 So, apparently make is confused and thinks that the compiler/linker commandline option is an item to build. I'm at loss how to solve this. I would appreciate it, if somebody could give me a hint how to solve this. Kind regards, Frank Hi, I'm trying to build dovecot-2.4.4 on FreeBSD 14.4 and I get a strange error message. What I did is download and extract dovecot-2.4.4.tar.gz and then run ./configure without any arguments. After typing make the build started without any problems until this point: .... Making all in auth CC test_auth_cache-auth-cache.o CC test_auth_cache-test-auth-cache.o CC auth-main.o CC auth-auth.o CC auth-auth-cache.o CC auth-auth-client-connection.o CC auth-auth-master-connection.o CC auth-auth-policy.o CC auth-auth-penalty.o CC auth-auth-request.o CC auth-auth-request-fields.o CC auth-auth-request-handler.o CC auth-auth-request-var-expand.o CC auth-auth-sasl-mech-apop.o CC auth-auth-sasl-mech-dovecot-token.o CC auth-auth-sasl-mech-oauth2.o CC auth-auth-sasl.o CC auth-auth-settings.o CC auth-auth-fields.o CC auth-auth-token.o CC auth-auth-worker-connection.o CC auth-auth-worker-server.o CC auth-db-oauth2.o CC auth-db-sql.o CC auth-db-passwd-file.o CC auth-passdb.o CC auth-passdb-blocking.o CC auth-passdb-bsdauth.o CC auth-passdb-cache.o CC auth-passdb-oauth2.o CC auth-passdb-passwd.o CC auth-passdb-passwd-file.o CC auth-passdb-pam.o CC auth-passdb-sql.o CC auth-passdb-static.o CC auth-userdb.o CC auth-userdb-blocking.o CC auth-userdb-passwd.o CC auth-userdb-passwd-file.o CC auth-userdb-prefetch.o CC auth-userdb-static.o CC auth-userdb-sql.o CC auth-db-ldap.o CC auth-db-ldap-sasl.o CC auth-db-ldap-settings.o CC auth-passdb-ldap.o CC auth-userdb-ldap.o CC auth-db-lua.o CC auth-passdb-lua.o CC auth-userdb-lua.o make[3]: don't know how to make -L/usr/local/lib. Stop make[3]: stopped making "all" in /home/volf/dovecot-2.4.4/src/auth *** Error code 1 So, apparently make is confused and thinks that the compiler/linker commandline option is an item to build. I'm at loss how to solve this. I would appreciate it, if somebody could give me a hint how to solve this. Kind regards, Frank

6 13

flatcurve index size (10x larger than lucene)
by Jean-Daniel Beaubien 19 May '26

19 May '26

Hi everyone, I am currently trying to update from an old dovecot 2.3 setup with fts-lucene to 2.4.2 with fts-flatcurve. However, I am seeing a giant jump in the size of the indexes. For an email account that takes 12GB of storage, I get the following index sizes: - lucene: 270 MB - flatcurve: 2400 MB That is almost a 10x increase in the index size (with flatcurve the indexes represent 20% of the size of the mailbox). Considering I have a mailbox that takes 270GB, I can't imagine the size of the indexes. *Am I doing something wrong with flatcurve? How can the indexes be so much larger than lucene?* I took the default flatcurve configuration from the Ubuntu 26.04 install: mail_plugins { fts = yes fts_flatcurve = yes } fts_autoindex = yes language_filters = normalizer-icu snowball stopwords language_tokenizers = generic email-address language_tokenizer_generic_algorithm = simple language en { default = yes filters = lowercase snowball english-possessive stopwords } fts flatcurve { # All of these are optional, and indicate the default values. # They are listed here for documentation purposes; most people should not # need to define/override in their config. # commit_limit = 500 # max_term_size = 30 # min_term_size = 2 # optimize_limit = 10 # rotate_count = 5000 # rotate_time = 5000 substring_search = yes } *Any help/insight would be greatly appreciated.* Best regards, -J Hi everyone, I am currently trying to update from an old dovecot 2.3 setup with fts-lucene to 2.4.2 with fts-flatcurve. However, I am seeing a giant jump in the size of the indexes. For an email account that takes 12GB of storage, I get the following index sizes: o lucene: 270 MB o flatcurve: 2400 MB That is almost a 10x increase in the index size (with flatcurve the indexes represent 20% of the size of the mailbox). Considering I have a mailbox that takes 270GB, I can't imagine the size of the indexes. Am I doing something wrong with flatcurve? How can the indexes be so much larger than lucene? I took the default flatcurve configuration from the Ubuntu 26.04 install: mail_plugins { fts = yes fts_flatcurve = yes } fts_autoindex = yes language_filters = normalizer-icu snowball stopwords language_tokenizers = generic email-address language_tokenizer_generic_algorithm = simple language en { default = yes filters = lowercase snowball english-possessive stopwords } fts flatcurve { # All of these are optional, and indicate the default values. # They are listed here for documentation purposes; most people should not # need to define/override in their config. # commit_limit = 500 # max_term_size = 30 # min_term_size = 2 # optimize_limit = 10 # rotate_count = 5000 # rotate_time = 5000 substring_search = yes } Any help/insight would be greatly appreciated. Best regards, -J

3 3

[Dovecot] batch convert mbox to maildir
by Netlink Tech 18 May '26

18 May '26

Hello, I have used mb2md for an individual user like this: su ~username cd ~ ./mb2md -m This converted /var/spool/mail/username mbox to /home/users/username/Maildir just as I expected. To convert 100s of users the same way would be a chore (su as each user for permissions, etc.). Is there a way to batch process all /var/spool/mail/$USER to /home/users/$USER/Maildir with the correct permissions/file owners for each user?

4 4

Lua authentication
by John Fawcett 18 May '26

18 May '26

Hi I'm finally getting round to taking up Aki's suggestion here to look into lua. The original requirement was to check the ip reputation giving an OK or KO before proceeding to the login. I'd be interested in any feedback on the dovecot.conf settings and lua script. Also I've encountered a strange caching issue. https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/E5FLX… To do this I've added a new passdb before the existing sql passdb. I am assuming that I will need to reverse the defaults (in 2.3.21.1) for result_success and result_failure. passdb { driver = lua args = file=/etc/dovecot/passdb.lua blocking=yes result_success = continue result_failure = return-fail } This is my lua test script. function auth_passdb_lookup(req) dovecot.i_info("login request from " .. req.remote_ip .. " user=" .. req.user) if (req.user == "user_to_deny(a)example.com") then dovecot.i_info("deny login") return dovecot.auth.PASSDB_RESULT_USER_UNKNOWN, "" end return dovecot.auth.PASSDB_RESULT_NEXT, "" end I am trying to get this working with this very simple logic before developing the real logic. But basically I am considering two responses from the lua script, one which is OK (returning dovecot.auth.PASSDB_RESULT_NEXT) in which case the next passdb should be consulted for the real password lookup. The other case is a KO (returning dovecot.auth.PASSDB_RESULT_USER_UNKNOWN) where this should be taken as an immediate failure without proceeding to password lookup in the next passd.I have passdb caching disabled. While testing the KO case which seems to be working, if I modify the script changing the user_to_deny(a)example.com so it no longer matches, the script still outputs "deny login". It's not a passdb caching issue since it is going through the "deny login" code despite the user not matching. Could it be that lua scripts are being cached by dovecot? John

1 0

Re: [EXT] Re: postfix/dovecot migration
by bcs＠nanomail.net 16 May '26

16 May '26

Was able to execute the process as root with "doveadm -D backup -Ru tst tcp:10.0.1.212:12354" after updating some destination side configuration options that do not appear to be documented in the link provided, but there are a few errors that I am unable to understand or correct. 1. Debug: open(/proc/self/io) failed: Permission denied - This file is read only for root and permissions cannot be modified. 2. Error: Mailbox INBOX sync: mailbox_delete failed: INBOX can't be deleted. - Not sure why a mailbox would need to be deleted other than the backup is using a delete and recreate to retain only current emails, assuming this is on the destination server. 3. All emails for tst account are deleted from the source server - This is a significant issue when only copies should be made for a backup. Full log is attached. Any additional insights would be greatly appreciated, Bryan May 15, 2026 10:01 AM, "Aki Tuomi" <aki.tuomi(a)open-xchange.com> wrote: > Yeah, you can do migration with dsync or imap between 2.3 and 2.4 > > Aki > >> On 15/05/2026 16:10 EEST Bryan Simmons <bcs(a)nanomail.net> wrote: >> >> Aki, >> >> Thank you for the guidance. Just to confirm, doveadm/imap based >> migration is the section under "Migrating Mailboxes from Another Dovecot >> Server" in the link referenced below since this migration will be >> between servers? >> >> Seems an upgrade from dovecot 2.3.21 (current version on source server) >> to 2.4.2 (installed version on the destination server) would be >> appropriate before migrating any user accounts based on information from >> some of the other posts regarding migration. >> >> Thanks , Bryan >> >> On 5/13/26 13:41, Aki Tuomi via dovecot wrote: >> On 13/05/2026 20:31 EEST Bryan Simmons via dovecot <dovecot(a)dovecot.org> wrote: >> >> Moving postfix and dovecot to a new server including all current users >> and emails. There exists several dovecot files in each user mail directory: >> >> dovecot.index >> dovecot.index.cache >> dovecot.index.log >> dovecot-keywords >> dovecot.list.index.log >> dovecot.mailbox.log >> dovecot-uidlist >> dovecot-uidvalidity >> dovecot-uidvalidity.612d3d34 >> >> Should these files be migrated also or will dovecot recreate them as needed? >> >> Thank you, Bryan >> >> https://doc.dovecot.org/2.4.4/core/admin/migration.html#migrating-mailboxes >> >> I would recommend seeing this. Depending on your mailbox format, it can be important that those >> files are copied, but I would suggest doveadm/imap based migration. >> >> Aki >> >> _______________________________________________ >> dovecot mailing list -- dovecot(a)dovecot.org >> To unsubscribe send an email to dovecot-leave(a)dovecot.org

2 2

Regression/Bug report: crypt_private_key_file (for crypt_global_private_key) no longer supports inline base64 (from userdb) in dev branch
by Ömer Güven 15 May '26

15 May '26

Hi, I’ve run into what appears to be a regression (or at least a behavioral change) in Dovecot 3.3.0+ / current HEAD regarding crypt_private_key_file handling for the crypt_global_private_key. I don‘t use per-folder user keys but a global encryption key per user. Previously, it was possible to provide the private key via userdb using an inline base64:-encoded PEM directly to the crypt_global_private_key_file and Dovecot would correctly parse and use it. With the latest config scheme change, this no longer works, as you cannot really set named config variables from userdb. I did workaround by setting a custom userdb variable and setting the needed named/filter variables manually in the config file. To make it work, I had to enclose the config in a „protocol imap“ scope. The crypt_global_public_key_file is accessible from userdb (as it is not within a named filter scope), so inline-base64 works as with Dovecot 2.3+. When using the following workaround to reach the scoped variables, Dovecot tries to load the file „inline:BASE64ENCODEDPEM“ as a literal filename (error open(inline:AB….C==) failed): protocol imap { crypt_global_private_key user { crypt_private_key_file = %{userdb:private_key_file} crypt_private_key_password = %{userdb:private_key_password} } } As a workaround, I now have to: • store the private key as a file (e.g. %{home}/privkey.pem) • pass only the password via userdb • inject the path indirectly via static config + userdb variables This works, but is less elegant: protocol imap { crypt_global_private_key user { crypt_private_key_file = %{home}/privkey.pem crypt_private_key_password = %{userdb:private_key_password} } } Again, with the new named filter mechanism, it’s no longer possible to directly inject such config values via userdb, which makes fully dynamic per-user key provisioning harder. I now have to export all encrypted private keys from the database to the users home directory. Ömer Hi, I've run into what appears to be a regression (or at least a behavioral change) in Dovecot 3.3.0+ / current HEAD regarding crypt_private_key_file handling for the crypt_global_private_key. I don`t use per-folder user keys but a global encryption key per user. Previously, it was possible to provide the private key via userdb using an inline base64:-encoded PEM directly to the crypt_global_private_key_file and Dovecot would correctly parse and use it. With the latest config scheme change, this no longer works, as you cannot really set named config variables from userdb. I did workaround by setting a custom userdb variable and setting the needed named/filter variables manually in the config file. To make it work, I had to enclose the config in a "protocol imap" scope. The crypt_global_public_key_file is accessible from userdb (as it is not within a named filter scope), so inline-base64 works as with Dovecot 2.3+. When using the following workaround to reach the scoped variables, Dovecot tries to load the file "inline:BASE64ENCODEDPEM" as a literal filename (error open(inline:AB....C==) failed): protocol imap { crypt_global_private_key user { crypt_private_key_file = %{userdb:private_key_file} crypt_private_key_password = %{userdb:private_key_password} } } As a workaround, I now have to: o store the private key as a file (e.g. %{home}/privkey.pem) o pass only the password via userdb o inject the path indirectly via static config + userdb variables This works, but is less elegant: protocol imap { crypt_global_private_key user { crypt_private_key_file = %{home}/privkey.pem crypt_private_key_password = %{userdb:private_key_password} } } Again, with the new named filter mechanism, it's no longer possible to directly inject such config values via userdb, which makes fully dynamic per-user key provisioning harder. I now have to export all encrypted private keys from the database to the users home directory. Oemer

4 10