- dovecot - dovecot.org

sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
by michael.merz＠wtnet.de 10 Jul '26

10 Jul '26

Hello, I've been evaluating sieve-test (Pigeonhole, dovecot-sieve package, version 2.3.21, as shipped with Ubuntu 24.04 LTS) as an offline testing tool for a personal Sieve ruleset that currently runs on a Cyrus IMAPd/CMU Sieve 3.0 backend. I'd like to ask for some clarification on two points, in case I'm missing a configuration option. 1) PCRE support My ruleset makes extensive use of the `(?i)` inline case-insensitivity flag within :regex tests, which is valid under PCRE (as used by Cyrus). When running sieve-test, I get: error: invalid regular expression '(?i)...' for regex match: invalid preceding regular expression. Checking `dovecot --build-options` shows no PCRE entry, which suggests the Ubuntu-packaged binary was compiled without --with-pcre and falls back to POSIX extended regex. Question: Is PCRE support in Pigeonhole's regex extension purely a compile-time decision (i.e. something that would need to be addressed at the distribution packaging level, not via runtime configuration), or is there a runtime way to enable PCRE matching that I might have missed (e.g. via -o, sieve_extensions, or similar)? 2) Return-Path in the `address` test Several of my rules use: address :domain :is "return-path" "..." Cyrus accepts this. Pigeonhole's sieve-test rejects it with: error: specified header 'return-path' is not allowed for the address test. I understand this is likely an RFC 5228 strictness difference (Cyrus being more permissive than the RFC requires). Is there a recommended alternative within Sieve itself to achieve the same effect (testing the address portion of Return-Path) while staying within what Pigeonhole accepts - e.g. via the `header` test combined with some address-parsing approach, or via the envelope test instead? For context: I'm not running a Dovecot mail server myself. I'm using sieve-test purely as an offline syntax/behaviour verification tool before deploying ruleset changes to a separate Cyrus-based production system. I understand this is a bit of an unusual use case, so any guidance on whether Pigeonhole is well suited for this kind of cross-implementation testing at all would also be appreciated. Thank you for your time and for maintaining Pigeonhole. Best regards, Michael Merz Hello, I've been evaluating sieve-test (Pigeonhole, dovecot-sieve package, version 2.3.21, as shipped with Ubuntu 24.04 LTS) as an offline testing tool for a personal Sieve ruleset that currently runs on a Cyrus IMAPd/CMU Sieve 3.0 backend. I'd like to ask for some clarification on two points, in case I'm missing a configuration option. 1) PCRE support My ruleset makes extensive use of the `(?i)` inline case-insensitivity flag within :regex tests, which is valid under PCRE (as used by Cyrus). When running sieve-test, I get: error: invalid regular expression '(?i)...' for regex match: invalid preceding regular expression. Checking `dovecot --build-options` shows no PCRE entry, which suggests the Ubuntu-packaged binary was compiled without --with-pcre and falls back to POSIX extended regex. Question: Is PCRE support in Pigeonhole's regex extension purely a compile-time decision (i.e. something that would need to be addressed at the distribution packaging level, not via runtime configuration), or is there a runtime way to enable PCRE matching that I might have missed (e.g. via -o, sieve_extensions, or similar)? 2) Return-Path in the `address` test Several of my rules use: address :domain :is "return-path" "..." Cyrus accepts this. Pigeonhole's sieve-test rejects it with: error: specified header 'return-path' is not allowed for the address test. I understand this is likely an RFC 5228 strictness difference (Cyrus being more permissive than the RFC requires). Is there a recommended alternative within Sieve itself to achieve the same effect (testing the address portion of Return-Path) while staying within what Pigeonhole accepts -- e.g. via the `header` test combined with some address-parsing approach, or via the envelope test instead? For context: I'm not running a Dovecot mail server myself. I'm using sieve-test purely as an offline syntax/behaviour verification tool before deploying ruleset changes to a separate Cyrus-based production system. I understand this is a bit of an unusual use case, so any guidance on whether Pigeonhole is well suited for this kind of cross-implementation testing at all would also be appreciated. Thank you for your time and for maintaining Pigeonhole. Best regards, Michael Merz

4 3

Client sent invalid input for CATEGORY
by Mail Operations 09 Jul '26

09 Jul '26

Hello list We are running a dovecot 2.4 instance and the following errors start to pop up after a listener is configured to scrape metrics with Prometheus: ... dovecot[2090309]: stats: Error: conn unix:stats (pid=2090333,uid=108): Client sent invalid input for CATEGORY: Category parent 'ssl' changed to 'ssl' (input: CATEGORY ssl-client ssl) Stats listener config: service stats { inet_listener http { port = 9090 ssl = yes } } So far I failed to reliably trigger the error messages and it looks like they appear randomly. Besides the logged errors, everything seems to work correctly. Could this be a possible bug, or configuration error? Kind regards, Patrik

2 2

doveadm backup / purge problems since migration from 2.3 to 2.4
by MK 09 Jul '26

09 Jul '26

Hi everyone, I have a two-server setup where all user data from the actively used server is periodically transferred to the second server using "doveadm backup". For this, I currently use a script that caches a list of all users (containing only the usernames) via "doveadm user '*' " and then executes the command "doveadm backup -u [username] tcp:1.2.3.4" (target host) for each user. I use a similarly structured script for a daily "doveadm purge", where a purge is performed per user instead of a backup. Under version 2.3, I always ran both commands using the "-A" flag (doveadm purge -A and doveadm backup -A tcp:1.2.3.4). Since migrating from Dovecot 2.3 to 2.4, this no longer works. When running the purge, the process always aborts after a certain number of users with the following error message: doveadm(john(a)doe.de): Error: auth-master: userdb list: User listing returned failure It's not the same User allways but after nearly the same time or amount of users the script has processed. Since I couldn't identify the exact cause of the error and suspect it might be related to changes in how the SQL iterate query is integrated in the 2.4 configuration (I use MySQL as the backend) I switched to the script described above. Then since is used the new script I have a non-reproducible issue. After the initial data transfer (when the target is still empty) the amount of data is equal to the source. Then after one of the next transfers the data is twice as high. It is random as to which subsequent transfer triggers this. When comparing the quotas on the source and target server, the output is identical on both. Even running `quota recalc` makes no difference. If I check the user directories, I can see that the `storage` folder contains nearly double the number of files and used disk space per user. My second problem is that when I run the purge script on the second server (target), it sometimes deletes all emails for all users, also non-reproducible. Afterwards, all files under "storage" are gone, and the quota shows 0 emails. I did not have this issue with the exactly same purge script on the first server which is the source for the backup. The version change was during the update from Debian 12 to 13, involving an upgrade of Dovecot from version 2.3.19 to 2.4.1. (both packages from debian repo) We use MySQL as the backend and mdbox as the storage format. I hope some can help me to solve this issue. Greetings, Oliver

2 1

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

06 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 9

Bug report: doveadm kick does not kick proxy sessions
by Patrick Cernko 06 Jul '26

06 Jul '26

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. In the previous Dovecot 2.3 setup 'doveadm proxy kick' is not yet an alias for 'doveadm kick' and works as expected by disconnection the specified proxy sessions. 'doveadm kick' behaves similar to Dovecot 2.4 (not kicking proxy sessions) but that is understandable given that the documentation describes the dedicated kick command for proxy sessions. If this is the intended behavior for 'doveadm kick', how can I disconnect specific *proxy* sessions? If this is a bug, could you please fix it in the next releases or at least provide a patch that I can apply on my own build? I verified the bug exists in the latest dovecot packages for Debian Trixie from repo.dovecot.org. Attached is the doveconf -n output for my test setup. 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

How to use sieve_env_ variables in 2.4.4?
by inaugurator＠ya.ru 01 Jul '26

01 Jul '26

Hi Dear Devs! In the previous version 2.3.x I used variables with the **sieve_env_** prefix to access them later in Sieve scripts, for example `sieve_env_hello = hello` changed to `"${env.vnd.dovecot.config.hello}"`. But now I am getting an error ``` doveconf: Fatal: Error in configuration file /etc/dovecot/dovecot.conf line 11: sieve_env_hello: Unknown setting: sieve_env_hello ``` Thank you in advance!

1 0

The SORT extension in 2.4.4 over imapc never returns any UIDs
by inaugurator＠ya.ru 29 Jun '26

29 Jun '26

Hi guys! This is really annoying. On the command to dovecot over imapc from another one: "UID SEARCH ALL" I get my UIDs: "* SEARCH 1 2 3 4" But when sending: "UID SORT (REVERSE ARRIVAL) US-ASCII NOT DELETED" I get literally nothing: "* SORT" Sorry, but this is a bug. Thank you!

3 7

dsync does not like sieve
by Stéphane Veyret 27 Jun '26

27 Jun '26

Hi, I’m using Dovecot for many years. My installation is configured to manage spam using sieve. In the same time, I have a backup server, connecting to the main server every night in order to backup emails (note that the main server is not pushing its data, but the backup server is pulling them). Dovecot v2.4 made me re-write the configuration files, so maybe I missed something, but since then, I cannot make both these service work in the same time. With my current configuration, the backup server is terminating in error with the following logs: dsync-remote(example(a)example.com)<HbkSGoKQG2o8+gEAGKlOPA>: Error: brain S: Exporting mailbox INBOX failed: Mailbox attribute iteration failed: Internal error occurred. Refer to server log for more information. [2026-05-31 03:36:03] (and there are no more logs anywhere). Because this message <https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/MGCGR…> was suggesting there could be a problem with sieve, I tried to modify the configuration. And indeed, when changing sieve configuration, the backup is working again. But then, my spam filter isn’t anymore. Here are the relevant parts of the configuration for managing sieve. Can someone help me saying what could be wrong? protocols { sieve = yes imap = yes lmtp = yes } sieve_extensions { fileinto = yes reject = yes envelope = yes encoded-character = yes vacation = yes subaddress = yes comparator-i;ascii-numeric = yes relational = yes regex = yes imap4flags = yes copy = yes include = yes body = yes variables = yes enotify = yes environment = yes mailbox = yes date = yes index = yes ihave = yes duplicate = yes mime = yes foreverypart = yes extracttext = yes vnd.dovecot.pipe = yes vnd.dovecot.environment = yes } sieve_pipe_bin_dir = /etc/dovecot/sieve sieve_pipe_socket_dir = sieve-pipe sieve_plugins { sieve_imapsieve = yes sieve_extprograms = yes } service managesieve-login { inet_listener sieve { port = 4190 } } sieve_script personal { } sieve_script default { path = /etc/dovecot/sieve/spam.sieve } protocol imap { mail_plugins { acl = yes quota = yes imap_acl = yes imap_quota = yes imap_sieve = yes } } protocol lmtp { mail_plugins { acl = yes quota = yes sieve = yes } } namespace user { inbox = yes prefix = separator = / type = private mailbox * { sieve_script reportspam { cause = flag path = /etc/dovecot/sieve/report-spam.sieve type = before } } } Thank you. Stéphane -- Bien cordialement, / Plej kore, Stéphane Veyret Hi, I'm using Dovecot for many years. My installation is configured to manage spam using sieve. In the same time, I have a backup server, connecting to the main server every night in order to backup emails (note that the main server is not pushing its data, but the backup server is pulling them). Dovecot v2.4 made me re-write the configuration files, so maybe I missed something, but since then, I cannot make both these service work in the same time. With my current configuration, the backup server is terminating in error with the following logs: dsync-remote([1]example(a)example.com)<HbkSGoKQG2o8+gEAGKlOPA>: Error: brain S: Exporting mailbox INBOX failed: Mailbox attribute iteration failed: Internal error occurred. Refer to server log for more information. [2026-05-31 03:36:03] (and there are no more logs anywhere). Because [2]this message was suggesting there could be a problem with sieve, I tried to modify the configuration. And indeed, when changing sieve configuration, the backup is working again. But then, my spam filter isn't anymore. Here are the relevant parts of the configuration for managing sieve. Can someone help me saying what could be wrong? protocols { sieve = yes imap = yes lmtp = yes } sieve_extensions { fileinto = yes reject = yes envelope = yes encoded-character = yes vacation = yes subaddress = yes comparator-i;ascii-numeric = yes relational = yes regex = yes imap4flags = yes copy = yes include = yes body = yes variables = yes enotify = yes environment = yes mailbox = yes date = yes index = yes ihave = yes duplicate = yes mime = yes foreverypart = yes extracttext = yes vnd.dovecot.pipe = yes vnd.dovecot.environment = yes } sieve_pipe_bin_dir = /etc/dovecot/sieve sieve_pipe_socket_dir = sieve-pipe sieve_plugins { sieve_imapsieve = yes sieve_extprograms = yes } service managesieve-login { inet_listener sieve { port = 4190 } } sieve_script personal { } sieve_script default { path = /etc/dovecot/sieve/spam.sieve } protocol imap { mail_plugins { acl = yes quota = yes imap_acl = yes imap_quota = yes imap_sieve = yes } } protocol lmtp { mail_plugins { acl = yes quota = yes sieve = yes } } namespace user { inbox = yes prefix = separator = / type = private mailbox * { sieve_script reportspam { cause = flag path = /etc/dovecot/sieve/report-spam.sieve type = before } } } Thank you. Stephane -- Bien cordialement, / Plej kore, Stephane Veyret References Visible links 1. mailto:example@example.com 2. https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/MGCGR…

3 2

How to use two databases in two passdb sections
by Евгений 26 Jun '26

26 Jun '26

Hello everyone! In version 2.3.21, I used two databases where each passdb queried its own database. After upgrading to 2.4.4, I cannot figure out how to restore this functionality. Is it no longer possible to use two databases in a single configuration after upgrade? Thank you for the best MDA!

3 2

Issues with syncing of shared mailboxes
by fc26wuqa＠studserv.uni-leipzig.de 26 Jun '26

26 Jun '26

Hello, I have a two users, that have a personal mailbox and a shared mailbox. They have access to the same shared mailbox. Today they notified me, that a mail send to the shared mailbox exists for the one user but not the other. The user also notified me, that some mails are not being delivered. I haven't found anything in my log files and the postmaster has also no delivery failures. I relay my mails through another server I don't have access to though. My /etc/aliases only consists of `postmaster: root`. The relay owners said that I should change postfix' main.cf to `double_bounce_sender = postmaster` a while ago. I am also not sure if I am not getting any delivery failure notifications since then, since I don't have a `postmaster` account, but I thought this is not needed since I have the above line in `/etc/aliases`. I also tried forcing a resync of their shared and non-shared inboxes with: `doveadm force-resync -u user(a)emaildomain.com INBOX` as well as `doveadm force-resync -u user(a)emaildomain.com Shared` (as well as with `Shared\*` - I don't know if that makes a difference tbh). Here is the output of `dovecot -n`: https://bin.disroot.org/?4eac9ea90a72ff08#A2dim9VGqHAjjKcggF4ScFWpbGytePZjt… I am kind of lost where to start from here, because any other person I asked told me their mail worked fine ^^. I would highly appreciate some guidance :) Thank you. Best, Lucienne

1 0