April 2026 - dovecot - dovecot.org

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

[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

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

Sync'ing two dovecot servers
by Marc Singer 12 May '26

12 May '26

Greetings, I was pleased to see that dovecot has a sync function in doveadm. So far, other tools for moving mailbox contents from one server to another has not been successful. However. Perhaps I don't understand how this should work. I have a new containerized dovecot v2.4.2 # 2.4.2 (0962ed2104): /etc/dovecot/dovecot.conf # OS: Linux 6.12.63+deb13-amd64 x86_64 and I have an existing dovecot running in a VPS: # 2.3.19.1 (9b53102964): /etc/dovecot/dovecot.conf # Pigeonhole version 0.5.19 (4eae2f79) # OS: Linux 6.1.0-35-amd64 x86_64 Debian 12.11 I want to move one user, as a test. I execute this in the container. # doveadm sync -R1 -u USER tcps:OLD_SERVER:993 doveadm(USER): Error: conn OLD_SERVER:993 (IP:993): doveadm server sent invalid handshake: * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN AUTH=LOGIN] Dovecot (Debian) ready. doveadm(USER): Error: cmd sync: Disconnected from remote: Connection closed I'm pretty sure that doveadm sync was able to negotiate the TLS connection. I don't see what it could object to in the sign-on. What am I missing? Cheers -- /Marc Oscar Singer/ *Woollysoft* Dial 817.1823.602.1+ from right to left. Greetings, I was pleased to see that dovecot has a sync function in doveadm. So far, other tools for moving mailbox contents from one server to another has not been successful. However. Perhaps I don't understand how this should work. I have a new containerized dovecot v2.4.2 # 2.4.2 (0962ed2104): /etc/dovecot/dovecot.conf # OS: Linux 6.12.63+deb13-amd64 x86_64 and I have an existing dovecot running in a VPS: # 2.3.19.1 (9b53102964): /etc/dovecot/dovecot.conf # Pigeonhole version 0.5.19 (4eae2f79) # OS: Linux 6.1.0-35-amd64 x86_64 Debian 12.11 I want to move one user, as a test. I execute this in the container. # doveadm sync -R1 -u USER tcps:OLD_SERVER:993 doveadm(USER): Error: conn OLD_SERVER:993 (IP:993): doveadm server sent invalid handshake: * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN AUTH=LOGIN] Dovecot (Debian) ready. doveadm(USER): Error: cmd sync: Disconnected from remote: Connection closed I'm pretty sure that doveadm sync was able to negotiate the TLS connection. I don't see what it could object to in the sign-on. What am I missing? Cheers -- Marc Oscar Singer Woollysoft Dial 817.1823.602.1+ from right to left.

5 7

Confusion about ldap in 2.4
by fc26wuqa＠studserv.uni-leipzig.de 28 Apr '26

28 Apr '26

Hello, With dovecot 2.3 it was clear to me, how I should set up ldap: Include `conf.d/auth-ldap.conf.ext` in `conf.d/10-auth.conf` and include `dovecot-ldap.conf.ext` with the usual parameters like hosts, uris, dn, etc. In dovecot 2.4 I am a little bit confused about whats the best practice. I heard about that .ext files being outdated and examples in the documentation saying I should put everything in dovecot.conf? So If in 2.3 my config would look like this: ``` # auth-ldap.conf.ext passdb { driver = ldap args = /etc/dovecot/dovecot-ldap.conf.ext } userdb { driver = ldap args = /etc/dovecot/dovecot-ldap.conf.ext } ``` ``` # dovecot-ldap.conf.ext hosts = ldap.something.org:636 uris = ldaps://smoething.org dn = cn=something,ou=something,dc=something,dc=org dnspass = somethingsomething auth_bind = yes auth_bind_userdn = uid=%u,ou=something ... ``` I would put something like this in dovecot.conf? Or in auth-ldap.conf.ext? ``` ldap_uris = ldap://ldap.example.org ldap_auth_dn = cn=admin,dc=example,dc=org ldap_auth_dn_password = secret ldap_base = dc=example,dc=org passdb ldap { bind = yes filter = (&(objectClass=posixAccount)(uid=%{user})) fields { user = %{ldap:uid} } } ``` (https://doc.dovecot.org/2.4.3/core/config/auth/databases/ldap.html#dn-lookup)

1 0

Upgrading from 2.4.2 to 2.4.3 broke static password login
by harrison＠hhj.me 28 Apr '26

28 Apr '26

Hey folks, I've got dovecot running via docker on version 2.4.2. Here's what my config extension looks like: ``` # auth_mechanisms = plain login auth_verbose = yes passdb static { password = %{env:USER_PASSWORD} } service lmtp { inet_listener lmtps { port = 31024 ssl = no } } ssl_server_cert_file = /etc/dovecot/ssl/cert.pem ssl_server_key_file = /etc/dovecot/ssl/key.pem ssl = yes auth_allow_cleartext = no namespace inbox { type = private separator = / inbox = yes mailbox Drafts { special_use = \Drafts auto = subscribe } mailbox Junk { special_use = \Junk auto = create } mailbox spam { special_use = \Junk auto = no } mailbox Spam { special_use = \Junk auto = no } mailbox Trash { special_use = \Trash auto = subscribe } mailbox TRASH { special_use = \Trash auto = no } mailbox Sent { special_use = \Sent auto = subscribe } mailbox "Sent Mail" { special_use = \Sent auto = no } mailbox "Sent Messages" { special_use = \Sent auto = no } mailbox Archive { special_use = \Archive auto = create } mailbox "Archives" { special_use = \Archive auto = no } } ``` I have env `USER_PASSWORD` defined in the format of `{PLAIN}REDACTED` This has been humming along fine for a little while. I recently automatically upgraded to 2.4.3 which broke my ability to login via IMAP to retrieve emails (it also broke my local mail transport setup; it was unable to send emails). I could see the following messages in the logs: ``` Apr 27 11:12:09 auth(REDACTED,REDACTED,sasl:plain)<REDACTED>: Info: static: No password returned (and no nopassword) Apr 27 11:12:11 imap-login: Info: Login aborted: Connection closed (auth failed, 1 attempts in 6 secs) (auth_failed): user=<REDACTED>, method=PLAIN, rip=REDACTED, lip=172.17.0.2, TLS, session=<REDACTED> ``` Downgrading back to 2.4.2 "fixed" the problem (I was able to login again; LMTP worked again). I didn't change my config extension between the upgrades. I tried searching https://github.com/search?q=repo%3Adovecot%2Fcore+password&type=issues and I see a few related to passwords but nothing is really jumping out at me. Help? I'm staying pinned on 2.4.2 for now but that's not a long term solution.

2 3

Panic in logs
by Kamil Jońca 26 Apr '26

26 Apr '26

Recently I found in my lda logs: 2025-12-30T07:55:14.717927+01:00 alfa dovecot: lda(kjonca): Error: Raw backtrace: #1 [unw_get_proc_name() failed: -10] -> #2 i_syslog_fatal_handler[0x7f99a2351430] -> #3 i_panic[0x7f99a226d453] -> #4 [unw_get_proc_name() failed: -10] -> #5 [unw_get_proc_name() failed: -10] -> #6 [unw_get_proc_name() failed: -10] -> #7 buffer_append[0x7f99a2345270] -> #8 dregex_code_match_groups[0x7f99a233f1a0] -> #9 [unw_get_proc_name() failed: -10] -> #10 [unw_get_proc_name() failed: -10] -> #11 sieve_match_value[0x7f99a117f770] -> #12 sieve_match[0x7f99a117fa30] -> #13 [unw_get_proc_name() failed: -10] -> #14 sieve_interpreter_continue[0x7f99a117e100] -> #15 sieve_multiscript_run[0x7f99a1190330] -> #16 [unw_get_proc_name() failed: -10] -> #17 mail_deliver[0x7f99a27e54a0] -> #18 main[0x55e371c555e0] -> #19 __libc_start_call_main[0x7f99a1e29f00] -> #20 __libc_start_main_alias_2[0x7f99a1e29fa0] -> #21 _start[0x55e371c566a0] And sadly it seems, that mail is missing (it was passed to pipe program to further processing) KJ -- http://wolnelektury.pl/wesprzyj/teraz/ When you go out to buy, don't show your silver.

4 6

Incorrect ARC signature on emails
by Lafiel Elentari 25 Apr '26

25 Apr '26

Hello. On the mail server, I configured addition of the `Authentication-Results` header with authentication check results. I noticed that emails from the dovecot.org server have an incorrect ARC signature: Authentication-Results: ...; dkim=pass header.d=dovecot.org header.s=... header.b=...; dkim=fail ("body hash did not verify") header.d=... header.s=... header.b=...; arc=reject ("signature check failed: fail, {[1] = sig:dovecot.org:reject}"); spf=pass (...: domain of "dovecot-bounces+...=...(a)dovecot.org" designates ... as permitted sender) smtp.mailfrom="dovecot-bounces+...=...(a)dovecot.org"; dmarc=pass (policy=reject) header.from=dovecot.org ``` -- Best regards, Lafiel Elentari mailto:lafiel@elven.pw

2 2

mbox to maildir migration, same server?
by kjohnson＠eclypse.org 25 Apr '26

25 Apr '26

What is the recommended procedure to migrate from mbox to maildir on a server already running dovecot? Ideally, this procedure would convert messages in an existing mbox INBOX and in ~/mail mboxes (as defined in my dovecot configuration) to storage in a ~/Maildir. Some of the INBOXs are rather large -- 100's of MB (one of the reasons for migrating). What I have tried has not worked for me. Below, I describe what I tried, how I tested before I tried, what went wrong, and the current setup (pre-migration). What I tried: ============= stop exim4 service dovecot stop Make dovecot listen only locally, not to external connections. /etc/dovecot/local.conf protocol imap { listen = 127.0.0.1:143 ssl_listen = 127.0.0.1:993 } protocol pop3 { listen = 127.0.0.1:110 ssl_listen = 127.0.0.1:995 } Modify dovecot configuration for maildir: Watch capitalization! #in 10-mail.conf: mail_location = maildir:/home/%u/Maildir namespace inbox { separator = / } dovecot -n, to confirm results and perform limited syntax checking. service dovecot start for each user, in a bash script: dsync -v -u "$U" mirror "mbox:/home/$U/mail:INBOX=/var/mail/$U" (if the conversion worked for all users, then reconfigure exim to use maildir and restart it; reconfigure dovecot to listen to external interfaces and restart.) How I tested: ============= Before trying this on the real server, I set up a matching (same versions of Debian, Exim, and Dovecot) VM using mbox, with a couple of accounts. One using POP3, one using IMAP. The IMAP account was accessed from Claws and from Outlook. The test accounts had perhaps a dozen messages on the server. I tried the conversion procedure, and everything I tried worked flawlessly. (Yes, next time I will move some real inbox files from the live server). What went wrong: ================ I encountered two types of problems here. The first was several dsync warnings (username changed): dsync(example): Warning: Mailbox changes caused a desync. You may want to run dsync again: Remote lost mailbox GUID 21bfa11a81f11763ac150000d09efc50 (maybe it was just deleted?) As I understand it, this can result in some or all messages being downloaded again by clients. My understanding may be wrong. I also don't understand how the mailbox could have changed -- exim4 was stopped, dovecot is only listening on 127.0.0.1, and I am the only user who uses a local mail client on that system, and this was not my account. The second problem I encountered seems to match Debian Bug report logs - #1011238. In part of the discussion of that report, the reporter mentions adding -1 to the command, as shown: dsync -v -u "$U" mirror -1 "mbox:/home/$U/mail:INBOX=/var/mail/$U" While this seemed to eliminate the dsync panic of #1011238, as far as I can tell, no old messages were actually moved from the old mbox files to the new maildirs. At that point I restored the backup mbox files and undid the changes to dovecot and exim4. Current setup: ============== Debian 11.4 Exim 4.94.2-7 dovecot 1:2.3.13+dfsg1-2 The current setup with Dovecot was a successful migration from IMAP-UW in December 2020. Output from dovecot -n (the list of trusted networks has been removed) # 2.3.13 (89f716dc2): /etc/dovecot/dovecot.conf # Pigeonhole version 0.5.13 (cdd19fe3) # OS: Linux 5.10.0-16-686-pae i686 Debian 11.4 # Hostname: localhost auth_verbose = yes mail_location = mbox:~/mail:INBOX=/var/mail/%u mail_privileged_group = mail namespace inbox { inbox = yes location = mailbox Drafts { special_use = \Drafts } mailbox Junk { special_use = \Junk } mailbox Sent { special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } mailbox Trash { special_use = \Trash } prefix = } passdb { driver = pam } pop3_uidl_format = %08Xv%08Xu protocols = " imap pop3" ssl_cert = </etc/dovecot/dovecot.pem ssl_client_ca_dir = /etc/ssl/certs ssl_dh = # hidden, use -P to show it ssl_key = # hidden, use -P to show it userdb { driver = passwd } Thank you to anyone who read this far. Ken

5 5