May 2026 - dovecot - dovecot.org

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

Panic: file charset-iconv.c: line 83 (charset_to_utf8_try): assertion failed: (srcleft <= CHARSET_MAX_PENDING_BUF_SIZE)
by Alex Rosenberg 15 May '26

15 May '26

Attached is an LLM-reduced reproduction of the crash in the title. My particular setup is dovecot 2.3.21.1 (d492236fa0) in a FreeBSD jail (13.5). I realize that this is an older release but there is no FreeBSD port/pkg for dovecot 2.4.x yet. The message in the attachment is reduced from an old (2017!) email to one of the LLVM compiler mailing lists. The original malformed email had this header: X-Mailer: Evolution 3.22.5 (3.22.5-1.fc25) The bug occurs when dovecot's FTS indexer processes a MIME part that: 1. Declares charset="UTF-7" 2. Contains base64-encoded content that, when decoded, has bare '+' characters 3. Causes UTF-7 decoder buffer overflow in charset-iconv.c:83 The base64 content decodes to C source code with expressions like: - argc + 4 - state++ - state-- These '+' characters in UTF-7 context cause the decoder's pending buffer to exceed CHARSET_MAX_PENDING_BUF_SIZE, triggering the assertion failure. Alex

4 5

Can't find unicode/ustring.h in test
by mr.thesaw＠gmail.com 14 May '26

14 May '26

I get this error during compilation: make[3]: Entering directory '/home/hacksaw/src/dovecot-2.4.4/src/lib-language' CC test-lang-icu.o In file included from test-lang-icu.c:8: lang-icu.h:4:10: fatal error: unicode/ustring.h: No such file or directory 4 | #include <unicode/ustring.h> | ^~~~~~~~~~~~~~~~~~~ compilation terminated. I have unicode 66, at least as far as Ubuntu is concerned.

2 8

Dovecot 2.4.4 - mail_crypt with per-user Global Keys from LDAP (not Folder Keys)
by luis.neapolis＠gmail.com 14 May '26

14 May '26

Hi everyone, I'm trying to configure Dovecot 2.4.4 with per-user encryption keys stored in LDAP, using Global Keys mode (NOT Folder Keys). My goal: Each user has their own public key and private key (encrypted with the user's login password) stored in LDAP attributes. 1) LMTP should use the public key to encrypt incoming emails. 2) IMAP should use the user's login password to decrypt the private key from LDAP, then decrypt the emails. I want to use Global Keys mode (where keys are provided via userdb), NOT Folder Keys (where Dovecot stores keys in dovecot-attributes files). What works: LMTP receives emails and encrypts them correctly using the user's public key from LDAP and the encrypted files are saved to disk. What doesn't work: IMAP can log in and see the email list (subject, from, date), but the email body never loads. Error: Decryption error: no private key available May 14 18:58:45 host dovecot[295725]: imap(test(a)example.com)<295760><SESSIONID>: Debug: Mailbox INBOX: UID 11: Opened mail because: prefetch May 14 18:58:45 host dovecot[295725]: imap(test(a)example.com)<295760><SESSIONID>: Debug: dict(file): Looking up 'priv/a82ea60599ba056ad47904003a5aeee9/vendor/vendor.dovecot/pvt/crypt/privkeys/aacbcb614fb59f81e9519186b12ac8862858d89fa3bcc1be5f25b886d3e95ee3' May 14 18:58:45 host dovecot[295725]: imap(test(a)example.com)<295760><SESSIONID>: Debug: dict(file): Lookup finished for 'priv/a82ea60599ba056ad47904003a5aeee9/vendor/vendor.dovecot/pvt/crypt/privkeys/aacbcb614fb59f81e9519186b12ac8862858d89fa3bcc1be5f25b886d3e95ee3': not found May 14 18:58:45 host dovecot[295725]: imap(test(a)example.com)<295760><SESSIONID>: Error: Mailbox INBOX: UID 11: read() failed: read(/mail/example.com/test/cur/1778773528.M279604P294174.host.example.com,… failed: Decryption error: no private key available (FETCH BODY[1]) The confusing part: IMAP has the user's password (the user authenticated successfully). The private key in LDAP is encrypted with that same password. So IMAP should be able to decrypt the private key, then decrypt the email. But Dovecot is not using the password it already has to unlock the private key. My configuration: dovecot_config_version = 2.4.4 mail_plugins { quota = yes } # Empty global key block (workaround for LMTP not to fail) crypt_global_private_key main { } passdb ldap { driver = ldap filter = (&(objectClass=Account) (mail=%{user})) fields { mail = %{ldap:mail} password = %{ldap:userPassword} userdb_home = %{ldap:homeDirectory} } } userdb ldap { driver = ldap filter = (&(objectClass=Account) (mail=%{user})) fields { home = %{ldap:homeDirectory} uid = %{ldap:uidNumber|default('500')} gid = %{ldap:gidNumber|default('500')} # Per-user keys from LDAP (Global Keys mode) crypt_global_public_key_file = inline:%{ldap:userPublicKey} crypt_global_private_key/main/crypt_private_key_file = inline:%{ldap:userPrivateKey} crypt_private_key_password = %{password} } } protocol imap { mail_plugins { imap_quota = yes mail_crypt = yes } protocol lmtp { mail_plugins { sieve = yes mail_crypt = yes } } Note: I do NOT have mail_attribute_dict configured. I do NOT want Dovecot to store keys in local files. I want everything to come from LDAP. What I've verified: 1) The private key is valid and decrypts correctly with the user's password using openssl pkey -passin pass:xxx. 2) doveadm user shows the keys are retrieved from LDAP. The error persists. The question: Since IMAP already has the user's password (from the successful login), how can I make Dovecot use that password to decrypt the private key from LDAP and then decrypt the emails? Is there a specific setting I'm missing? Does crypt_private_key_password = %{password} need to be placed somewhere else (e.g., inside the protocol imap block) to work correctly? Also, I see in the logs that Dovecot is still looking for dict(file) keys (Folder Keys mode). How can I completely disable Folder Keys behavior and force Dovecot to only use Global Keys from LDAP? Thank you! Dovecot version: 2.4.4-5 OS: AlmaLinux 9.7 Mail storage: Maildir

1 0

Backup problem
by Doug Hardie 13 May '26

13 May '26

I just migrated my mail server to a new machine. When the new machine was back up and running, I found one mailbox that used to have many emails, now only had 3. I went back to the old machine and found there were only those three messages in the mailbox. I suspect somehow I managed to delete them prior to the backup to the new machine. I have a copy of that mailbox on a backup machine. I just checked and all are there. They have file names like: 1658299911.M966551P8821.mail,S=5001,W=5108:2,S 1664572476.M701757P94428.mail,S=4051,W=4135:2,Sab 1665119988.M609674P37848.mail,S=8455,W=8629:2,Sab 1665757235.M137163P32739.mail,S=5838,W=5950:2,S 1665774793.M299412P37846.mail,S=4669,W=4755:2,S 1665782571.M706364P40033.mail,S=12191,W=12379:2,S The backup machine has all the dovecot files for that user. How can I restore those email from the backup machine to the new server? -- Doug

2 1

Can I use a static userdb or no?
by social+17dw1scw＠lombra.net 13 May '26

13 May '26

Hi, I've been researching this for a while now, and can't find a definitive answer. I have a virtual setup, with globally static UID, GID and mail locations set. The documentation is clear that this lets me use a static userdb instead of SQL. But then, doveadm mailbox list -A requires that a valid iterate_query is set, and that requires an SQL userdb. So, which is it? If querying does not work with a static userdb, that seems like a significant caveat. I'm also curious how this works with prefetch. I understand I can make the passdb query return static values, but I figure since I already have those configured, I shouldn't need to do that. How can I determine whether prefetching is working as intended? Thank you.

3 2

postfix/dovecot migration
by Bryan Simmons 13 May '26

13 May '26

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

2 1

Expand dovecot recipients from ldap group
by Maksim Rodin 13 May '26

13 May '26

Hello, I have set up dovecot (2.3.21) to get its recipients from Active Directory. I can successfully get recipients from Active Directory user objects using their sAMAccountName: # cat /etc/dovecot/local.conf ... passdb users { driver = ldap args = /etc/dovecot/dovecot-ldap_domain.conf.ext } userdb users { driver = static args = uid=vmail gid=vmail } ... Here is the relevant part of the ldap config: # cat /etc/dovecot/dovecot-ldap_domain.conf.ext ... user_attrs = \ =home=/vmail/%{ldap:sAMAccountName}, \ =uid=vmail, \ =gid=vmail pass_filter = (&(objectCategory=person)(mail=%u)) user_filter = (&(objectCategory=person)(mail=%u)) ... I can also successfully get user aliases from Active Directory user objects using their otherMailbox attribute: # cat /etc/dovecot/local.conf ... userdb aliases { driver = ldap args = /etc/dovecot/dovecot-ldap_domain_aliases.conf.ext } ... Here is the relevant part of the ldap config: # cat /etc/dovecot/dovecot-ldap_domain_aliases.conf.ext: ... user_attrs = \ =home=/vmail/%{ldap:sAMAccountName}, \ =uid=vmail, \ =gid=vmail pass_filter = (&(objectCategory=person)(otherMailbox=%u)) user_filter = (&(objectCategory=person)(otherMailbox=%u)) Now I am struggling with the task of getting recipients from Active Directory group objects to handle them as distribution groups. Is there a way to expand an Active Directory group object to multiple recipients? I know all of this can be done with postfix ldap module, but I would like to handle all the delivery tasks to dovecot LMTP. -- Best regards Maksim Roin

1 0