April 2026 - dovecot - dovecot.org

Sieve vnd.dovecot.config extension does not work when mail is delivered to lmtp inet_listener but works when delivered to lmtp unix_listener
by DK 20 Jul '26

20 Jul '26

Hello. I have a strange problem with sieve scripts vnd.dovecot.config extension processing on newest dovecot 2.3 and 2.4. When I deliver mail via lmtp unix_listener sieve script can get sieve_env_* variable with no problem. However when I deliver mail via lmtp inet_listener sieve script can not get the same sieve_env_* variable. I deliver mails from postfix to lmtp inet_listener directly (not via haproxy). The same postfix is used when testing lmtp unix_listener mail delivery which works. Any clues what could be the cause of such problem? DK

2 3

imap-sieve, question concerning "sieve_user_email" and variables, migration from 2.3 to 2.4
by Claus-Justus Heine 14 Jul '26

14 Jul '26

Hi there, I have a question concerning the configuration setting sieve_user_email In a v2.3 setup I had it set to sieve_user_email = %Ln(a)some.concrete.domain Now I am trying to migrate to v2.4 and thought the direct translation from the old variable expansion scheme to the new scheme deployed in v2.4 would be sieve_user_email = %{user|username|lower}(a)some.concrete.domain However, this does not work. Testing the documentation yields the following error: # dovecot -n -c dovecot.conf > /dev/null doveconf: Error: sieve: sieve settings: Failed to parse configuration: Failed to expand sieve_user_email setting variables: Unknown variable 'user' doveconf: Fatal: Error in configuration file dovecot.conf: Failed to initialize Sieve Setting "sieve_user_email" to something without variable expansion or just commenting it out yields a configuration which is accepted by "dovecot -n". Now I wonder: a) v2.3 did not complain. But perhaps just because it was using "%Ln" literally? b) In case it did work in v2.3, should it work in v2.4 also? And if so: what would be the correct syntax / variable names? c) Under which circumstances is this setting "sieve_user_email" used? The documentation states: https://doc.dovecot.org/main/core/summaries/settings.html#sieve_user_email > The primary e-mail address for the user. > > This is used as a default when no other appropriate address is available for sending messages. > > If this setting is not configured, either the postmaster or null <> address is used as a sender, depending on the action involved. > > This setting is important when there is no message envelope to extract addresses from, such as when the script is executed in IMAP. I thought that then it would make sense to use something which depends on the login-name of the IMAP-user? Or was this "sieve_user_email" intended to hold just one static email like "my_global_catch_all(a)some.concrete.domain"? Kind thanks for clarification, best regards Claus -- Claus-Justus Heine himself(a)claus-justus-heine.de http://www.claus-justus-heine.de/ Schatzmeister der Camerata Academica Freiburg e.V. --- www.cafev.de

2 3

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

14 Jul '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

5 11

Announcement: wormhole plugin, replication for Dovecot 2.4
by Patrick Cernko 12 Jun '26

12 Jun '26

Hello List, I am proud to announce my project "wormhole". This is an extension for Dovecot 2.4.1. It allows to continue the use of the replication feature of Dovecot that was removed with the 2.4 release. History: I started this project by forking the replication code of Dovecot 2.3.21.1 and porting it to 2.4. The first result was a patch for Dovecot 2.4.1. While working with the code, I realized that it is possible to provide the feature as a plugin / extension. In the first release of the plugin, I tried to integrate it with the existing dsync commands for doveadm. This required an API for access to the dsync commands, which I proposed to the Dovecot developers in https://github.com/dovecot/core/pull/249 . Unfortunately, my pull request was rejected, though I can understand the reasons for that. Without the required API, I had to switch to another approach: I forked the dsync code from doveadm to provide a new set of commands: "repl" and "repl-server". These commands work similar to "sync" and "dsync-server" but use additional functions required by the replication feature. This approach was released as version 0.3 of the plugin. With version 0.4 I renamed the project to wormhole. Before that it was just called dovecot-replication (see https://codeberg.org/errror/dovecot-replication) I thought that the project should have a more unique name. Currently I'm working on designing a test suite for wormhole. Doing unit tests of the components is not sufficient IMHO. The test suite should check the whole replication feature using two running dovecot instances that replicate the users' mailboxes. Having a sophisticated test suite will help in future development and bug tracking. The code can be found on my codeberg site at: https://codeberg.org/errror/wormhole There is also a web page on my personal homepage at: https://people.mpi-klsb.mpg.de/~pcernko/wormhole.shtml The project is still missing documentation. For the moment, configuration is similar to the existing Dovecot 2.3 documentation. Upgrading from 2.3: When using the included patch for Dovecot, the plugin should be 100% compatible with existing Dovecot 2.3 servers. This compatibility should allow uninterrupted upgrades of the service by replacing Dovecot on one server and then the other one. After the upgrade, the plugin can be reconfigured to work without the patch for Dovecot. Upgrading without the patch is also possible. During the upgrade (aka "while one server still runs 2.3") some aspects of the replication will not work or lack performance. Upgrading is not yet tested very well and missing documentation also. I will work on that soon. I hope to get some feedback, pull requests or bug reports via mail or at codeberg (preferred). -- 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

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 22 May '26

22 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 11

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

[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

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