- dovecot - dovecot.org

Mail loop storm
by Aki Tuomi 21 Sep '26

21 Sep '26

Hi! Unfortunately an ex-subscriber at hhad a catch-all/"MXGuardDog" spam-filter address that rewrites the recipient to the list posting address and re-sends. So every list message delivered there is immediately re-injected as a new post. We are taking steps to guard against this. Apologies for the extra emails. Regards Aki,

1 0

Bug report: deadlock with new doveadm protocol
by Patrick Cernko 21 Sep '26

21 Sep '26

Hi Dovecot developers, hi list, I think I found a bug in the new doveadm protocol using OSTREAM_MULTIPLEX_FORMAT_STREAM enabled in 2.4.5 (commit 16226f8021068cda43023982eca45f859164a2d9). For very specific mailboxes (so far I only found 2 users in our setup), the following command runs into a deadlock: doveadm sync -l 30 -u USERNAME tcp:OTHER_SERVER If I start the command with debugging enabled (-D), the command successfully finishes after less than a second (the mailbox is rather small). This looks to me like a race condition which is not triggered when enabling debug output (some call this a heisenbug). Both processes (doveadm and doveadm-server on the OTHER_SERVER) are hanging in epoll_wait(). To create a backtrace, I have sent a SIGSEGV to the processes, once on the source server, once on the other. This resulted in a coredump and termination of the other process due to EOF. Here are the backtraces of those coredumps: PID: 3975605 (doveadm) UID: REDACTED (REDACTED) GID: REDACTED (REDACTED) Signal: 11 (SEGV) Timestamp: Mon 2026-09-21 10:54:13 CEST (2h 19min ago) Command Line: $'doveadm [REDACTED recv_mailbox_tree_deletes]' Executable: /usr/bin/doveadm Control Group: /user.slice/user-0.slice/session-87057.scope Unit: session-87057.scope Slice: user-0.slice Session: 87057 Owner UID: 0 (root) Boot ID: e3d3c33d72164c98b58575bc3ad98ff5 Machine ID: ae0fa1dbcc7d4f4d9bb6ad7fcd1e072f Hostname: typhon Storage: /var/lib/systemd/coredump/core.doveadm.REDACTED.e3d3c33d72164c98b58575bc3ad98ff5.3975605.1789980853000000.zst (present) Size on Disk: 518.3K Message: Process 3975605 (doveadm) of user REDACTED dumped core. Module libuuid.so.1 from deb util-linux-2.41.5-0+deb13u1.amd64 Module libgcc_s.so.1 from deb gcc-14-14.2.0-19.amd64 Module libstdc++.so.6 from deb gcc-14-14.2.0-19.amd64 Module libzstd.so.1 from deb libzstd-1.5.7+dfsg-1.amd64 Stack trace of thread 3975605: #0 0x00007ff829f4f3a7 n/a (libc.so.6 + 0x8f3a7) #1 0x00007ff829f4f3cd n/a (libc.so.6 + 0x8f3cd) #2 0x00007ff829fd07ed epoll_wait (libc.so.6 + 0x1107ed) #3 0x00007ff82a370a85 io_loop_handler_run_internal (libdovecot.so.0 + 0x170a85) #4 0x00007ff82a370be4 io_loop_handler_run (libdovecot.so.0 + 0x170be4) #5 0x00007ff82a370de8 io_loop_run (libdovecot.so.0 + 0x170de8) #6 0x00005f60bd513b3d cmd_dsync_run_remote (/usr/bin/doveadm + 0x3ab3d) #7 0x00005f60bd51484b doveadm_mail_next_user (/usr/bin/doveadm + 0x3b84b) #8 0x00005f60bd516657 doveadm_mail_cmd_exec (/usr/bin/doveadm + 0x3d657) #9 0x00005f60bd52af99 doveadm_cmdline_run (/usr/bin/doveadm + 0x51f99) #10 0x00005f60bd52b122 doveadm_cmdline_try_run (/usr/bin/doveadm + 0x52122) #11 0x00005f60bd50317b main (/usr/bin/doveadm + 0x2a17b) #12 0x00007ff829ee9ca8 n/a (libc.so.6 + 0x29ca8) #13 0x00007ff829ee9d65 __libc_start_main (libc.so.6 + 0x29d65) #14 0x00005f60bd5034b1 _start (/usr/bin/doveadm + 0x2a4b1) ELF object binary architecture: AMD x86-64 PID: 1992428 (doveadm-server) UID: 0 (root) GID: REDACTED (REDACTED) Signal: 11 (SEGV) Timestamp: Mon 2026-09-21 10:58:35 CEST (2h 18min ago) Command Line: $'dovecot/doveadm-server [REDACTED REDACTED slave_recv_mailbox]' Executable: /usr/lib/dovecot/doveadm-server Control Group: /system.slice/dovecot.service Unit: dovecot.service Slice: system.slice Boot ID: fb737a07888046ab9be0656dbe6cb21f Machine ID: 2d9ee85474064e06aa796c67b8f11dd9 Hostname: tyche Storage: /var/lib/systemd/coredump/core.doveadm-server.0.fb737a07888046ab9be0656dbe6cb21f.1992428.1789981115000000.zst (present) Size on Disk: 497.5K Message: Process 1992428 (doveadm-server) of user 0 dumped core. Module libuuid.so.1 from deb util-linux-2.41.5-0+deb13u1.amd64 Module libgcc_s.so.1 from deb gcc-14-14.2.0-19.amd64 Module libstdc++.so.6 from deb gcc-14-14.2.0-19.amd64 Module libzstd.so.1 from deb libzstd-1.5.7+dfsg-1.amd64 Stack trace of thread 1992428: #0 0x000079838fdab3a7 n/a (libc.so.6 + 0x8f3a7) #1 0x000079838fdab3cd n/a (libc.so.6 + 0x8f3cd) #2 0x000079838fe2c7ed epoll_wait (libc.so.6 + 0x1107ed) #3 0x0000798390170a85 io_loop_handler_run_internal (libdovecot.so.0 + 0x170a85) #4 0x0000798390170be4 io_loop_handler_run (libdovecot.so.0 + 0x170be4) #5 0x0000798390170de8 io_loop_run (libdovecot.so.0 + 0x170de8) #6 0x000059f13b7bdcce cmd_dsync_server_run (/usr/lib/dovecot/doveadm-server + 0x39cce) #7 0x000059f13b7bf74b doveadm_mail_next_user (/usr/lib/dovecot/doveadm-server + 0x3b74b) #8 0x000059f13b7c1557 doveadm_mail_cmd_exec (/usr/lib/dovecot/doveadm-server + 0x3d557) #9 0x000059f13b7d55b9 doveadm_cmdline_run (/usr/lib/dovecot/doveadm-server + 0x515b9) #10 0x000059f13b7d8232 doveadm_cmd_server_run_ver2 (/usr/lib/dovecot/doveadm-server + 0x54232) #11 0x000079839016ecdb io_loop_call_io (libdovecot.so.0 + 0x16ecdb) #12 0x0000798390170b1b io_loop_handler_run_internal (libdovecot.so.0 + 0x170b1b) #13 0x0000798390170be4 io_loop_handler_run (libdovecot.so.0 + 0x170be4) #14 0x0000798390170de8 io_loop_run (libdovecot.so.0 + 0x170de8) #15 0x00007983900b84be master_service_run (libdovecot.so.0 + 0xb84be) #16 0x000059f13b7ae307 main (/usr/lib/dovecot/doveadm-server + 0x2a307) #17 0x000079838fd45ca8 n/a (libc.so.6 + 0x29ca8) #18 0x000079838fd45d65 __libc_start_main (libc.so.6 + 0x29d65) #19 0x000059f13b7ae3b1 _start (/usr/lib/dovecot/doveadm-server + 0x2a3b1) ELF object binary architecture: AMD x86-64 The doveconf -n output is attached. As a temp. workaround, I have disabled multiplex stream for the doveadm protocol by: --- dovecot-2.4.5.orig/src/lib-doveadm/doveadm-protocol.h +++ dovecot-2.4.5/src/lib-doveadm/doveadm-protocol.h @@ -16,7 +16,7 @@ #define DOVEADM_PROTOCOL_MIN_VERSION_EXTRA_FIELDS 3 /* Use the (non-deprecated) STREAM multiplex format instead of PACKET for the server -> client output. */ -#define DOVEADM_PROTOCOL_MIN_VERSION_MULTIPLEX_STREAM 4 +#define DOVEADM_PROTOCOL_MIN_VERSION_MULTIPLEX_STREAM 5 #define DOVEADM_EX_NOTFOUND EX_NOHOST #define DOVEADM_EX_NOTPOSSIBLE EX_DATAERR This allows us to continue the service for our users but obviously is not a solution. Unfortunately I cannot provide the data of the affected mailboxes to allow reproducing the bug. But I have saved them on a development system and can reproduce it locally. I'm willing to test suggested patches and provide more data (unless restricted by privacy issues). Can anyone help me debugging this issue? 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

1 0

dict: ldap deref
by Tomas Habarta 21 Sep '26

21 Sep '26

Hello, just been testing sieve extlists against ldap dict in 2.4.5 -- works ok but need to narrow a search base but this would require setting deref other than default none for the ldap client. Seems that something like ldap_deref = always in dict_map {} section does not work (is not even documented, but config is parsed ok on the other hand) and value of the global ldap_deref is not picked up either. Question is whether the deref parameter is supposed to work and if yes, where to set it up correctly... Many thanks, Tomas

1 0

Re: 2.4.5 causes an infinite loop in maildir_is_internal_name
by Johannes Nohl 21 Sep '26

21 Sep '26

Dear Naofumi Honda, unfortunately I don't have your email. I found - rather by surprise - that mail_driver is case-sensitiv; Maildir is like Auto like auto. The work around is stating "mail_driver = maildir" not "= Maildir". This is a reply to your config as described here: https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/message/TV5O… Please try. -- Johannes Nohl

2 1

Quota messages warning
by Alberto 21 Sep '26

21 Sep '26

I have dovecot 2.4.5 in a Docker container and warning quota of message count isn't working. My quota config: quota "User quota" { driver = count quota_warning warn-espacio-95 { quota_storage_percentage = 95 execute quota-warning { args = espacio-95 %{user} } } quota_warning warn-mensajes-95 { quota_message_percentage = 95 execute quota-warning { args = cantidad-95 %{user} } } quota_warning warn-espacio-85 { quota_storage_percentage = 85 execute quota-warning { args = espacio-85 %{user} } } quota_warning warn-mensajes-85 { quota_message_percentage = 85 execute quota-warning { args = cantidad-85 %{user} } } quota_warning warn-espacio-75 { quota_storage_percentage = 75 execute quota-warning { args = espacio-75 %{user} } } quota_warning warn-mensajes-75 { quota_message_percentage = 75 execute quota-warning { args = cantidad-75 %{user} } } } In storage option works ok, but in case of messages no event success. Log not show anything and external script is not call, of course. Any idea? Best Regards, Alberto

4 10

Variable expansion syntax: Filter "default" throws error (unwanted)
by Johannes Nohl 20 Sep '26

20 Sep '26

I am using dovecot 2.4.2 (almost) with new config language and I have a working configuration. However, the check for disabled users throws permanently errors in the log file, whenever a user is missing the ldap attribute for disabled. This is - in my view - due to a misfunction of Filter "default". passdb ldap { driver = ldap ldap_bind = yes ldap_filter = (&(|(objectClass=posixAccount)(objectClass=mailAccount))(uid=%{user})) fields { user = %{ldap:uid} nologin = %{ldap:shadowInactive | default(null)} reason = The account for this email address is disabled. } } This results in the following log line: 2026-03-31T00:46:31.102690+02:00 mailserver dovecot: auth(test,ipv4,sasl:plain)<YE81n0VOVuofEeSD>: Error: ldap: auth_passdb_post settings: Failed to parse configuration: Failed to expand passdb_fields/nologin setting variables: ldap: No such attribute 'shadowinactive' The right behaviour would be no logging on login success. Because the Filter "default" is intended to suppress any errors ("When value is missing or empty, you can use the default filter to provide value. Missing variables will cause errors and must be negated with default. This does not apply to all providers, some providers return empty when value is missing."). https://doc.dovecot.org/2.4.2/core/settings/variables.html#variable-expansi… As you may have seen I had to borrow null-value from sql db config also to make nologin ignoring a non present attribute. This is undocumented obviously. Instead, a non-working tip is provided ("Changed: 2.4.0 Extra fields can now also be set to empty string, "). However, the following does not work: "nologin = {ldap:shadowinactive | default("")}". https://doc.dovecot.org/2.4.2/core/settings/variables.html Also, the documentation is missing/hiding the part which explains that "default()" can be used to avoid error logs. PR regarding the documentation source is sent already. See "Fails if the attribute is not present, unless the ` <missing part>" https://doc.dovecot.org/2.4.0/core/config/auth/databases/ldap.html#ldap-spe… Is there another way to verify if account is disabled? -- Johannes Nohl postmaster i-t-cloud -- Johannes Nohl postmaster(a)i-t-cloud.de I am using dovecot 2.4.2 (almost) with new config language and I have a working configuration. However, the check for disabled users throws permanently errors in the log file, whenever a user is missing the ldap attribute for disabled. This is - in my view - due to a misfunction of Filter "default". passdb ldap { driver = ldap ldap_bind = yes ldap_filter = (&(|(objectClass=posixAccount)(objectClass=mailAccount))(uid=%{user})) fields { user = %{ldap:uid} nologin = %{ldap:shadowInactive | default(null)} reason = The account for this email address is disabled. } } This results in the following log line: *2026-03-31T00:46:31.102690+02:00 mailserver dovecot: auth(test,ipv4,sasl:plain)<YE81n0VOVuofEeSD>: Error: ldap: auth_passdb_post settings: Failed to parse configuration: Failed to expand passdb_fields/nologin setting variables: ldap: No such attribute 'shadowinactive' The right behaviour would be no logging on login success. Because the Filter "default" is intended to suppress any errors ("When value is missing or empty, you can use the default filter to provide value. Missing variables will cause errors and must be negated with default. This does not apply to all providers, some providers return empty when value is missing."). https://doc.dovecot.org/2.4.2/core/settings/variables.html#variable-expansi… As you may have seen I had to borrow null-value from sql db config also to make nologin ignoring a non present attribute. This is undocumented obviously. Instead, a non-working tip is provided ("Changed: 2.4.0 Extra fields can now also be set to empty string, "). However, the following does not work: "nologin = {ldap:shadowinactive | default("")}". https://doc.dovecot.org/2.4.2/core/settings/variables.html Also, the documentation is missing/hiding the part which explains that "default()" can be used to avoid error logs. PR regarding the documentation source is sent already. See "Fails if the attribute is not present, unless the ` <missing part>" https://doc.dovecot.org/2.4.0/core/config/auth/databases/ldap.html#ldap-spe… Is there another way to verify if account is disabled? -- Johannes Nohl postmaster i-t-cloud -- Johannes Nohl postmaster(a)i-t-cloud.de

2 2

Push Notification on 2.4.5
by horst.simon2＠icloud.com 19 Sep '26

19 Sep '26

Hi, Is there any simple explanation on how to enable and verify push notifications on dovecot 2.4.5. I am using eM Client on IOS and it uses push notification, but it does not receives any notification about new emails. I assume by default push notifications is not enabled. Any information appreciated. Regards, Horst

7 11

Dovecot and Pigeonhole v2.4.5 released
by Aki Tuomi 18 Sep '26

18 Sep '26

Hi! We are happy to publish version 2.4.5 of Dovecot and Pigeonhole. These contain CVEs, discovered by external researches. The majority of these have been discovered with help of automated code analysis tools like claude code security, which is why some of these are rather old, missed bugs. Distributions have changed - Jammy (Ubuntu 22.04) is no longer provided in repo.dovecot.org - Resolute Raccoon (Ubuntu 26.04) has been added to repo.dovecot.org No new dependencies have been added. Note that there are experimental features in 2.4, one is enabled with `--enable-experimental-mail-utf8`, and another with `--enable-experimental-imap4rev2`, and you also need to set mail_utf8_extensions=yes and imap4rev2_enabled=yes to enable them in config. https://dovecot.org/releases/2.4/dovecot-2.4.5.tar.gz https://dovecot.org/releases/2.4/dovecot-2.4.5.tar.gz.sig https://pigeonhole.dovecot.org/releases/2.4/dovecot-pigeonhole-2.4.5.tar.gz https://pigeonhole.dovecot.org/releases/2.4/dovecot-pigeonhole-2.4.5.tar.gz… Binary packages in https://repo.dovecot.org/ Docker images in https://hub.docker.com/r/dovecot/dovecot --- * CVE-2026-27852: Messages with a huge number of From/To/Cc/etc email addresses could result in excessive memory usage. * CVE-2026-33263: Submission: Login service crashes with panic once mail_max_userip_connections limit is reached. * CVE-2026-33604: The SMTP outbound dot-stuffing mechanism does not properly escape dots following a bare \r in message bodies, potentially allowing spoofed emails via malicious end-of-DATA injection. * CVE-2026-33606: Mail content stored by a user can be crafted so that it is interpreted as dsync protocol commands when an administrator later runs dsync with the stream protocol, for example during a migration. * CVE-2026-33607: IMAP LIST command could be used to cause excessive CPU usage. * CVE-2026-40014: IMAP THREAD command could have used excessive amount of CPU processing a single email with a massive number of Message-IDs in References header. * CVE-2026-40015: Invalid IMAP command sent to imap-hibernate process might crash it. * CVE-2026-40017: IMAP THREAD command could have used excessive amount of CPU processing emails with a large number of specially crafted Message-IDs in References header. The fix requires a new dovecot.index.thread file format, which is enabled only after setting dovecot_storage_version or newer. This rebuilds the index, so it will cause some extra CPU usage and extra metacache disk IO usage. It shouldn't cause (much) extra object storage IO, because all the fields should be coming from dovecot.index.cache. * CVE-2026-40203: When IMAP COMPRESS=DEFLATE was enabled, an attacker could send mails into a victim's mailbox and observe network traffic to determine whether a secret message matched a known string by comparing compressed response sizes (a CRIME-style attack). The fix resets the compression dictionary after each IMAP command, preventing information from leaking between commands. * CVE-2026-40205: If multiple OAUTH scopes were required, then this could have been only partially enforced with certain configurations. * CVE-2026-4200: XCLIENT FORWARD allows to forward key only passdb fields without the "forward_" prefix which allows connections from trusted networks to set nopasswd field which allows to skip the authentication. * CVE-2026-42391: Pre-login IMAP ID command could have used excessive amount of memory, causing the process to become killed and disconnecting all the other IMAP connections being proxied by the process. Or alternatively it could have caused excessive CPU usage, slowing down all the other IMAP connections being proxied by the process. * CVE-2026-42392: If URLAUTH is enabled, sending an invalid IMAP URLFETCH can result in an untagged NO response containing uninitialized memory, potentially leaking sensitive data. * CVE-2026-42393: Doveadm password length or API key length could still be determined via timing based attacks. * CVE-2026-42395: XCLIENT FORWARD command from login_trusted_networks could have been used to cause login processes to crash. * CVE-2026-52681: Sieve resource usage (sieve_max_cpu_time) was tracked in the active Sieve binary. Switching to a different active binary could have been used to reset (bypass) the resource usage. * CVE-2026-52687: Using IMAP COMPRESS ZSTD command can cause excessive memory usage in imap-login process, possibly making it reach vsz_limit and kill all the connections being served by the process. Fixed by disabling COMPRESS command with all other compression algorithms than the standard DEFLATE. * CVE-2026-73208: In oauth2, scope/aud checking was done with JWT tokens. Now it requires all scopes. * CVE-2026-73209: Sending IMAP COMPRESS package containing zero-length frames crashes imap or imap-login process. * auth: SIGHUP no longer flushes the passdb cache and SIGUSR2 no longer logs cache statistics. Use "doveadm auth cache flush" and the new "doveadm auth cache status" instead. * auth: The OTP authentication mechanism, the {OTP} password scheme and the passdb set-credentials support have been removed. They were unmaintained and unused. This also drops the passdb_sql_update_query setting. * config: doveconf no longer prints a flat global setting when a top-level named filter overrides the same setting. * doveadm: The doveadm protocol has been bumped to v1.4. The server uses the newer multiplex stream format with clients supporting it. Older clients keep working unchanged. * imap: Change imap_compress_on_proxy default to yes. * lib-dict-extra: Increase dict client request timeout from 30s to 65s, so it stays above the SQL/Cassandra query timeout. * lib-http: HTTP requests are now parsed strictly: obsolete line folding (obs-fold) and a bare LF line terminator are rejected. Both are request desynchronization/smuggling risks. HTTP responses are still parsed leniently. * lib-storage: A '~' in a mailbox name is now escaped only when it is at the beginning of the mailbox name, not at the beginning of every hierarchy part. Directories written by older versions are migrated automatically while listing mailboxes. * lib-var-expand: Add %{time:unix} provider and the epoch, from_epoch, date, iso8601 and escape filters. Deprecates the old time providers. * lib-var-expand: The safe filter must now be the last filter in the chain. * master: Increase the timeout after config reload before killing still running old processes from 6s to 35s, so that lib-master can stop them gracefully first. + config: Support heredoc syntax for multi-line setting values: key = <<EOD ... EOD. doveconf now outputs inline SET_FILE contents (e.g. ssl_ca) using heredoc instead of the "inline:" prefix. The "inline:" form is still accepted. + configure: Build imap-hibernate also when only kqueue notify is available. + doveadm: Add "doveadm auth cache status" command, with --reset for clearing the counters. + doveadm: dump - List all supported dump types, and print the key type also for KEM and unsupported keys. + fts-flatcurve: Add support for phrase searching. This fixes false positives where the searched words existed, but not as a phrase. + fts-flatcurve: Delete the FTS index directory also when a Maildir mailbox is deleted. + imap: Add [THROTTLED] response code to tagged replies when a plugin has throttled the command. + last-login: Add last_login_dict_fields setting for updating multiple dictionary fields at login. + lib-dcrypt: Add ML-KEM-512/768/1024 support with OpenSSL 3. + lib-dcrypt: Support AEAD with Dovecot key encryption. + lib-settings: Expand %{variables} also in strlist and boollist keys. + lib-sql: sqlite - Add sqlite_busy_timeout setting, default 1s. + login-common: Log the destination also when a proxy connection fails. + quota: Update quota-clone also when "doveadm quota recalc" is run. - Fix building on systems with a signed 32-bit time_t. - Fix building with Lua when LUA_LIBS contains linker flags such as -L. - anvil: Fix busy loop eating CPU after an admin socket connection was disconnected. - auth: Fix authentication failing after a password change when the passdb cache entry was verified by an auth worker. - auth: Fix the credentials scheme of one passdb leaking into the next one during a multi-passdb lookup. - auth: oauth2 - Fix losing userdb_* fields during OAUTHBEARER authentication. - auth: passwd-file - Fix %{passdb:...} and %{userdb:...} expansion returning garbage or crashing. - config: Fix crash in "doveconf -f" for a filter that includes a @group. - config: Fix crash when including a default @group into a filter. - config: Fix hiding secrets in doveconf output. - config: Fix startup failures with some settings containing %{variables}. - configure: Fix BUILD_IMAP_HIBERNATE detection. - doc: solr-schema-9.xml - Add the mandatory tokenizer class attribute. - doveadm: compress-connect - Fix writing server input to a non-blocking stdout. - doveadm: fs delete - Fix crash with concurrent async deletes. - doveconf: Fix bogus "Multiple settings matched" error when stdout is redirected to a file that already has content. - dsync: Fix truncating a mailbox attribute value when it is compared to the local one, e.g. truncating a Sieve script. - dsync: backup - Mailbox attributes changed or created only in the destination are now reverted or deleted. - fts-flatcurve: Ignore index directory entries that vanish during iteration. - fts: Don't run FTS optimize on forced resync. - fts: build-mail - Fix accessing Content-Type header buffer out of bounds. - imap-login, pop3-login: Tolerate SASL continuations "+" without a trailing space when proxying authentication. - imap: Don't report FETCH output stream errors as "BUG: Unknown internal error". - imap: Fix hibernation always failing on FreeBSD. - imap: Fix panic on GETMETADATA with an invalid UTF-8 mailbox pattern. - imapc: Don't send SEEEN/UNSEEN to the remote server when private indexes are used. - imapc: Fix SEARCH results pointing at wrong messages after an untagged EXPUNGE. - imapc: Fix SORT returning an empty result when search criteria were used. - imapc: Fix crash when copying a mail that was already expunged in the source mailbox. - imapc: Fix stale SEARCH/SORT results after a STORE in the same session. - imapc: Honor imapc_features=no-search also for SORT. - imapc: Properly handle search criteria that can be sent to remote server. - lib-dcrypt: Don't panic on key algorithms the backend doesn't support. - lib-dcrypt: Fix x9.62 ECDSA signatures randomly failing verification. - lib-dict-backend: cdb - Fix use-after-free of the returned key. - lib-dns-client: Fix handling of a disconnect initiated by the dns-client service. - lib-fs: Fix panic in fs_write_stream_abort(), e.g. when the disk is full during FTS indexing. - lib-index: Fix "File is already open" error when appending to the transaction log while another process is rotating it. This showed up as "NO [SERVERBUG] Internal error occurred." without any logging. - lib-ldap: Fall back to system default CA paths, needed for OpenLDAP built against GnuTLS. - lib-mail: istream-binary-converter - Fix heap use-after-free with a bodyless MIME part. - lib-mail: message-parser - Fix out of bounds read with an empty preamble, fix skipping the epilogue boundary line, and degrade to a re-parse instead of panicking with an inconsistent cached MIME tree. - lib-master: Fix kick reason when the KICK-USER-SIGNAL command arrives late, which logged "Killed with signal 15" instead of "User kicked". - lib-oauth2: jwt - Fix use-after-realloc, guard against an empty body segment and percent-encode bare "." and ".." identifiers. - lib-program-client: Fix panic upon irregular termination. - lib-settings: Fix sorting of the settings history, which caused changed defaults and renames to be ignored once a plugin registered its own history, if dovecot_config_version has been set to greater than 2.4.0. - lib-smtp: Fix assert with an empty broken localpart. - lib-smtp: xclient - Reject an invalid HELO parameter with 501. - lib-sql: pgsql - Fix binary field values for rows after the first. This mainly affected dict-sql maps with hexblob fields. - lib-ssl-iostream: Fix crash at process exit with OpenSSL 4.0. - lib-storage: Don't log an error when the client resets the connection while saving a mail. - lib-storage: Fix crash when reverting a failed mailbox deletion. - lib-storage: Fix decoded size calculation for base64 attachments, which could delete the cache record of a mail with a detached attachment. - lib-storage: Fix handling escaped mailbox names in the mailbox list index. - lib-storage: Fix rewriting non-NFC subscriptions with mUTF-7 storage names, which caused repeated rename errors. - lib-storage: Fix searching flags when the view is not up to date. This broke e.g. a pipelined UID STORE +FLAGS \Deleted followed by UID EXPUNGE. - lib-storage: Fix the mailbox vsize header not being repaired when it is corrupted, causing wrong mailbox sizes to be reported. - lib-storage: thread - Fix panic when running IMAP THREAD in multiple connections in parallel. - lib-var-expand: Reject an empty separator in the index filter, which caused an infinite loop. - lib: Fix crash and out of bounds reads when decoding IDN addresses. Reachable only with the experimental mail UTF-8 support enabled. - lib: ioloop - Fix panic and delayed timeouts when time moves forwards. - lib: ostream-multiplex - Fix stalls, busy loops and a panic when streaming data through a multiplexed connection, e.g. IMAP FETCH through a login proxy or TLS connections. - login-common: Fix connection hanging if an ostream write failed. This happened at least with HAProxy health check connections. - login-common: Fix real_remote_ip being looked up incorrectly. - login-common: Reject proxy credentials with ASCII control characters. - login-proxy: Fix "doveadm kick" for proxied connections in high-security mode, and log "Kicked by admin" as the reason. - maildir: Fix random SEARCH failures when another session concurrently expunges mails. - quota: Fix maildir quota dropping to zero after IMAP MOVE or REPLACE. - submission-login: proxy - Fix crash and unbounded memory usage with a multi-line or malformed AUTH reply from the backend. --- * CVE-2026-33605: managesieve-login: Pre-auth crash. An unauthenticated attacker can crash the ManageSieve login process by sending a small malformed command before authenticating. * CVE-2026-40019: v2.4.3 regression: managesieve-login pre-auth infinite loop. An unauthenticated attacker can send a truncated quoted argument to the ManageSieve login process, which makes it spin in an infinite loop consuming CPU. * CVE-2026-42007: sieve-editheader: An attacker that has valid credentials can use a Sieve script with the editheader extension to trigger a use-after-free in the mail editing code, and to write memory contents beyond the intended buffer in the delivered mail. * lib-sieve: sieve_max_cpu_time now defaults to 30s globally, so the limit also applies to MDA delivery. Previously the global default was unlimited and only imap_sieve used 30s. The old defaults are kept for older dovecot_config_version values. * lib-sieve: enotify - The number of notify actions performed during a single script execution is now limited to 10 by default. See the new sieve_notify_max_notifications setting. * lib-sieve: enotify - A single "mailto:" notify action is now limited to 8 recipients and 16 additional headers by default. See the new sieve_notify_mailto_max_recipients and sieve_notify_mailto_max_headers settings. * imap-filter-sieve: FILTER SIEVE SCRIPT literals larger than sieve_max_script_size are now rejected before the script is read. - lib-sieve: Fix stack overflow occurring when a script requires the same extension repeatedly. - lib-sieve: encoded-character - Fix integer overflow parsing ${unicode:...} values with 9 or more hex digits. - lib-sieve: variables - Fix integer overflow parsing numeric variable index. - lib-sieve: regex - Fix panic occurring when more than 8 group values are matched. - lib-sieve: ldap - Fix LDAP settings missing from the LDAP storage plugin. - managesieve-login: Fix capability reporting when Sieve settings use %variables.

6 12

2.4.5 Segmentation fault when sieve dir exists, but there is no personal script
by inaugurator＠ya.ru 17 Sep '26

17 Sep '26

Hi guys, with config ``` sieve_script personal { driver = file path = ~/sieve active_path = ~/.dovecot.sieve } ``` there can be ~/sieve dir, but no script file. The situation leads to SIGSEGV, Segmentation fault. ``` (gdb) bt #0 0x00007fd1604dfc03 in sieve_script_binary_read_metadata (script=0x0, sblock=sblock@entry=0x603d08ce4ef0, offset=offset@entry=0x7fff8dab6150) at sieve-script.c:530 #1 0x00007fd16051b63c in ext_include_binary_open (ext=0x603d08cc7eb0, sbin=0x603d08ce4758, context=0x603d08ce5018) at ext-include-binary.c:409 #2 0x00007fd1604ea7af in sieve_binary_open (svinst=<optimized out>, path=<optimized out>, script=script@entry=0x603d08ce23f8, sbin_r=<optimized out>, error_code_r=<optimized out>, error_code_r@entry=0x7fff8dab6344) at sieve-binary-file.c:940 #3 0x00007fd1604e0765 in sieve_script_binary_load_default (script=0x603d08ce23f8, path=<optimized out>, sbin_r=<optimized out>) at sieve-script.c:691 #4 0x00007fd1604e0803 in sieve_script_binary_load (script=script@entry=0x603d08ce23f8, sbin_r=sbin_r@entry=0x7fff8dab63b8, error_code_r=<optimized out>, error_code_r@entry=0x7fff8dab64dc) at sieve-script.c:716 #5 0x00007fd16050b7ed in sieve_open_script_real (error_code_r=0x7fff8dab64dc, sbin_r=0x7fff8dab6420, flags=SIEVE_COMPILE_FLAG_NO_ENVELOPE, ehandler=0x603d08cc9e98, script=0x603d08ce23f8) at sieve.c:451 #6 sieve_open_script (script=script@entry=0x603d08ce23f8, ehandler=ehandler@entry=0x603d08cc9e98, flags=flags@entry=SIEVE_COMPILE_FLAG_NO_ENVELOPE, sbin_r=sbin_r@entry=0x7fff8dab6420, error_code_r=<optimized out>, error_code_r@entry=0x7fff8dab64dc) at sieve.c:531 #7 0x00007fd160c2b2a6 in imap_sieve_run_open_script (isrun=isrun@entry=0x603d08ce1de8, rscript=rscript@entry=0x603d08ce1c60, cpflags=cpflags@entry=SIEVE_COMPILE_FLAG_NO_ENVELOPE, error_code_r=error_code_r@entry=0x7fff8dab64dc, recompile=false) at imap-sieve.c:641 #8 0x00007fd160c2c54d in imap_sieve_run_scripts (fatal_r=0x7fff8dab66cb, scriptenv=0x7fff8dab6580, msgdata=0x7fff8dab6540, isrun=0x603d08ce1de8) at imap-sieve.c:847 #9 imap_sieve_run_mail (isrun=0x603d08ce1de8, mail=<optimized out>, changed_flags=<optimized out>, fatal_r=fatal_r@entry=0x7fff8dab66cb) at imap-sieve.c:1018 #10 0x00007fd160c2e810 in imap_sieve_mailbox_transaction_run (changes=<optimized out>, dest_box=<optimized out>, ismt=0x603d08ce1fe8) at imap-sieve-storage.c:691 #11 imap_sieve_mailbox_transaction_commit (t=<optimized out>, changes_r=<optimized out>) at imap-sieve-storage.c:774 #12 0x00007fd16102f013 in quota_mailbox_transaction_commit () from /usr/lib/dovecot/modules/lib10_quota_plugin.so #13 0x00007fd16104d14a in acl_transaction_commit () from /usr/lib/dovecot/modules/lib01_acl_plugin.so #14 0x00007fd1640648d7 in mailbox_transaction_commit_get_changes () from /usr/lib/dovecot/libdovecot-storage.so.0 #15 0x0000603d088f0660 in cmd_append_finish_parsing () #16 0x0000603d088f0d56 in cmd_append_parse_new_msg () #17 0x0000603d088f1190 in cmd_append_continue_message () #18 0x0000603d0890a569 in command_exec () #19 0x0000603d088eebd7 in client_input_append () #20 0x00007fd163be7db7 in io_loop_call_io () from /usr/lib/dovecot/libdovecot.so.0 #21 0x00007fd163beb469 in io_loop_handler_run_internal () from /usr/lib/dovecot/libdovecot.so.0 #22 0x00007fd163be8066 in io_loop_handler_run () from /usr/lib/dovecot/libdovecot.so.0 #23 0x00007fd163be7f19 in io_loop_run () from /usr/lib/dovecot/libdovecot.so.0 #24 0x00007fd163abc8be in master_service_run () from /usr/lib/dovecot/libdovecot.so.0 #25 0x0000603d08921c54 in main () ``` Thank you for any help!

1 0

open(/proc/self/io) failed: Permission denied
by horst.simon2＠icloud.com 17 Sep '26

17 Sep '26

My sieve scripts don't get executed and when I enable debug logging I get following errors in the log: Sep 17 20:43:04 imap(username)<13827><3lXZcqtbpcHAqHUF>: Debug: Loading modules from directory: /opt/lib/dovecot Sep 17 20:43:04 imap(username)<13827><3lXZcqtbpcHAqHUF>: Debug: Module loaded: /opt/lib/dovecot/lib15_notify_plugin.so Sep 17 20:43:04 imap(username)<13827><3lXZcqtbpcHAqHUF>: Debug: Module loaded: /opt/lib/dovecot/lib20_push_notification_plugin.so Sep 17 20:43:04 imap(username)<13827><3lXZcqtbpcHAqHUF>: Debug: Module loaded: /opt/lib/dovecot/lib95_imap_sieve_plugin.so Sep 17 20:43:04 imap(username)<13827><3lXZcqtbpcHAqHUF>: Debug: Effective uid=5000, gid=5000, home=/share/CACHEDEV1_DATA/mail/<domainnamee>/<user> Sep 17 20:43:04 imap(horst(a)hbsimon.net)<13827><3lXZcqtbpcHAqHUF>: Debug: open(/proc/self/io) failed: Permission denied (euid=5000(vmail) egid=5000(vmail) missing +r perm: /proc/self/io) Dovecot version is 2.4.5 Is there anything I can change in the permissions to get this working?

4 9

problems restarting dovecot from cron: stderr not dup2()ed
by Thomas Klausner 15 Sep '26

15 Sep '26

Hi! I'm using dovecot-2.3.21.1 from pkgsrc on NetBSD 11.99.8/x86_64. I use certbot to handle dovecot's TLS certificate, and since I haven't implemented a nicer method yet, I restart dovecot weekly from cron to make sure it has the newest certificate. The symptom I see is that the restart doesn't finish until the next restart a week later - only then the previous restart's cron job "finishes" and I get an email. In a discussion on the NetBSD mailing list[1], RVP diagnosed it as follows: --- begin quote --- cron is still waiting for output from dovecot: 1. dovecot doesn't dup2() its STDERR_FILENO[2]--prolly to spew out error msgs. 2. when cron runs a crontab command, it dup2(STDOUT, STDERR)s the cmds stdout and stderr. 3. then it reads from this combined output and write()s this to sendmail's stdin. 4. all this works if either a) the program dies (ie. is not a daemon) so that cron can close sendmail's stdin.; or b) the daemon itself closes its stderr so an EOF can be generated when stdout is exhausted. 5. neither a) nor b) are satisfied in this case, so cron is still waiting for output which'll never arrive. 6. a week later, `service dovecot restart' kills the still running dovecot so cron can now "complete" the job and generate the email. --- end quote --- Can you please change dovecot to also dup(2) stderr to fix this? Thank you, Thomas [1] https://mail-index.netbsd.org/current-users/2026/09/13/msg047887.html [2]: https://github.com/dovecot/core/blob/main/src/master/main.c#L931

1 0

Issues after upgrading to the 2.4.* tree
by Kevin N Carpenter 15 Sep '26

15 Sep '26

Hi all. I've been running a Gentoo based mail server for decades - yeah, really! I usually upgrade it about once a year, which I just did. Been using the older dovecot versions until 2.4.5 got pulled in. Under Dovecot 2.3, I simply had the statement: *mail_location = maildir:~/.maildir* In dovecot/conf.d/10-mail and everything has been working. Ungraded my system and along comes 2.4 which changes configuration up. Using their converter, they suggest: *mail_driver = maildir mail_path = ~/.maildir * returns the error: /mail dovecot: imap(ccgllc)<5839><6sozAX5bskysEAQB>: Error: Namespace inbox: mail_storage settings: Failed to parse configuration: Invalid setting mail_path=~/.maildir: mail_path setting used home directory (~/) but there is no mail_home and userdb didn't return it / Setting *mail_home = /home/%{user}* gets closer, but then dovecot has permission errors reading the .maildir directory: /mail dovecot: imap(kevinc)<5541><6HubuX1bV42sEAQB>: Error: maildir: stat(/home/kevinc/.maildir/tmp) failed: Permission denied (euid=5000(<unknown>) egid=5000(<unknown>) missing +x perm: /home/kevinc/.maildir, dir owned by 1000:1000 mode=0700)/ Been going in circles for hours over this... all I want is a nice simply mairdir based imap server. btw - have SSL working just fine now. just added: *passdb pam { driver = pam pam_service_name = * } userdb passwd { driver = passwd } * since passdb and userdb were specified in my old configuration. Now getting: /auth-worker(kevinc,172.16.4.1)<5973></2FNPn5b1YqsEAQB>: request [1]: Error: pam: pam_authenticate() failed: Authentication failure (/etc/pam.d/* missing?/ /etc/pam.d/ exist, including the new dovecot statement. In any case, that last step feels like I am going backwards. Help please. Hi all. I've been running a Gentoo based mail server for decades - yeah, really! I usually upgrade it about once a year, which I just did. Been using the older dovecot versions until 2.4.5 got pulled in. Under Dovecot 2.3, I simply had the statement: mail_location = maildir:~/.maildir In dovecot/conf.d/10-mail and everything has been working. Ungraded my system and along comes 2.4 which changes configuration up. Using their converter, they suggest: mail_driver = maildir mail_path = ~/.maildir returns the error: mail dovecot: imap(ccgllc)<5839><6sozAX5bskysEAQB>: Error: Namespace inbox: mail_storage settings: Failed to parse configuration: Invalid setting mail_path=~/.maildir: mail_path setting used home directory (~/) but there is no mail_home and userdb didn't return it Setting mail_home = /home/%{user} gets closer, but then dovecot has permission errors reading the .maildir directory: mail dovecot: imap(kevinc)<5541><6HubuX1bV42sEAQB>: Error: maildir: stat(/home/kevinc/.maildir/tmp) failed: Permission denied (euid=5000(<unknown>) egid=5000(<unknown>) missing +x perm: /home/kevinc/.maildir, dir owned by 1000:1000 mode=0700) Been going in circles for hours over this... all I want is a nice simply mairdir based imap server. btw - have SSL working just fine now. just added: passdb pam { driver = pam pam_service_name = * } userdb passwd { driver = passwd } since passdb and userdb were specified in my old configuration. Now getting: auth-worker(kevinc,172.16.4.1)<5973></2FNPn5b1YqsEAQB>: request [1]: Error: pam: pam_authenticate() failed: Authentication failure (/etc/pam.d/* missing? /etc/pam.d/ exist, including the new dovecot statement. In any case, that last step feels like I am going backwards. Help please.

1 0

2.4.5 causes an infinite loop in maildir_is_internal_name
by Naofumi Honda 12 Sep '26

12 Sep '26

Dear developers, afte upgrading to the 2.4.5, all the imap-login processes always fall into infinite loops in maildir_is_inernal_name(). This is becuase, when mailbox_list_layout = fs, mlist->module_ctx.super.is_internal_name becomes the jus maidir_is_internal_name() itself, which causes infinite self-recursion loops (by a tail recursion optimization) as was the attached debug info shows.

2 3

2.4.5 build failures on s390x and loong64 architectures
by Noah Meyerhans 10 Sep '26

10 Sep '26

While preparing the Debian packages of Dovecot 2.4.5, I've encountered the following architecture-specific build failures: On s390x, the test suite fails in test-lib with: test-hash-method.c:483: Assert(#28) failed: memcmp(result, test_vectors[i].output, test_vectors[i].olen) == 0 test-hash-method.c:483: Assert(#29) failed: memcmp(result, test_vectors[i].output, test_vectors[i].olen) == 0 hash method xxh64 (test vectors) ..................................... : FAILED Full build log is visible at https://buildd.debian.org/status/fetch.php?pkg=dovecot&arch=s390x&ver=1%3A2… I haven't determined yet whether the problem is with the xxh64 hash method itself or with the test suite, but the failure is reliably reproducible. On loong64, the test suite fails in test-lib with: ostream multiplex stream (backpressure): sub-process ended properly .. : FAILED Warning: test: Sub-process forcibly terminated with signal 9 ostream multiplex stream (backpressure) .............................. : FAILED Complete log is at https://buildd.debian.org/status/fetch.php?pkg=dovecot&arch=loong64&ver=1%3… I'm working on debugging these, and will share whatever I find, but maybe somebody here will beat me to the solution. noah

2 3

Corrupt index.cache file causes looping and out of memory errors
by Evan Booyens 09 Sep '26

09 Sep '26

Dovecot -n and systems report are attached Log file extries: Sep 9 14:29:32 www23.jnb2.host-h.net dovecot: imap(*****@*******): Error: Mailbox INBOX.Client Correspondence: read() failed with file /usr/www/dovecot_indexes/********.co.za/orders/.Client Correspondence/dovecot.index.cache: Cannot allocate memory Sep 9 14:29:32 www23.jnb2.host-h.net dovecot: imap(*****(a)*******.co.za): Error: mremap_anon(/usr/www/dovecot_indexes/********.co.za/orders/.Client Correspondence/dovecot.index.cache, 967524352) failed: Cannot allocate memory Sep 9 14:29:32 www23.jnb2.host-h.net dovecot: imap(*****@*******): Error: mremap_anon(/usr/www/dovecot_indexes/********.co.za/orders/.Client Correspondence/dovecot.index.cache, 967524352) failed: Cannot allocate memory Sep 9 14:29:32 www23.jnb2.host-h.net dovecot: imap(*****@*******): Error: Mailbox INBOX.Client Correspondence: read() failed with file /usr/www/dovecot_indexes/********.co.za/orders/.Client Correspondence/dovecot.index.cache: Cannot allocate memory Sep 9 14:29:32 www23.jnb2.host-h.net dovecot: imap(*****@*******): Error: mremap_anon(/usr/www/dovecot_indexes/********.co.za/orders/.Client Correspondence/dovecot.index.cache, 967524352) failed: Cannot allocate memory Sep 9 14:29:32 www23.jnb2.host-h.net dovecot: imap(*****(a)*******.co.za): Error: mremap_anon(/usr/www/dovecot_indexes/********.co.za/orders/.Client Correspondence/dovecot.index.cache, 967524352) failed: Cannot allocate memory Sep 9 14:29:32 www23.jnb2.host-h.net dovecot: imap(*****(a)*******.co.za): Error: Mailbox INBOX.Client Correspondence: read() failed with file /usr/www/dovecot_indexes/********.co.za/orders/.Client Correspondence/dovecot.index.cache: Cannot allocate memory Evan Booyens Linux Platform Engineer xneelo (Pty) Ltd SA Contact Centre: 0861 0861 08 International: +27 21 970 2000 Disclaimer: xneelo.co.za/email-disclaimer Formerly known as Hetzner SA Dovecot -n and systems report are attached Log file extries: Sep 9 14:29:32 [1]www23.jnb2.host-h.net dovecot: imap(*****@*******): Error: Mailbox INBOX.Client Correspondence: read() failed with file /usr/www/dovecot_indexes/********.[2]co.za/orders/.Client Correspondence/dovecot.index.cache: Cannot allocate memory Sep 9 14:29:32 [3]www23.jnb2.host-h.net dovecot: imap(*****(a)*******.[4]co.za): Error: mremap_anon(/usr/www/dovecot_indexes/********.[5]co.za/orders/.Client Correspondence/dovecot.index.cache, 967524352) failed: Cannot allocate memory Sep 9 14:29:32 [6]www23.jnb2.host-h.net dovecot: imap(*****@*******): Error: mremap_anon(/usr/www/dovecot_indexes/********.[7]co.za/orders/.Client Correspondence/dovecot.index.cache, 967524352) failed: Cannot allocate memory Sep 9 14:29:32 [8]www23.jnb2.host-h.net dovecot: imap(*****@*******): Error: Mailbox INBOX.Client Correspondence: read() failed with file /usr/www/dovecot_indexes/********.[9]co.za/orders/.Client Correspondence/dovecot.index.cache: Cannot allocate memory Sep 9 14:29:32 [10]www23.jnb2.host-h.net dovecot: imap(*****@*******): Error: mremap_anon(/usr/www/dovecot_indexes/********.[11]co.za/orders/.Client Correspondence/dovecot.index.cache, 967524352) failed: Cannot allocate memory Sep 9 14:29:32 [12]www23.jnb2.host-h.net dovecot: imap(*****(a)*******.[13]co.za): Error: mremap_anon(/usr/www/dovecot_indexes/********.[14]co.za/orders/.Client Correspondence/dovecot.index.cache, 967524352) failed: Cannot allocate memory Sep 9 14:29:32 [15]www23.jnb2.host-h.net dovecot: imap(*****(a)*******.[16]co.za): Error: Mailbox INBOX.Client Correspondence: read() failed with file /usr/www/dovecot_indexes/********.[17]co.za/orders/.Client Correspondence/dovecot.index.cache: Cannot allocate memory Evan Booyens Linux Platform Engineer xneelo (Pty) Ltd SA Contact Centre: 0861 0861 08 International: +27 21 970 2000 Disclaimer: [18]xneelo.co.za/email-disclaimer Formerly known as Hetzner SA References Visible links 1. http://www23.jnb2.host-h.net/ 2. http://co.za/orders/.Client 3. http://www23.jnb2.host-h.net/ 4. http://co.za/ 5. http://co.za/orders/.Client 6. http://www23.jnb2.host-h.net/ 7. http://co.za/orders/.Client 8. http://www23.jnb2.host-h.net/ 9. http://co.za/orders/.Client 10. http://www23.jnb2.host-h.net/ 11. http://co.za/orders/.Client 12. http://www23.jnb2.host-h.net/ 13. http://co.za/ 14. http://co.za/orders/.Client 15. http://www23.jnb2.host-h.net/ 16. http://co.za/ 17. http://co.za/orders/.Client 18. http://xneelo.co.za/email-disclaimer

1 0

Crash on FreeBSD 14.4 with dovecot 2.4.5
by Frank Volf 09 Sep '26

09 Sep '26

Hi, On a daily basis I see a anvil crash in my logs for dovecot 2.4.5 on FreeBSD. Not sure if this is a FreeBSD specific issue, a dovecot issue, or a configuration issue (this is the first system converted from 2.3 configuration syntax): Sep 9 03:20:00 mail dovecot[53730]: anvil: Panic: file anvil-connection.c: line 837: unreached Sep 8 16:40:00 mail dovecot[53730]: anvil: Panic: file anvil-connection.c: line 837: unreached Sep 7 20:47:28 mail dovecot[6215]: anvil: Panic: file anvil-connection.c: line 838 (anvil_connection_destroy): assertion failed: (hash_conn == conn) Sep 6 17:07:24 mail dovecot[96610]: anvil: Panic: file anvil-connection.c: line 837: unreached Sep 6 20:40:01 mail dovecot[96610]: anvil: Panic: file anvil-connection.c: line 837: unreached Sep 6 21:53:59 mail dovecot[96610]: anvil: Panic: file anvil-connection.c: line 837: unreached The "assertion failed" only happened once, but the "unreached" happen on a daily basis. About 20 minutes (more or less) after each crash I see also the following message: Sep 8 16:56:32 mail dovecot[53730]: anvil: Error: connect limit: disconnection for unknown (pid=59834, user=xxxx, service=imap, ip=x.x.x.x, conn_guid=7925eb292e15a06abae9000050df13ba) Can somebody please give me some pointers on how to solve or troubleshoot this? Kind regards, Frank Hi, On a daily basis I see a anvil crash in my logs for dovecot 2.4.5 on FreeBSD. Not sure if this is a FreeBSD specific issue, a dovecot issue, or a configuration issue (this is the first system converted from 2.3 configuration syntax): Sep 9 03:20:00 mail dovecot[53730]: anvil: Panic: file anvil-connection.c: line 837: unreached Sep 8 16:40:00 mail dovecot[53730]: anvil: Panic: file anvil-connection.c: line 837: unreached Sep 7 20:47:28 mail dovecot[6215]: anvil: Panic: file anvil-connection.c: line 838 (anvil_connection_destroy): assertion failed: (hash_conn == conn) Sep 6 17:07:24 mail dovecot[96610]: anvil: Panic: file anvil-connection.c: line 837: unreached Sep 6 20:40:01 mail dovecot[96610]: anvil: Panic: file anvil-connection.c: line 837: unreached Sep 6 21:53:59 mail dovecot[96610]: anvil: Panic: file anvil-connection.c: line 837: unreached The "assertion failed" only happened once, but the "unreached" happen on a daily basis. About 20 minutes (more or less) after each crash I see also the following message: Sep 8 16:56:32 mail dovecot[53730]: anvil: Error: connect limit: disconnection for unknown (pid=59834, user=xxxx, service=imap, ip=x.x.x.x, conn_guid=7925eb292e15a06abae9000050df13ba) Can somebody please give me some pointers on how to solve or troubleshoot this? Kind regards, Frank

1 0

iOS email client / imap push
by Jorge Bastos 08 Sep '26

08 Sep '26

Howdy, Does anyway had an issue with latest iOS's, where the native email client put the messages as seen, when the only thing that is done is just "refresh", the message wasn't open, i tested myself. Anyone/is it known, if yes any workarround or wait for apple to solve it? Howdy, Does anyway had an issue with latest iOS's, where the native email client put the messages as seen, when the only thing that is done is just "refresh", the message wasn't open, i tested myself. Anyone/is it known, if yes any workarround or wait for apple to solve it?

1 0

Re: Help with sieve
by Jorge Bastos 08 Sep '26

08 Sep '26

António, Oh, i'm so sorry for the question and the time of you all. Yes, i'm missing the stop on the 1st rule, sieve executes them from top to bottom. Solved, and thank you all for the time, On 2026-09-06 22:14, Antonio Oliveira via dovecot wrote: > On 9/6/2026 9:48 PM, Jorge Bastos via dovecot wrote: > >> Hi all, >> >> Well, my issue is not exacly what you descrived, >> >> I have an account, that i want to forward all incoming emails, so far >> so >> good. >> Before the emails are forward, i want to delete some, based on the >> sender >> domain. >> >> Thing is, i think managesieve roundcube plugin is producing the script >> wrong, here's what i have, i have 1 rule for the delete some senders, >> ok, >> and the 2nd for the redirect >> >> # rule:[blocks] >> if anyof (header :contains "from" "clubefashion.com", header :contains >> "from" "nutribody.pt", header :contains "from" "mcdonalds.pt") >> { >> discard; >> redirect "jorge(a)domain.pt"; >> } >> # rule:[redir] >> if true >> { >> redirect "jorge(a)domain.pt"; >> } > > Hello, > > if you want to forward all of the emails, regardless of the sender > domain and then "delete" them from the original inbox I would do > (option 1): > > # rule:[blocks] > if anyof (header :contains "from" "clubefashion.com", header :contains > "from" "nutribody.pt", header :contains "from" "mcdonalds.pt") > { > redirect "jorge(a)domain.pt"; > discard; > stop; > } > # rule:[redir] > if true > { > redirect "jorge(a)domain.pt"; > stop; > } > > If, on the other hand you do not want do forward them and also do not > want to keep them then simply do (option 2): > > # rule:[blocks] > if anyof (header :contains "from" "clubefashion.com", header :contains > "from" "nutribody.pt", header :contains "from" "mcdonalds.pt") > { > discard; > stop; > } > # rule:[redir] > if true > { > redirect "jorge(a)domain.pt"; > stop; > } > > option 1 - Email is redirected, discarded and rule processing stops > (which inhibits the implicit "keep" from running, so the email is > redirected to the other mailbox but not kept on the original one). > > option 2 - Email from those domains is discarded and rule processing > stops, again inhibiting the implicit keep. For the other domains, email > is redirected and "implicilty" kept on the original mailbox. > > if you're using roundcube you should have an action when creating the > rule to "stop evaluating rules" or something else to that effect when > creating the rule, that will add the "stop;" line on each rule. > you just need to add it in the correct order to make it work. > > In your first message you stated that you wanted to avoid having those > blocked domain emails from being stored in the original mailbox, so > option 2 should work correctly for that. The rules you have in this > message will redirect both the "blocked" and all other emails to being > redirected to the other mailbox, which is what option 1 gives you. With > the rules you sent you would get *two* emails from the "blocked" > domains being redirected to "jorge(a)domain.pt" since both rules would > match. > > Hope this clarifies and helps you achieve the desired outcome. Both are > entirely possible with roundcube generated sieve rules, you just need > to decide on which of the two you want. > > Regards, > >> On 2026-09-06 10:15, Toth Attila via dovecot wrote: >> >> I'm using a filter that moves the mail to another directory. The >> original message disappeared only from the initial location if >> imapsieve_expunge_discarded = yes was set. A duplicate remained >> otherwise. I suggest to take a look at on this configuration option >> depending on the purpose of the filter. >> >> On 2026.09.06 02:30, Stephan Bosch via dovecot wrote: >> >> Op 2-9-2026 om 16:00 schreef Antonio Oliveira via dovecot: >> >> Hello, >> >> You can try to add "stop;" after "discard;", so that rule processing >> stops after the discard and doesn't trickle down to the other rule. >> >> Yes, this will help. Why? The discard action command only cancels the >> implicit keep; nothing else. It means that if and only if no other >> explicit action delivers or preserves (keeps!) the message somehow, it >> is discarded. So, if subsequently redirect is triggered, the message >> is redirected, thereby making the discard action ineffective. Stopping >> the script right after discard will make sure no other actions can be >> triggered, thereby making sure the message is discarded (provided no >> earlier actions already triggered some sort of delivery either). >> Without discard or any other action command that cancels the implicit >> keep (such as redirect, fileinto, and ... keep), the default action is >> to "keep" the message, e.g. file it to INBOX. >> >> Regards, >> >> Stephan. >> >> On 9/2/2026 1:05 PM, Jorge Bastos via dovecot wrote: >> >> Hi guys, >> >> Small help with a sieve script, I have the script below in a >> useraccount, >> in this exact order. >> The redirect works, but the discard doesn't. >> A message that comes from the domain "clubefashing.com" or >> "nutribody.pt", >> is always redirected. >> >> Any idea what is wrong here? >> >> # rule:[blocks] >> if anyof (header :contains "from" "clubefashion.com", header >> :contains >> "from" "nutribody.pt") >> { >> discard; >> } >> # rule:[redir] >> if true >> { >> redirect "[1]jorge(a)decimal.pt"; >> } >> >> _______________________________________________ >> dovecot mailing list -- [2]dovecot(a)dovecot.org >> To unsubscribe send an email to [3]dovecot-leave(a)dovecot.org >> >> _______________________________________________ >> dovecot mailing list -- [4]dovecot(a)dovecot.org >> To unsubscribe send an email to [5]dovecot-leave(a)dovecot.org >> >> References >> >> Visible links >> 1. mailto:jorge@decimal.pt >> 2. mailto:dovecot@dovecot.org >> 3. mailto:dovecot-leave@dovecot.org >> 4. mailto:dovecot@dovecot.org >> 5. mailto:dovecot-leave@dovecot.org >> >> _______________________________________________ >> dovecot mailing list -- dovecot(a)dovecot.org >> To unsubscribe send an email to dovecot-leave(a)dovecot.org Antonio, Oh, i'm so sorry for the question and the time of you all. Yes, i'm missing the stop on the 1st rule, sieve executes them from top to bottom. Solved, and thank you all for the time, On 2026-09-06 22:14, Antonio Oliveira via dovecot wrote: On 9/6/2026 9:48 PM, Jorge Bastos via dovecot wrote: Hi all, Well, my issue is not exacly what you descrived, I have an account, that i want to forward all incoming emails, so far so good. Before the emails are forward, i want to delete some, based on the sender domain. Thing is, i think managesieve roundcube plugin is producing the script wrong, here's what i have, i have 1 rule for the delete some senders, ok, and the 2nd for the redirect # rule:[blocks] if anyof (header :contains "from" "clubefashion.com", header :contains "from" "nutribody.pt", header :contains "from" "mcdonalds.pt") { discard; redirect "[1]jorge(a)domain.pt"; } # rule:[redir] if true { redirect "[2]jorge(a)domain.pt"; } Hello, if you want to forward all of the emails, regardless of the sender domain and then "delete" them from the original inbox I would do (option 1): # rule:[blocks] if anyof (header :contains "from" "clubefashion.com", header :contains "from" "nutribody.pt", header :contains "from" "mcdonalds.pt") { redirect "[3]jorge(a)domain.pt"; discard; stop; } # rule:[redir] if true { redirect "[4]jorge(a)domain.pt"; stop; } If, on the other hand you do not want do forward them and also do not want to keep them then simply do (option 2): # rule:[blocks] if anyof (header :contains "from" "clubefashion.com", header :contains "from" "nutribody.pt", header :contains "from" "mcdonalds.pt") { discard; stop; } # rule:[redir] if true { redirect "[5]jorge(a)domain.pt"; stop; } option 1 - Email is redirected, discarded and rule processing stops (which inhibits the implicit "keep" from running, so the email is redirected to the other mailbox but not kept on the original one). option 2 - Email from those domains is discarded and rule processing stops, again inhibiting the implicit keep. For the other domains, email is redirected and "implicilty" kept on the original mailbox. if you're using roundcube you should have an action when creating the rule to "stop evaluating rules" or something else to that effect when creating the rule, that will add the "stop;" line on each rule. you just need to add it in the correct order to make it work. In your first message you stated that you wanted to avoid having those blocked domain emails from being stored in the original mailbox, so option 2 should work correctly for that. The rules you have in this message will redirect both the "blocked" and all other emails to being redirected to the other mailbox, which is what option 1 gives you. With the rules you sent you would get *two* emails from the "blocked" domains being redirected to "[6]jorge(a)domain.pt" since both rules would match. Hope this clarifies and helps you achieve the desired outcome. Both are entirely possible with roundcube generated sieve rules, you just need to decide on which of the two you want. Regards, On 2026-09-06 10:15, Toth Attila via dovecot wrote: I'm using a filter that moves the mail to another directory. The original message disappeared only from the initial location if imapsieve_expunge_discarded = yes was set. A duplicate remained otherwise. I suggest to take a look at on this configuration option depending on the purpose of the filter. On 2026.09.06 02:30, Stephan Bosch via dovecot wrote: Op 2-9-2026 om 16:00 schreef Antonio Oliveira via dovecot: Hello, You can try to add "stop;" after "discard;", so that rule processing stops after the discard and doesn't trickle down to the other rule. Yes, this will help. Why? The discard action command only cancels the implicit keep; nothing else. It means that if and only if no other explicit action delivers or preserves (keeps!) the message somehow, it is discarded. So, if subsequently redirect is triggered, the message is redirected, thereby making the discard action ineffective. Stopping the script right after discard will make sure no other actions can be triggered, thereby making sure the message is discarded (provided no earlier actions already triggered some sort of delivery either). Without discard or any other action command that cancels the implicit keep (such as redirect, fileinto, and ... keep), the default action is to "keep" the message, e.g. file it to INBOX. Regards, Stephan. On 9/2/2026 1:05 PM, Jorge Bastos via dovecot wrote: Hi guys, Small help with a sieve script, I have the script below in a useraccount, in this exact order. The redirect works, but the discard doesn't. A message that comes from the domain "clubefashing.com" or "nutribody.pt", is always redirected. Any idea what is wrong here? # rule:[blocks] if anyof (header :contains "from" "clubefashion.com", header :contains "from" "nutribody.pt") { discard; } # rule:[redir] if true { redirect "[1][7]jorge(a)decimal.pt"; } _______________________________________________ dovecot mailing list -- [2][8]dovecot(a)dovecot.org To unsubscribe send an email to [3][9]dovecot-leave(a)dovecot.org _______________________________________________ dovecot mailing list -- [4][10]dovecot(a)dovecot.org To unsubscribe send an email to [5][11]dovecot-leave(a)dovecot.org References Visible links 1. mailto:[12]jorge@decimal.pt 2. mailto:[13]dovecot@dovecot.org 3. mailto:[14]dovecot-leave@dovecot.org 4. mailto:[15]dovecot@dovecot.org 5. mailto:[16]dovecot-leave@dovecot.org _______________________________________________ dovecot mailing list -- [17]dovecot(a)dovecot.org To unsubscribe send an email to [18]dovecot-leave(a)dovecot.org References Visible links 1. mailto:jorge@domain.pt 2. mailto:jorge@domain.pt 3. mailto:jorge@domain.pt 4. mailto:jorge@domain.pt 5. mailto:jorge@domain.pt 6. mailto:jorge@domain.pt 7. mailto:jorge@decimal.pt 8. mailto:dovecot@dovecot.org 9. mailto:dovecot-leave@dovecot.org 10. mailto:dovecot@dovecot.org 11. mailto:dovecot-leave@dovecot.org 12. mailto:jorge@decimal.pt 13. mailto:dovecot@dovecot.org 14. mailto:dovecot-leave@dovecot.org 15. mailto:dovecot@dovecot.org 16. mailto:dovecot-leave@dovecot.org 17. mailto:dovecot@dovecot.org 18. mailto:dovecot-leave@dovecot.org

1 0

Problem email client iPhone ios18.2
by andrzej.milewski＠gmail.com 08 Sep '26

08 Sep '26

Hello, I have a fairly new installation of the Dovecot server version 2.3.19.1 on Debian 12.8. In general, the server works correctly. It sends and receives emails without issues. The clients primarily use Thunderbird on desktops and Gmail on Android. However, some clients are using iPhones with various hardware versions. Those with iOS below version 18 work correctly without any issues. Those who have updated their phones to version 18 and now even 18.2 are experiencing problems with mailbox synchronization. On version 18.2, the issue appears as follows: When you open the app, you can read several messages. They load correctly, but, for instance, attachments do not. If I wait for some time, the attachment eventually loads. During this time, I observe the server logs, and it shows that a certain session on the Dovecot server has ended. Dec 17 13:13:01 iredmail0 dovecot[408]: imap(xxx(a)xxx.com)<44785><1QGZCHcp/+3AqM2O>: Disconnected: Connection closed (UID SEARCH finished 92.295 secs ago) in=2972 out=6076956 deleted=0 expunged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=36 body_bytes=6059064 Dec 18 08:40:41 iredmail0 dovecot[408]: imap(xxx(a)xxx.com)<177412>: Disconnected: Connection closed (UID FETCH finished 90.079 secs ago) in=5126 out=1304237 deleted=0 expunged=0 trashed=0 hdr_count=94 hdr_bytes=289688 body_count=89 body_bytes=969615 Dec 18 08:42:19 iredmail0 dovecot[408]: imap(xxx(a)xxx.com)<177410><D5mqU4cpZ+nAqM2O>: Disconnected: Connection closed (UID FETCH finished 95.051 secs ago) in=4475 out=1162785 deleted=0 expunged=0 trashed=0 hdr_count=95 hdr_bytes=281674 body_count=61 body_bytes=839545 Dec 18 08:44:17 iredmail0 dovecot[408]: imap(edyta.kowalewska(a)laktopol.com.pl)<177918>: Disconnected: Connection closed (UID FETCH finished 92.132 secs ago) in=29399 out=30266644 deleted=0 expunged=0 trashed=0 hdr_count=565 hdr_bytes=1726228 body_count=628 body_bytes=28109455 After the session is closed, the attachment loads immediately. From the logs and router analysis, it appears that the download happens in another previously opened session. After this incident, I go to another message with an attachment, and the situation repeats. There are also situations where the email body does not load, and the app waits for the server until the session closes and the content is fetched in another session. It does not matter whether I connect to the server via the internet or through a local network. On an iPhone 7 with iOS 15.8.3, everything works smoothly. Attachments open without issues. On iOS 18.1.1, attachments do not load, and the session does not close on its own. It takes forever unless the app is closed. In the Gmail app, everything works correctly without any issues. This is clearly a problem with the mail client on iPhone. However, is there anything I can adjust in my server settings to mitigate this issue for users? My dovecot configuration https://pastebin.com/UPNQ5dZz

26 60

mail-crypt: user key generated with crypt_user_key_password still usable without it
by Twinsen＠die-optimisten.net 08 Sep '26

08 Sep '26

Hi, I please need help. Dovecot 2.4.1-4 (docker-mailserver 16.0.1), Maildir, passwd-file for both passdb and userdb. Config: mail_plugins = mail_crypt mail_attribute { dict file { path = %{home}/Maildir/dovecot-attributes } } crypt_user_key_curve = secp521r1 crypt_user_key_require_encrypted = yes I also added a second passdb in Lua that returns the login password as a sha256 hex string: passdb passdb-default { result_success = continue-ok } passdb lua { lua_file = /etc/dovecot/lua/crypt.lua skip = unauthenticated use_worker = yes } The Lua script returns PASSDB_RESULT_OK with: { noauthenticate = "yes", userdb_crypt_user_key_password = <sha256 hex> } What I have verified so far: doveadm auth login lists crypt_user_key_password under "userdb extra fields", so the field reaches userdb. With crypt_user_key_require_encrypted = no and the attributes file removed, an IMAP login auto-creates a user key. That key is unencrypted. With crypt_user_key_require_encrypted = yes and the attributes file removed, no key is created. IMAP logs: dict(file): stat(.../Maildir/dovecot-attributes) failed: No such file or directory So I generated the key manually: doveadm -o crypt_user_key_password=<sha256 hex> \ mailbox cryptokey generate -u user(a)example.com -Uf This succeeded. The new key is active, the old one shows as inactive, and the attributes file grew from 2280 to 3147 bytes. Now incoming mail is stored encrypted, the files start with CRYPTED. However, this still returns the headers in clear text, without any password and without error: doveadm fetch -u user(a)example.com hdr mailbox INBOX So the key appears to be usable without the password at all. My main question is: Does -o crypt_user_key_password actually encrypt the user key when it is generated, or is it only used to unlock an already encrypted key? Related to that: Can an old inactive user key still be used for decryption in this setup? Is there any marker that indicates in the attributes dict whether a user key is password-encrypted? With passwd-file as userdb (no prefetch), should an extra field from a passdb reach the IMAP process that creates or loads the key? Any pointers apreciated. Best regards, Twinsen

1 0

[2.4.5] LDAPS Panic: file ldap-utils.c: line 66: unreached
by inaugurator＠ya.ru 07 Sep '26

07 Sep '26

Hello, LDAP in passdb with 389 port works pretty well. But when I change port to 636 and use ldaps:// I get the error: ``` auth: Panic: file ldap-utils.c: line 66: unreached auth: Error: Raw backtrace: #0 default_fatal_finish[0x7a7e387b9ef4] -> #1 fatal_handler_real[0x7a7e387b9fb2] -> #2 i_internal_fatal_handler[0x7a7e387bb36d] -> #3 i_panic[0x7a7e387ba1ec] -> #4 i_unreached[0x7a7e387bb867] -> #5 ldap_set_opt_str[0x7a7e3763ad84] -> #6 ldap_set_tls_options[0x7a7e3763af3d] -> #7 ldap_set_options[0x7a7e3763200d] -> #8 db_ldap_init_ld[0x7a7e3763230f] -> #9 db_ldap_init[0x7a7e37633efb] -> #10 passdb_ldap_preinit[0x7a7e37635d22] -> #11 passdb_preinit[0x55cc948e7eb9] -> #12 auth_passdb_preinit[0x55cc948c0193] -> #13 auth_preinit[0x55cc948c0a87] -> #14 auths_preinit[0x55cc948c16de] -> #15 main_preinit[0x55cc948bf3e2] -> #16 main[0x55cc948bfae2] -> #17 __libc_init_first[0x7a7e383671d0] -> #18 __libc_start_main[0x7a7e38367280] -> #19 _start[0x55cc948bee20] master: Error: service(auth): command startup failed, throttling for 16.000 secs auth: Fatal: master: service(auth): child 344291 killed with signal 6 (core dumps disabled - https://dovecot.org/bugreport.html#coredumps) ```

1 0

Help with sieve
by Jorge Bastos 07 Sep '26

07 Sep '26

Hi guys, Small help with a sieve script, I have the script below in a useraccount, in this exact order. The redirect works, but the discard doesn't. A message that comes from the domain "clubefashing.com" or "nutribody.pt", is always redirected. Any idea what is wrong here? # rule:[blocks] if anyof (header :contains "from" "clubefashion.com", header :contains "from" "nutribody.pt") { discard; } # rule:[redir] if true { redirect "jorge(a)decimal.pt"; } Hi guys, Small help with a sieve script, I have the script below in a useraccount, in this exact order. The redirect works, but the discard doesn't. A message that comes from the domain "clubefashing.com" or "nutribody.pt", is always redirected. Any idea what is wrong here? # rule:[blocks] if anyof (header :contains "from" "clubefashion.com", header :contains "from" "nutribody.pt") { discard; } # rule:[redir] if true { redirect "jorge(a)decimal.pt"; }

4 6

Process destroy
by Christian H. Kuhn 06 Sep '26

06 Sep '26

Hi all, i have a user who cannot log in anymore with thunderbird. The problem arose after my updating to ubuntu 26.04. It is only that one user with his three accounts who has the problem. If i read the log right, he uses the correct credentials and could log in, if there wasn't a read problem with /proc/self/io and ad Process destroy. Here are the relevant data: root@bywater ~ # lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 26.04.1 LTS Release: 26.04 Codename: resolute root@bywater ~ # dovecot --version 2.4.2 (0962ed2104) /var/log/dovecot/dovecot.debug: 2026-09-06T08:51:08.583060+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6 Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: sasl(plain): Set authid 'user(a)sglasker.de' 2026-09-06T08:51:08.583084+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6 Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: sasl(plain): Performing plain passdb verification 2026-09-06T08:51:08.583108+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6 Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: sql: Performing passdb lookup 2026-09-06T08:51:08.583178+02:00 bywater dovecot: auth-worker(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8)<339340><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: request [11]: Debug: sql: Performing passdb lookup 2026-09-06T08:51:08.583210+02:00 bywater dovecot: auth-worker(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8)<339340><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: request [11]: Debug: sql: query: SELECT email AS user, password FROM user WHERE email = 'user(a)sglasker.de' 2026-09-06T08:51:08.583374+02:00 bywater dovecot: auth-worker: Debug: mysql(127.0.0.1): Finished query 'SELECT email AS user, password FROM user WHERE email = 'user(a)sglasker.de'' in 0 msecs 2026-09-06T08:51:08.585565+02:00 bywater dovecot: auth-worker(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8)<339340><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: request [11]: Debug: sql: Finished passdb lookup 2026-09-06T08:51:08.585652+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: sql: Finished passdb lookup 2026-09-06T08:51:08.585677+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: sasl(plain): Finished plain passdb verification (status=ok) 2026-09-06T08:51:08.585704+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: sasl(plain): Interaction succeeded 2026-09-06T08:51:08.585738+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: Auth request finished 2026-09-06T08:51:08.585769+02:00 bywater dovecot: auth: Debug: conn unix:login (pid=339464,uid=111) [501]: client passdb out: OK#0111#011user=user(a)sglasker.de 2026-09-06T08:51:08.591149+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: static: Performing userdb lookup 2026-09-06T08:51:08.591186+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: static: Finished userdb lookup 2026-09-06T08:51:08.591209+02:00 bywater dovecot: auth: Debug: master userdb out: USER#011622723073#011user@sglasker.de#011uid=5000#011gid=5000#011home=/var/mail/vhosts/sglasker.de/user#011auth_mech=PLAIN#011auth_token=581264423b972f752ffa367319e23d10630ec484#011local_name=IMAP.qno.de 2026-09-06T08:51:08.591236+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8)<G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: sasl(plain): Request destroy 2026-09-06T08:51:08.591513+02:00 bywater dovecot: imap(user(a)sglasker.de)<339465><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: Effective uid=5000, gid=5000, home=/var/mail/vhosts/sglasker.de/user 2026-09-06T08:51:08.591603+02:00 bywater dovecot: imap(user(a)sglasker.de)<339465><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: open(/proc/self/io) failed: Permission denied (euid=5000(vmail) egid=5000(vmail) missing +r perm: /proc/self/io) 2026-09-06T08:51:08.591811+02:00 bywater dovecot: imap(user(a)sglasker.de)<339465><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: Namespace inbox: type=private, prefix=, sep=, inbox=yes, hidden=no, list=yes, subscriptions=yes 2026-09-06T08:51:08.591868+02:00 bywater dovecot: imap(user(a)sglasker.de)<339465><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: maildir++: root=/var/mail/vhosts/sglasker.de/user/Maildir, index=, indexpvt=, control=, inbox=/var/mail/vhosts/sglasker.de/user/Maildir, alt= 2026-09-06T08:51:08.981986+02:00 bywater dovecot: imap(user(a)sglasker.de)<339465><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: Mailbox INBOX: Mailbox opened Any hints? TIA QNo

1 0

Process destroy
by Christian H. Kuhn 06 Sep '26

06 Sep '26

Hi all, i have a user who cannot log in anymore with thunderbird. The problem arose after my updating to ubuntu 26.04. It is only that one user with his three accounts who has the problem. If i read the log right, he uses the correct credentials and could log in, if there wasn't a read problem with /proc/self/io and ad Process destroy. Here are the relevant data: root@bywater ~ # lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 26.04.1 LTS Release: 26.04 Codename: resolute root@bywater ~ # dovecot --version 2.4.2 (0962ed2104) /var/log/dovecot/dovecot.debug: 2026-09-06T08:51:08.583060+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6 Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: sasl(plain): Set authid 'user(a)sglasker.de' 2026-09-06T08:51:08.583084+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6 Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: sasl(plain): Performing plain passdb verification 2026-09-06T08:51:08.583108+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6 Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: sql: Performing passdb lookup 2026-09-06T08:51:08.583178+02:00 bywater dovecot: auth-worker(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8)<339340><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: request [11]: Debug: sql: Performing passdb lookup 2026-09-06T08:51:08.583210+02:00 bywater dovecot: auth-worker(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8)<339340><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: request [11]: Debug: sql: query: SELECT email AS user, password FROM user WHERE email = 'user(a)sglasker.de' 2026-09-06T08:51:08.583374+02:00 bywater dovecot: auth-worker: Debug: mysql(127.0.0.1): Finished query 'SELECT email AS user, password FROM user WHERE email = 'user(a)sglasker.de'' in 0 msecs 2026-09-06T08:51:08.585565+02:00 bywater dovecot: auth-worker(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8)<339340><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: request [11]: Debug: sql: Finished passdb lookup 2026-09-06T08:51:08.585652+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: sql: Finished passdb lookup 2026-09-06T08:51:08.585677+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: sasl(plain): Finished plain passdb verification (status=ok) 2026-09-06T08:51:08.585704+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: sasl(plain): Interaction succeeded 2026-09-06T08:51:08.585738+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: Auth request finished 2026-09-06T08:51:08.585769+02:00 bywater dovecot: auth: Debug: conn unix:login (pid=339464,uid=111) [501]: client passdb out: OK#0111#011user=user(a)sglasker.de 2026-09-06T08:51:08.591149+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: static: Performing userdb lookup 2026-09-06T08:51:08.591186+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: static: Finished userdb lookup 2026-09-06T08:51:08.591209+02:00 bywater dovecot: auth: Debug: master userdb out: USER#011622723073#011user@sglasker.de#011uid=5000#011gid=5000#011home=/var/mail/vhosts/sglasker.de/user#011auth_mech=PLAIN#011auth_token=581264423b972f752ffa367319e23d10630ec484#011local_name=IMAP.qno.de 2026-09-06T08:51:08.591236+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8)<G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: sasl(plain): Request destroy 2026-09-06T08:51:08.591513+02:00 bywater dovecot: imap(user(a)sglasker.de)<339465><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: Effective uid=5000, gid=5000, home=/var/mail/vhosts/sglasker.de/user 2026-09-06T08:51:08.591603+02:00 bywater dovecot: imap(user(a)sglasker.de)<339465><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: open(/proc/self/io) failed: Permission denied (euid=5000(vmail) egid=5000(vmail) missing +r perm: /proc/self/io) 2026-09-06T08:51:08.591811+02:00 bywater dovecot: imap(user(a)sglasker.de)<339465><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: Namespace inbox: type=private, prefix=, sep=, inbox=yes, hidden=no, list=yes, subscriptions=yes 2026-09-06T08:51:08.591868+02:00 bywater dovecot: imap(user(a)sglasker.de)<339465><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: maildir++: root=/var/mail/vhosts/sglasker.de/user/Maildir, index=, indexpvt=, control=, inbox=/var/mail/vhosts/sglasker.de/user/Maildir, alt= 2026-09-06T08:51:08.981986+02:00 bywater dovecot: imap(user(a)sglasker.de)<339465><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: Mailbox INBOX: Mailbox opened Any hints? TIA QNo

1 0

History Assignment Writing Help – Expert Assistance
by Theo Wilson 05 Sep '26

05 Sep '26

Struggling with your history assignments? Our History Assignment Writing Help service offers expert guidance to help you craft well-researched, structured, and original assignments. Fill out this form to get personalized support from experienced writers and improve your grades with ease. https://www.newassignmenthelp.co.uk/history-assignment-help

2 1

Pay Someone to Take My Online Course?
by xotawa2329＠hapincy.com 05 Sep '26

05 Sep '26

Pay Someone to Take My Online Course? Different understudies who battle with reworking school, work, and family obligations select online class tutors to assist them with finishing their tests and complete their coursework. In any case, some solicitation the ethicality of this planning. While <a href="https://onlineclassservices.com/nurs-fpx-4040-assessment-4-attempt-1-inform…">NURS FPX 4040 Assessment 4</a>  has every one of the reserves of being enticing, it goes with two or three serious dangers. This article will examine a piece of the things you ought to remember going before enlisting an online class help association. It's clearly a fact that online classes can be truly troublesome, particularly for working professionals who have a clamoring plan. Oftentimes they are searching for someone to take a whole course or individual tasks for them, to assist with managing their grades and moderate their strain. Nonetheless, be wary of affiliations that guarantee too wonderful to be authentic. They could charge you enormous totals for their associations and end up not conveying. The best technique for guaranteeing that you are getting anything that would be fair is to use an online class tutor who offers an inadequate responsibility. Additionally, review that different schools consider paying someone to take an online class to swindle. Therefore, whenever got, you could go facing silly outcomes like besieging the course, scholarly suspension or even send off. To this end picking a fair relationship with a showed history is crucial. The association is clear: present your mentioning and survey offers from qualified educated authorities. Then enlist the one that is reasonable for yourself and store maintains in <a href="https://onlineclassservices.com/nurs-fpx-4050-assessment-1-attempt-3-prelim…">NURS FPX 4050 Assessment 1</a>  scrow until your assignment is finished. Online classes are eminent among understudies who need to save time on education and spotlight more on work or other private issues. These merge understudies who are taking courses while working and attempting to change family and profession responsibilities, military understudies on sending, and understudies with genuine inadequacies or sickness that make it pursuing for them to go to classes. Unfortunately, there are many tricks that confirmation to take online courses for you. These affiliations charge ridiculous totals and don't complete their obligations. They may also hand you over to your school. Tolerating that they do, you could be killed from your underwriting project or even suspended or removed from school. This isn't the very thing that you truly need for your business and future. Therefore, you genuinely need to track down serious areas of strength for a that offers a fair cost and mind blowing results. To this end you ought to search for a <a href="https://onlineclassservices.com/nurs-fpx-4050-assessment-2-attempt-1-ethica…">NURS FPX 4050 Assessment 2</a>  affiliation that has an inadequate responsibility and splendid customer association. Various individuals decide to use a professional to take their online class since they need the opportunity to go to it very close. They could be working the whole day, supervising family issues, or fighting disease and disappointments that log jam their review tendencies. These professionals can assist you with fulfilling time necessities, stay away from imaginative theft, and set free your nights to zero in on work or other unwinding works out. They may comparatively have the decision to help you with beating any learning handicaps you have. Copyright infringement suggests utilizing someone else's words and thoughts without their endorsement. It is viewed as a kind of cheating and can accomplish a delicate grade or even send off from school. It is difficult to ensure that a used professional won't phony. This is on the grounds that educational foundations don't have <a href="https://onlineclassservices.com/nurs-fpx-4900-assessment-1-assessing-the-pr…">NURS FPX 4900 Assessment 1 Assessing the Problem</a>  assets for check whether understudies are authentic or not. This truly expects that tolerant you are gotten, you will probably lose the cash you paid to have someone take your class. There's no veritable strategy for remaining caution assuming the solitary you enroll to take your online course will tell the truth and dependable. They probably won't be in a tantamount state as you. Moreover, they apparently won't be as dedicated to finishing the class for you as you are. They may very well be doing the base extent of work expected to get reviewed and a brief time frame later vanish. MORE <a href="https://dev.gajim.org/gajim/website/-/issues/35#note_211778">Facebook is a powerful tool for business</a> <a href="https://xtremepape.rs/members/horridhenry7860.397211/about">Mobile Application Development Services</a> <a href="https://xtremepape.rs/members/samfarrid4563.397213/about">best digital marketing agencies</a>

6 6

Lazy-Expunge plugin documentation incomplete?
by Randolf Richardson 04 Sep '26

04 Sep '26

One of the Dovecot repository maintainers on GitHub recommended sending an eMail to you regarding the issue I encountered: Documentation for lazy-expunge doesn't work https://github.com/dovecot/documentation/issues/1555 -------- I converted from Dovecot 2.3 to Dovecot 2.4.1, which was not a minor upgrade. Anyway, I can't get the lazy-expunge plugin to work in 2.4.1 now. Here's my configuration file from 2.3 -- how can I get this working in 2.4.1? Thanks. namespace inbox { mailbox EXPUNGED { autoexpunge = 32days autoexpunge_max_mails = 100000 #auto = create } } # Namespace for lazy_expunge plugin namespace { prefix = EXPUNGED/ hidden = yes list = no subscriptions = no separator = / location = maildir:~/Maildir.deleted:INDEX= } mail_plugins = $mail_plugins lazy_expunge acl plugin { # Move expunged messages into the .EXPUNGED namespace lazy_expunge = EXPUNGED/ # Only move to expunged storage if this is the last copy of the message in the user´s account lazy_expunge_only_last_instance = yes # Exclude Drafts from lazy expunging lazy_expunge_exclude = \Drafts # Copy of each message is done with hard links whenever possible maildir_copy_with_hardlinks = yes # Define ACL so that user cannot list the .EXPUNGED mailbox # Example entry: .EXPUNGED owner rwstipekxa acl = vfile:/etc/dovecot/dovecot.acl # dovecot.acl contains one line: EXPUNGED owner ip # Expunged messages most likely don't want to be included in quota: quota_rule = EXPUNGED:ignore } #lazy_expunge_mailbox = EXPUNGED Here's an example of someone else who encountered the same problem: https://www.dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thr ead/25BXSHQWGQQ3ACVZSYF3O3LC4WROTUCI/ Randolf Richardson, CNA - randolf(a)inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Beautiful British Columbia, Canada https://www.inter-corporate.com/

2 4

Config parser bug?
by Pat Suwalski 03 Sep '26

03 Sep '26

Hello, I recently upgraded my servers from Debian Bullseye to Trixie (2.3 -> 2.4). I have a pretty basic config, though I use Maildir instead of Debian's default of mbox. In the process of getting things working correctly for the new config format, I believe I have stumbled on a bug. To make the inbox work correctly, I need the mail_inbox_path variable to be unset. This is because the default shipped 10-mail.conf file from Debian has: mail_driver = mbox mail_home = /home/%{user | username} mail_path = %{home}/mail mail_inbox_path = /var/mail/%{user} So, I overrode the mail_driver and mail_path in my local.conf. From the documentation, it seems like I should be able to set: mail_inbox_path = And that should clear it. Certainly, doveconf shows no mail_inbox_path variable set when that happens. However, no inbox! If I comment out mail_inbox_path from 10-mail.conf, doveconf output is identical, however the inbox works. My workaround is to make it the same as mail_path: mail_inbox_path = ~/Maildir However, I think the variable unsetting is buggy. This is dovecot 2.4.1. --Pat

3 10

discussion about "Remove doveadm_allowed_commands setting"
by Patrick Cernko 03 Sep '26

03 Sep '26

Hi Timo, hi list, I saw this commit (https://github.com/dovecot/core/commit/2b0947986ccb72e2f5ce13f8bd4b300e94e3…) on Dovecot's github repo: > doveadm: Remove doveadm_allowed_commands setting > The setting only compared the first command name against a list, which > gave a false sense of security. Anyone who is allowed to connect to the > doveadm server can already do practically anything with the commands > that were typically allowed: most commands take a -u/-A user parameter, > and commands like sync, backup and import take parameters that access > arbitrary paths. Restricting the command name doesn't change that, so > doveadm access must be given only to trusted clients regardless. I tried to understand the detailed reasoning but I don't get it. As far as I can follow the code not only the *first command name* is checked but every command send (in the list of commands via HTTP API). From our point of view, this setting has a clear security benefit like this: > # security: we only allow specific doveadm commands via doveadm-server and some more when coming from localhost > doveadm_allowed_commands = user,who > local 127.0.0.1/8 { > doveadm_allowed_commands = user,who,"sieve list","sieve get","sieve put","sieve activate" > } It limits the allowed commands in general to who and user which are read-only. Only if the connection is comming from localhost, we additionally grant some sieve commands for our web interface to manage and test sieve rulesets (https://gitlab.mpi-klsb.mpg.de/pcernko/sieveweb) All other commands are not allowed at all, e.g. it is not possible to delete mails or use dsync via the HTTP API. This policy matches our general security policy to only grant what's needed. So, Timo, I would like to ask, why this setting has to get removed (I assume in the next release) or if it can be restored again in the main branch? Is there anyone else using this setting besides me? What do the other users think about the removal of the setting? 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 1

Minor freebsd issue on dovecot 2.4.5
by Lucas Holt 02 Sep '26

02 Sep '26

On FreeBSD and MidnightBSD, Dovecot's net_getunixcred() relies on getpeereid(), which lacks PID info, causing every imap-login connection to register with anvil as pid=-1 and collide in its per-process hash. Here's an example fix for the problem. Note this was AI generated with claude fable and I don't know what your AI policy is. --- src/lib/net.c.orig 2026-08-28 00:00:00 UTC +++ src/lib/net.c @@ -9,6 +9,9 @@ #include <fcntl.h> #include <ctype.h> #include <sys/un.h> +#ifdef __FreeBSD__ +# include <sys/ucred.h> +#endif #include <netinet/tcp.h> #if defined(HAVE_UCRED_H) # include <ucred.h> /* for getpeerucred() */ @@ -832,6 +835,26 @@ cred_r->gid = ucred.unp_egid; cred_r->pid = ucred.unp_pid; return 0; +#elif defined(LOCAL_PEERCRED) && defined(__FreeBSD__) && __FreeBSD__ >= 13 + /* FreeBSD 13+ / MidnightBSD 4+ (getpeereid() exists too, but struct + xucred also carries the peer pid, which anvil needs) */ + struct xucred ucred; + socklen_t len = sizeof(ucred); + + if (getsockopt(fd, 0, LOCAL_PEERCRED, &ucred, &len) < 0) { + i_error("getsockopt(LOCAL_PEERCRED) failed: %m"); + return -1; + } + + if (ucred.cr_version != XUCRED_VERSION) { + errno = EINVAL; + return -1; + } + + cred_r->uid = ucred.cr_uid; + cred_r->gid = ucred.cr_gid; + cred_r->pid = ucred.cr_pid; + return 0; #elif defined(HAVE_GETPEEREID) /* OSX 10.4+, FreeBSD 4.6+, OpenBSD 3.0+, NetBSD 5.0+ */ if (getpeereid(fd, &cred_r->uid, &cred_r->gid) < 0) {

4 8

Problem with setup of 2.4
by Doug Hardie 02 Sep '26

02 Sep '26

I have a production 2.3 server on the machine named "mail". I have installed 2.4 on the server named "test". I used the configuration converter to convert the production configuration to the new configuration structure. I did add a "log_debug = category=auth" line at the end for debug info. If I use the command to the production server: master# openssl s_client -connect 10.0.1.230:imap -starttls imap -quiet Connecting to 10.0.1.230 Can't use SSL_get_servername depth=3 C=US, O=Internet Security Research Group, CN=ISRG Root X2 verify return:1 depth=2 C=US, O=ISRG, CN=Root YE verify return:1 depth=1 C=US, O=Let's Encrypt, CN=YE2 verify return:1 depth=0 CN=mail.sermon-archive.info verify return:1 . OK Pre-login capabilities listed, post-login capabilities have more. At that point I can login and view mail. However, if i use the same command on the test server: master# openssl s_client -connect 10.0.1.235:993 -starttls imap Connecting to 10.0.1.235 CONNECTED(00000003) At this point is sits there accepting no input. The log shows: Aug 31 13:56:22 test dovecot[85915]: auth: Debug: conn unix:login (uid=144) [6]: Server accepted connection (fd=21) Aug 31 13:56:22 test dovecot[85915]: auth: Debug: conn unix:login (uid=144) [6]: auth client connected (pid=86045) There appears to be an SSL issue. The same certificates are used on both servers. Both servers are running FreeBSD 15.1. dovecot.conf is: test# cat dovecot.conf # Conversion performed at 2026-08-23 05:06:46.587238 dovecot_config_version = 2.4.2 dovecot_storage_version = 2.4.0 auth_mechanisms = plain cram-md5 auth_verbose_passwords = no base_dir = /var/run/home_mail/ first_valid_gid = 0 imap_capability = SASL-IR LOGIN-REFERRALS ID ENABLE LITERAL+ STARTTLS LOGINDISABLED AUTH=CRAM-MD5 lda_mailbox_autocreate = yes login_log_format_elements = user=<%{user}> method=%{mechanism} rip=%{remote_ip} lip=%{local_ip} mpid=%{mail_pid} %{secured} %{ssl_security} session=<%{session}> port=%{local_port} mail_driver = maildir mail_gid = 2222 mail_home = /var/mail/home_mail/%{user | username} mail_log_events = delete undelete expunge copy mailbox_delete mailbox_rename mail_log_fields = uid box msgid size from mail_log_prefix = %{protocol}(%{user})[%{remote_ip}]<%{session}>: mail_path = Maildir mail_temp_scan_interval = 0 mail_uid = 2222 postmaster_address = doug(a)sermon-archive.info protocols = imap syslog_facility = local1 verbose_proctitle = yes namespace inbox { inbox = yes mailbox Drafts { autoexpunge = 5 days special_use = \Drafts } mailbox Junk { autoexpunge = 5 days special_use = \Junk } mailbox Trash { autoexpunge = 50 days special_use = \Trash } mailbox Sent { autoexpunge = 30 days special_use = \Sent } mailbox "Sent Messages" { autoexpunge = 30 days special_use = \Sent } } passdb passwd-file { auth_username_format = %{user | username} default_password_scheme = CRYPT driver = passwd-file passwd_file_path = /usr/local/etc/dovecot/users } userdb static { driver = static fields { allow_all_users = yes home = /var/mail/home_mail/%d/%n } } service imap-login { inet_listener imap { port = 143 } inet_listener imaps { port = 993 ssl = yes } inet_listener imaps2 { port = 998 ssl = yes } } service auth { unix_listener auth-userdb { group = vmail mode = 0666 user = vmail } unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } } service stats { unix_listener stats-reader { group = vmail mode = 0660 user = vmail } unix_listener stats-writer { group = vmail mode = 0660 user = vmail } } ssl_server { cert_file = /www/certs/mail.pem dh_file = /usr/local/etc/dovecot/dh.pem key_file = # hidden, use -P to show it } protocol lda { mail_plugins { sieve = yes } } protocol imap { imap_metadata = yes mail_plugins { mail_log = yes notify = yes } } protocol pop3 { mail_plugins { mail_log = yes notify = yes } } #sieve_script personal { # active_path = /var/mail/home_mail/%{user | username}/.dovecot.sieve # driver = file # path = /var/mail/home_mail/%{user | username}/sieve #} mail_attribute { dict file { path = %{home}/Maildir/dovecot-attributes } } # Warnings during conversion: # - <memory>:8: dropping removed setting 'auth_stats' # - <memory>:50: mail_plugins uses $SET:mail_plugins but adds nothing # - <memory>:180: no converter for 'plugin/@1/stats_refresh' # - <memory>:181: no converter for 'plugin/@1/stats_track_cmds' # - pruned default: inbox prefix = '' log_debug = category=auth -- Doug

2 4

Dovecot 2.4: shared mailboxes not working - maybe related to mail_path
by Markus Schönhaber 02 Sep '26

02 Sep '26

Hi, I've had a hard time trying to upgrade my dovecot 2.3 setup to v. 2.4 (debian 13, Dovecot installed from repo.dovecot.org) One thing I still haven't got to work is mailbox sharing. I have configured this (full doveconf -n output attached): mail_driver = mdbox mail_home = /var/spool/vmail/home/%{user | domain}/%{user | username} mail_path = /var/spool/vmail/mail/%{user | domain}/%{user | username} mail_plugins = quota acl namespace inbox { inbox = yes separator = / } namespace shared { mail_home = /var/spool/vmail/home/%{owner_domain}/%{owner_username} list = children prefix = shared/$domain/$username/ separator = / subscriptions = no type = shared } acl_driver = vfile mail_plugins { acl = yes } protocol imap { mail_plugins { imap_acl = yes } } acl_sharing_map { dict file { path = /var/spool/vmail/home/shared-mailboxes } } Now, given two users: 1: sharing-user(a)example.com 2: sharing-client(a)example.net User 1 wants to share his mailbox "4you" to user 2 by setting these acls: > # doveadm acl add -u sharing-user(a)example.com 4you user=sharing-client(a)example.net lookup read write-seen But the shared mailbox isn't visible for user 2 (in fact, not even the namespace is, since list = children). acl debug shows this: > # doveadm acl debug -u sharing-client(a)example.net shared/example.com/sharing-user/4you > doveadm(sharing-client(a)example.net): Error: Mailbox shared/example.com/sharing-user/4you: Mailbox '4you' in namespace shared doesn't exist in /var/spool/vmail/mail/example.net/sharing-client/mailboxes/4you/dbox-Mails So the shared mailbox is looked for in user 2's mail_path, not in user 1's, who shares it and where the mailbox actually resides. So, I tried and set mail_path = /var/spool/vmail/path/%{owner_domain}/%{owner_username} for the shared namespace. This does not only seem reasonable but also is mentioned in the second config example here: https://doc.dovecot.org/2.4.4/core/config/shared_mailboxes.html#user-shared… But that doesn't help. Instead I get: > # doveadm acl debug -u sharing-client(a)example.net shared/example.com/sharing-user/4you > doveadm(sharing-client(a)example.net): Error: Namespace shared: mail_storage settings: Failed to parse configuration: Failed to expand mail_path setting variables: Unknown variable 'owner_domain' > doveadm(sharing-client(a)example.net): Error: Namespace shared: mail_storage settings: Failed to parse configuration: Failed to expand mail_path setting variables: Unknown variable 'owner_domain' > doveadm(sharing-client(a)example.net): Error: Namespace shared: mail_storage settings: Failed to parse configuration: Failed to expand mail_path setting variables: Unknown variable 'owner_domain' > doveadm(sharing-client(a)example.net): Error: Mailbox shared/example.com/sharing-user/4you: Can't open mailbox shared/example.com/sharing-user/4you: Internal error occurred. Refer to server log for more information. [2026-08-20 14:53:40] Swapping %{owner_domain} and %{owner_username} in the config above, I get Unknown variable 'owner_username' as error. If I set mail_path = /var/spool/vmail/mail/example.com/sharing-user i. e. I hard-code the sharing user's mail_path, sharing works for this particular user. But that won't help if a second user wants to share mailboxes too. > # doveadm acl debug -u sharing-client(a)example.net shared/example.com/sharing-user/4you > doveadm(sharing-client(a)example.net): Info: Mailbox shared/example.com/sharing-user/4you: Mailbox '4you' is in namespace shared > doveadm(sharing-client(a)example.net): Info: Mailbox shared/example.com/sharing-user/4you: Mailbox path: /var/spool/vmail/mail/example.com/sharing-user/mailboxes/4you/dbox-Mails > doveadm(sharing-client(a)example.net): Info: Mailbox shared/example.com/sharing-user/4you: All message flags are shared across users in mailbox > doveadm(sharing-client(a)example.net): Info: Mailbox shared/example.com/sharing-user/4you: User sharing-client(a)example.net has rights: lookup read write-seen > doveadm(sharing-client(a)example.net): Info: Mailbox shared/example.com/sharing-user/4you: Mailbox found from dovecot-acl-list > doveadm(sharing-client(a)example.net): Info: Mailbox shared/example.com/sharing-user/4you: User sharing-user(a)example.com found from ACL shared dict > doveadm(sharing-client(a)example.net): Info: Mailbox shared/example.com/sharing-user/4you: Mailbox shared/example.com/sharing-user/4you is visible in LIST What am I doing wrong? How to do ist right? -- Regards mks

3 6

Problem with setup of 2.4
by Doug Hardie 01 Sep '26

01 Sep '26

I have a production 2.3 server on the machine named "mail". I have installed 2.4 on the server named "test". I used the configuration converter to convert the production configuration to the new configuration structure. I did add a "log_debug = category=auth" line at the end for debug info. If I use the command to the production server: master# openssl s_client -connect 10.0.1.230:imap -starttls imap -quiet Connecting to 10.0.1.230 Can't use SSL_get_servername depth=3 C=US, O=Internet Security Research Group, CN=ISRG Root X2 verify return:1 depth=2 C=US, O=ISRG, CN=Root YE verify return:1 depth=1 C=US, O=Let's Encrypt, CN=YE2 verify return:1 depth=0 CN=mail.sermon-archive.info verify return:1 . OK Pre-login capabilities listed, post-login capabilities have more. At that point I can login and view mail. However, if i use the same command on the test server: master# openssl s_client -connect 10.0.1.235:993 -starttls imap Connecting to 10.0.1.235 CONNECTED(00000003) At this point is sits there accepting no input. The log shows: Aug 31 13:56:22 test dovecot[85915]: auth: Debug: conn unix:login (uid=144) [6]: Server accepted connection (fd=21) Aug 31 13:56:22 test dovecot[85915]: auth: Debug: conn unix:login (uid=144) [6]: auth client connected (pid=86045) There appears to be an SSL issue. The same certificates are used on both servers. Both servers are running FreeBSD 15.1. dovecot.conf is: test# cat dovecot.conf # Conversion performed at 2026-08-23 05:06:46.587238 dovecot_config_version = 2.4.2 dovecot_storage_version = 2.4.0 auth_mechanisms = plain cram-md5 auth_verbose_passwords = no base_dir = /var/run/home_mail/ first_valid_gid = 0 imap_capability = SASL-IR LOGIN-REFERRALS ID ENABLE LITERAL+ STARTTLS LOGINDISABLED AUTH=CRAM-MD5 lda_mailbox_autocreate = yes login_log_format_elements = user=<%{user}> method=%{mechanism} rip=%{remote_ip} lip=%{local_ip} mpid=%{mail_pid} %{secured} %{ssl_security} session=<%{session}> port=%{local_port} mail_driver = maildir mail_gid = 2222 mail_home = /var/mail/home_mail/%{user | username} mail_log_events = delete undelete expunge copy mailbox_delete mailbox_rename mail_log_fields = uid box msgid size from mail_log_prefix = %{protocol}(%{user})[%{remote_ip}]<%{session}>: mail_path = Maildir mail_temp_scan_interval = 0 mail_uid = 2222 postmaster_address = doug(a)sermon-archive.info protocols = imap syslog_facility = local1 verbose_proctitle = yes namespace inbox { inbox = yes mailbox Drafts { autoexpunge = 5 days special_use = \Drafts } mailbox Junk { autoexpunge = 5 days special_use = \Junk } mailbox Trash { autoexpunge = 50 days special_use = \Trash } mailbox Sent { autoexpunge = 30 days special_use = \Sent } mailbox "Sent Messages" { autoexpunge = 30 days special_use = \Sent } } passdb passwd-file { auth_username_format = %{user | username} default_password_scheme = CRYPT driver = passwd-file passwd_file_path = /usr/local/etc/dovecot/users } userdb static { driver = static fields { allow_all_users = yes home = /var/mail/home_mail/%d/%n } } service imap-login { inet_listener imap { port = 143 } inet_listener imaps { port = 993 ssl = yes } inet_listener imaps2 { port = 998 ssl = yes } } service auth { unix_listener auth-userdb { group = vmail mode = 0666 user = vmail } unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } } service stats { unix_listener stats-reader { group = vmail mode = 0660 user = vmail } unix_listener stats-writer { group = vmail mode = 0660 user = vmail } } ssl_server { cert_file = /www/certs/mail.pem dh_file = /usr/local/etc/dovecot/dh.pem key_file = # hidden, use -P to show it } protocol lda { mail_plugins { sieve = yes } } protocol imap { imap_metadata = yes mail_plugins { mail_log = yes notify = yes } } protocol pop3 { mail_plugins { mail_log = yes notify = yes } } #sieve_script personal { # active_path = /var/mail/home_mail/%{user | username}/.dovecot.sieve # driver = file # path = /var/mail/home_mail/%{user | username}/sieve #} mail_attribute { dict file { path = %{home}/Maildir/dovecot-attributes } } # Warnings during conversion: # - <memory>:8: dropping removed setting 'auth_stats' # - <memory>:50: mail_plugins uses $SET:mail_plugins but adds nothing # - <memory>:180: no converter for 'plugin/@1/stats_refresh' # - <memory>:181: no converter for 'plugin/@1/stats_track_cmds' # - pruned default: inbox prefix = '' log_debug = category=auth -- Doug -- Doug

1 0

global ACL file with Dovecot >=2.4.3
by Markus Schönhaber 31 Aug '26

31 Aug '26

Hi, https://doc.dovecot.org/2.4.5/core/plugins/acl.html#acl_global_path says that the acl_global_path config setting was removed with Dovecot 2.4.3 and one should use acl instead. But it does not explain how the new config setting should look like. The documentation further down on the page didn't help me to get the idea. While here https://doc.dovecot.org/2.4.5/core/plugins/acl.html#global-acl-file it is said that the > Global ACL file path is specified as a parameter to vfile driver in > |acl > <https://doc.dovecot.org/2.4.5/core/summaries/settings.html#acl>|, > |/etc/dovecot/dovecot-acl| in the above example. I don't see what the "above example" exactly refers to. In fact, the string "|/etc/dovecot/dovecot-acl" doesn't appear a second time on this page. Can someone give an example, how to configure a global ACL file for Dovecot >=2.4.3? -- Regards mks |

2 4

Dovecot 2.4.1 on DietPi/ARM64: Cannot move/delete any folders via IMAP, and three specific folders are unreadable (but other folders work)
by rdorau＠gmx.de 31 Aug '26

31 Aug '26

Hello, I'm running Dovecot 2.4.1 on a Raspberry Pi 4 with DietPi (Debian 13, ARM64) and had to migrate from another OS with Dovecot 2.3. My maildir is at /var/mail/mailuser. It contains many dot‑prefixed subfolders, e.g. .Archiv, .Archiv.Reisen, .Sozio. Relevant parts from doveconf -n: text dovecot_config_version = 2.4.0 auth_mechanisms = plain login dovecot_storage_version = 2.4.0 listen = * login_trusted_networks = 192.168.178.0/24 mail_driver = maildir mail_home = /var/mail/%u mail_path = /var/mail/%u protocols = imap ssl = no passdb pam { driver = pam } userdb passwd { driver = passwd } namespace inbox { inbox = yes prefix = separator = . } Problem 1: Cannot move, delete, or rename any folder via IMAP. In Thunderbird, I can move individual messages between folders, but I cannot move, rename, or delete any folder itself. This affects all folders, not just specific ones. Right‑clicking a folder and choosing “Delete”, “Rename”, or dragging a folder to another location does nothing – no error, just no effect. I have checked permissions on the maildir; mailuser owns the directories and files, and dovecot is in the mailuser group. Problem 2: Three specific folders cannot be opened (message body not loaded). Most of my archive works fine. But exactly these three folders fail: .Archiv.merk.Versicherungen.Axa (Reiserücktritt) .Archiv.merk.Versicherungen.Bavaria_Haftpflicht .Archiv.merk.Versicherungen.LVM_Auslandsreisekrankenversicherung In Thunderbird, I see the message headers, but when I try to open a message, the body stays empty. On the server, the files are intact – head shows the full header, and the messages are readable as plain files. Other folders with similar special characters (e.g. &APw-, &AOQ-, &ANY-) work without problems. So I don't think the special characters are the cause. Problem 3: doveadm mailbox list shows only INBOX and Trash. Even though the maildir contains many dot‑prefixed subfolders, doveadm mailbox list -u mailuser returns only: text Trash INBOX In Thunderbird, the subfolders appear inside INBOX (e.g. INBOX.Archiv, INBOX.Archiv.Reisen), which is basically correct. But doveadm does not list them as separate mailboxes. What I have already tried (without success): Renaming the three problematic folders to simple names (e.g. Axa_Reiseruecktritt) and creating new folders with the copied mails. Deleting Dovecot index files (dovecot.index*, dovecot-uidlist, subscriptions) and restarting Dovecot. Changing namespace separator and prefix settings. Adding dovecot to mailuser group and adjusting permissions (chmod 750). Forcing Thunderbird to re‑synchronize by deleting local .msf files – after that, the three folders sometimes disappear or become empty in Thunderbird, but the mail files remain on disk. None of this made doveadm mailbox list show the subfolders, and the three folders remain unreadable. My questions: Why does doveadm mailbox list not show the subfolders, even though they exist as dot‑prefixed directories and Thunderbird displays them? What do I need to change so that Dovecot lists them properly? Why can I not move, delete, or rename any folder via IMAP, even though moving messages works? Is this a configuration issue (e.g. missing ACL, wrong permissions, or something with the namespace)? How can I make the three unreadable folders readable again? What is the safest way to rebuild their indexes or re‑create them so that Thunderbird can open the messages? If the folder names are problematic (e.g., due to length or special characters), what is the correct way to rename them in the maildir structure so that Dovecot and Thunderbird can handle them normally? I need a method that preserves the existing mails and the folder hierarchy. I would be very grateful for any hints, because I'm stuck and have already spent many hours on this. Thank you in advance.

3 4

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

29 Aug '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 12

IMAP access problem with iOS Mail app
by Reg Barclay 29 Aug '26

29 Aug '26

Hi, We've been running Dovecot 2.3.x as IMAPS server for quite some years. It works with Thunderbird (our primary mail client), MS Outlook, K9 Mail (Android) and some iPhones / iOS Mail. But we cannot get new iPhones / new iOS to *initially* connect to the server. On the contrary, when the mail account was created in iOS years ago, it continues to work even with modern software versions on iOS. But we cannot set up the mail server on brandnew iPhones. It either loads/waits for minutes without anything happening. Or it gives some error message that an SSL connection could not be established. I've found several reports about similar problems on the web, particularly after iOS 18. Did someone of you have the same problem and managed to solve it? We have a trusted certificate from an "official" CA, so no self-signed certificate or something like that. We have many users working with the server successfully every day, even modern iPhones where the mail account was set up years ago on an older version. So it's not broken in general. The only problem is with new iPhones and the integrated iOS Mail app. Yours, Reg

2 1

Pigeonhole v2.4.5 tarball reuploaded
by Aki Tuomi 28 Aug '26

28 Aug '26

Hi! Due to logistics mistake, the pigeonhole tarball was reuploaded now to include man pages that had dropped out by mistake. No code changes or git changes sneaked in. Sorry for the inconvenience. Aki

1 0

Dovecot Security Advisory 3/2026
by Aki Tuomi 28 Aug '26

28 Aug '26

Hi! We're sharing our latest advisory with you and like to thank everyone who contributed in finding and solving those vulnerabilities. This advisory will also be published at https://documentation.open-xchange.com/dovecot/security/advisories/html/202… --- Classification: TLP:GREEN Internal reference: DOV-8476 Type: CWE-403 (Exposure of File Descriptor to Unintended Control Sphere ('File Descriptor Leak')) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2025-11-25 Solution date: 2026-08-26 Disclosure date: 2026-08-26 CVE: CVE-2026-33263 CVSS: 4.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L) Details: submission-login: Panic when mail_max_userip_connections is reached: Panic: epoll_ctl(del, 8) failed: Bad file descriptor. When mail_max_userip_connections is set (defaul t 10) and reached, submission-login can crash with epoll() panic caused by file descriptor handling issues. Risk: If running in high-security mode (default for community releases), only the new submission connection gets terminated. If running in high-performance mode (default for Pr o releases), all connections handled by the submission-login process will be terminated. The crashes can cause failure for user to send a message, or it can cause duplica te messages to be sent. If TLS is not used (in the backend server processing the submission), duplicate deliveries cannot happen, because the crash can only happen at AUT H stage. No publicly available exploits are known. Solution: Limit the number of connections handled by single submission-login process. This has a performance impact though. Update to non-vulnerable version. --- Internal reference: DOV-8874 Type: CWE-400 (Uncontrolled Resource Consumption) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-03-11 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: ylwango613@yeswehack CVE: CVE-2026-33607 CVSS: 4.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L) Details: Dovecot IMAP LIST match_sub() Exponential Backtracking — CPU Denial of Service. An attacker that has valid credentials can use IMAP LIST command to consume CPU. Risk: This can cause degradation or denial of service for IMAP. No publicly available exploits are known. Solution: Monitor system for abnormal CPU usage and kill the offending process and lock account. Alternatively install fixed version. --- Internal reference: DOV-8884 Type: CWE-400 (Uncontrolled Resource Consumption) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-03-13 Solution date: 2026-08-26 Disclosure date: 2026-08-26 CVE: CVE-2026-27852 CVSS: 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) Details: DoS by sending mail with bad header. An attacker that can send mail to a user can craft a message whose headers contain a very large number of email addresses or MIME par ameters, which causes excessive memory usage when the message is later parsed. Risk: The message is still delivered, but reading it over IMAP can exhaust the memory limit of the process and terminate it, causing denial of service for the affected user. No publicly available exploits are known. Solution: Update to non-vulnerable version. --- Internal reference: DOV-8941 Type: CWE-93 (Improper Neutralization of CRLF Sequences ('CRLF Injection')) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-03-24 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: thanos_haruki@yeswehack CVE: CVE-2026-33606 CVSS: 4.8 (CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:H/A:N) Details: dsync: Mail content can cause dsync protocol injection. Mail content stored by a user can be crafted so that it is interpreted as dsync protocol commands when an administ rator later runs dsync with the stream protocol, for example during a migration. Risk: Injected commands can modify mailbox state on the destination during migration or replication, including internal mailbox attributes that a user should not be able to set directly. It can also cause dsync errors. No publicly available exploits are known. Solution: Avoid running dsync with the stream protocol on mailboxes with untrusted content. Update to non-vulnerable version. --- Internal reference: DOV-8947 Type: CWE-655 (Insufficient Psychological Acceptability) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-03-24 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: heckintosh@yeswehack CVE: CVE-2026-33604 CVSS: 5.9 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N) Details: SMTP Smuggling via Missing Dot-Stuffing After Bare Carriage Return. An attacker that can get Dovecot to relay a message, for example through Sieve redirect or submission relay, can use a crafted line ending in the message body to bypass the outbound protection that prevents message content from being interpreted as SMTP commands. Risk: A downstream mail server that hasn't yet fixed the SMTP smuggling vulnerability can be tricked into treating part of the message body as new SMTP commands, allowing injec tion of spoofed email. This is the same vulnerability class as CVE-2023-51764 and CVE-2023-51766. No publicly available exploits are known. Solution: Where you control the receiving mail servers, ensure they reject bare carriage returns in message data. Update to non-vulnerable version. --- Internal reference: DOV-8949 Type: CWE-400 (Uncontrolled Resource Consumption) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-03-24 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: djvirus@yeswehack CVE: CVE-2026-40014 CVSS: 6.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H) Details: IMAP THREAD REFERENCES O(N²) CPU DoS via Crafted References Header (index-thread-links.c). An attacker that can send mail to a user can craft a message header that makes the IMAP THREAD command consume CPU disproportionate to the size of the message. Risk: When a mail client issues a THREAD command on the affected mailbox, this can cause degradation or denial of service for IMAP. No publicly available exploits are known. Solution: Monitor system for abnormal CPU usage, kill the offending process and remove the offending message from the affected mailbox. Update to non-vulnerable version. --- Internal reference: DOV-8991 Type: CWE-124 (Buffer Underwrite ('Buffer Underflow')) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-04-02 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: ilyar@yeswehack CVE: CVE-2026-40013 CVSS: 4.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L) Details: pigeonhole: Stack Buffer Underflow in Pigeonhole ManageSieve CHECKSCRIPT/PUTSCRIPT. An attacker that has valid credentials can submit a Sieve script containing an extreme numeric literal, which causes an out-of-bounds write when the ManageSieve service compiles the script. Risk: This causes memory corruption and an observed crash of the ManageSieve process, resulting in denial of service for script management. This might be able to be used for re mote code execution. No publicly available exploits are known. Solution: Disable the ManageSieve service if users do not need remote Sieve script management. Update to non-vulnerable version. --- Internal reference: DOV-8994 Type: CWE-400 (Uncontrolled Resource Consumption) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-04-02 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: ilyar@yeswehack CVE: CVE-2026-33605 CVSS: 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) Details: managesieve-login: Pre-auth crash. An unauthenticated attacker can crash the ManageSieve login process by sending a small malformed command before authenticating. Risk: If running in high-security mode (default for community releases), only the attacker's own connection is terminated. If running in high-performance mode (default for Pro releases), all connections handled by the same managesieve-login process are terminated. Repeating the attack can cause denial of service for Sieve script management. No publicly available exploits are known. Solution: Restrict network access to the ManageSieve service to trusted clients. Update to non-vulnerable version. --- Internal reference: DOV-9039 Type: CWE-89 (Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-04-08 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: tipsennn@yeswehack CVE: CVE-2026-40018 CVSS: 7.4 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) Details: MySQL multi-byte escaping wrong. None Risk: None No publicly available exploits are known. Solution: None --- Internal reference: DOV-9041 Type: CWE-400 (Uncontrolled Resource Consumption) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot CE core >=2.4.3 <2.4.5 First fixed revision: OX Dovecot CE core 2.4.5 Discovery date: 2026-04-08 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: ilyar@yeswehack CVE: CVE-2026-40019 CVSS: 5.9 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) Details: v2.4.3 regression: managesieve-login pre-auth infinite loop. An unauthenticated attacker can send a truncated quoted argument to the ManageSieve login process, which make s it spin in an infinite loop consuming CPU. Risk: This can cause degradation or denial of service for Sieve script management, and repeated connections can consume all available CPU on the server. No publicly available e xploits are known. Solution: Monitor system for abnormal CPU usage and kill the offending process. Restrict network access to the ManageSieve service to trusted clients. Update to non-vulnerable vers ion. --- Internal reference: DOV-9046 Type: CWE-125 (Out-of-bounds Read) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-04-08 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: tipsennn@yeswehack CVE: CVE-2026-40015 CVSS: 4.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L) Details: imap-hibernate can be crashed. An attacker that has valid credentials can open many connections to the imap-hibernate service and send invalid commands, which can intermi ttently cause an out-of-bounds read and crash the process. Risk: The crash interrupts hibernated IMAP sessions handled by the affected process, which can cause degradation of service for IMAP. No publicly available exploits are known. Solution: Disable IMAP hibernation. Update to non-vulnerable version. --- Internal reference: DOV-9047 Type: CWE-400 (Uncontrolled Resource Consumption) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-04-08 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: djvirus@yeswehack CVE: CVE-2026-40017 CVSS: 6.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H) Details: IMAP THREAD O(M³) CPU DoS via CRC32 Hash Collision in strmap (mail-index-strmap.c / hash2.c). An attacker that can send mail to a user can craft a message header whose va lues are chosen to collide in an internal hash table, which makes the IMAP THREAD command consume CPU disproportionate to the size of the message. This is a separate issu e from CVE-2026-40014 and is not addressed by that fix. Risk: Whenever a mail client issues a THREAD command on the affected mailbox, this can cause degradation or denial of service for IMAP. No publicly available exploits are known . Solution: Monitor system for abnormal CPU usage, kill the offending process and remove the offending message from the affected mailbox. Update to non-vulnerable version. --- Internal reference: DOV-9066 Type: CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-04-12 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: ilhamaf@yeswehack CVE: CVE-2026-40203 CVSS: 3.7 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N) Details: IMAP Compression Can Reveal Whether a Small Synced Email Body Matches Sender-Chosen Text. When IMAP compression is enabled, the same compression state is reused across re sponses in a session, so response sizes depend on both attacker-supplied mail and other mail in the same mailbox. Risk: An attacker that can send mail to a user and can also observe the sizes of that user's IMAP traffic can confirm whether the body of a small message matches a guessed text . Recovery of arbitrary unknown content was not demonstrated, but the attack can disclose whether a secret-like message body matches a candidate. No publicly available ex ploits are known. Solution: Disable IMAP compression. Update to non-vulnerable version. --- Internal reference: DOV-9070 Type: CWE-416 (Use After Free) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-04-14 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: ilyar@yeswehack CVE: CVE-2026-42007 CVSS: 9.1 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:H) Details: Sieve editheader RCE. An attacker that has valid credentials can use a Sieve script with the editheader extension to trigger a use-after-free in the mail editing code, an d to write memory contents beyond the intended buffer into the delivered mail. Risk: This causes memory leak and opportunity to do memory corruption during mail delivery, which can crash the delivery process and may allow execution of arbitrary code in th e context of that process. No publicly available exploits are known. Solution: Disable the Sieve editheader extension. Update to non-vulnerable version. --- Internal reference: DOV-9099 Type: CWE-284 (Improper Access Control) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-04-22 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: ilhamaf@yeswehack CVE: CVE-2026-40204 CVSS: 3.1 (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N) Details: acl: lda_mailbox_autocreate can bypass acl restrictions. None Risk: None No publicly available exploits are known. Solution: None --- Internal reference: DOV-9106 Type: CWE-287 (Improper Authentication) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.11.2 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.11.2 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-04-23 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: Noobosaurus@yeswehack CVE: CVE-2026-40205 CVSS: 5.9 (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:H/A:N) Details: OAuth2 passdb scope enforcement bypass via OR semantics in remote validation path. An attacker that holds an OAuth2 token granting only part of the required scopes can au thenticate, because when more than one scope is required in the configuration, the remote token validation paths accept a token that carries only one of them, while the l ocal token validation path correctly requires all of them. Risk: The configured authorization policy is not enforced, so a token that was granted only part of the required permissions is accepted where it should have been rejected. No publicly available exploits are known. Solution: Use local token validation where tokens can be validated locally. Update to non-vulnerable version. --- Internal reference: DOV-9109 Type: CWE-287 (Improper Authentication) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.4 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.4 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-04-23 Solution date: 2026-08-26 Disclosure date: 2026-08-26 CVE: CVE-2026-42008 CVSS: 4.3 (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N) Details: XCLIENT FORWARD= bare token not namespaced, allows nopassword injection via trusted proxy. Forwarding information received from a host listed as a trusted proxy is not ke pt separate from Dovecot's own authentication fields, so a value sent by that host can be injected as an internal authentication field. Risk: Any host permitted to act as a trusted proxy can authenticate as any user without knowing that user's password. This affects deployments whose password database honours a field that permits authentication without a password. Deployments that do not configure trusted proxies are not affected. No publicly available exploits are known. Solution: Restrict the list of trusted proxy networks to hosts that are fully under your control. Update to non-vulnerable version. --- Internal reference: DOV-9142 Type: CWE-400 (Uncontrolled Resource Consumption) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-04-27 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: ilhamaf@yeswehack CVE: CVE-2026-42395 CVSS: 4.3 (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) Details: Single NUL-Byte XCLIENT FORWARD Payload Crashes. A host listed as a trusted proxy can send forwarding information containing a NUL byte, which crashes the login process o n the following login attempt. Risk: The login process is terminated, which can cause degradation or denial of service for logins. Deployments that do not configure trusted proxies are not affected. No publi cly available exploits are known. Solution: Restrict the list of trusted proxy networks to hosts that are fully under your control. Update to non-vulnerable version. --- Internal reference: DOV-9148 Type: CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-04-27 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: D4RKCYPH3R@yeswehack CVE: CVE-2026-42393 CVSS: 3.1 (CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N) Details: doveadm_password or api key length can still be leaked with timing comparisons. The comparison used for the doveadm password and API key is not fully timing safe and can reveal the length of the configured secret. Risk: An attacker with access to the same network as the doveadm service, able to make repeated requests and measure response timing accurately, can learn the length of the sec ret, which reduces the effort needed to guess it. The secret value itself is not disclosed. No publicly available exploits are known. Solution: Restrict network access to the doveadm service to trusted clients. Update to non-vulnerable version. --- Internal reference: DOV-9223 Type: CWE-1050 (Excessive Platform Resource Consumption within a Loop) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.15 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.15 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-05-05 Solution date: 2026-08-26 Disclosure date: 2026-08-26 CVE: CVE-2026-52681 CVSS: 3.1 (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L) Details: Sieve resource usage tracking lost when active script changes. Sieve CPU resource usage is tracked in the compiled script, so an attacker that has valid credentials can r eset the accounting by repeatedly changing the active script. Compiled script files are also not removed when a script is deleted or renamed. Risk: The configured Sieve CPU limit can be bypassed, allowing sustained CPU consumption, and the leftover files increase disk consumption. Both can cause degradation of servic e for mail delivery. No publicly available exploits are known. Solution: Monitor system for abnormal CPU usage and disk consumption. Update to non-vulnerable version. --- Internal reference: DOV-9230 Type: CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-05-06 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: djvirus@yeswehack CVE: CVE-2026-42392 CVSS: 4.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) Details: imap-urlauth leaks memory into user-visible error messages. An attacker that has valid credentials can send an invalid IMAP URLFETCH command, which causes uninitialized m emory to be included in the error response returned to the client. Risk: Process memory contents can be disclosed to the client, which may include sensitive data. No publicly available exploits are known. Solution: Disable the IMAP URLAUTH functionality. Update to non-vulnerable version. --- Internal reference: DOV-9309 Type: CWE-287 (Improper Authentication) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.13 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.13 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-05-28 Solution date: 2026-08-26 Disclosure date: 2026-08-26 CVE: CVE-2026-73208 CVSS: 7.4 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) Details: auth: db-oauth2: aud claim used as fallback for missing scope claim. An attacker that holds a token intended for a different purpose can authenticate, because when an OAu th2 token response does not contain a scope claim, the audience claim is used in its place and checked against the configured required scopes. These are different concept s, and the audience claim does not describe what a token is allowed to do. Risk: A token that grants no relevant permissions can be accepted because its intended recipient value happens to match a configured scope name, granting access that should hav e been denied. It also hides an identity provider misconfiguration where scopes are not being issued at all. No publicly available exploits are known. Solution: Ensure the identity provider issues a scope claim for all tokens used with Dovecot, and that configured scope names do not match audience values. Update to non-vulnerable version. --- Internal reference: DOV-9401 Type: CWE-674 (Uncontrolled Recursion) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-06-10 Solution date: 2026-08-26 Disclosure date: 2026-08-26 CVE: CVE-2026-73209 CVSS: 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) Details: imap-login crash: Self-recursion on zero-output decompress chunks. An attacker that has valid credentials can send crafted compressed data that causes the affected proces s to exhaust its stack and crash. Risk: The affected process is terminated, which can cause degradation or denial of service for IMAP. No publicly available exploits are known. Solution: Update to non-vulnerable version. --- Internal reference: DOV-9529 Type: CWE-400 (Uncontrolled Resource Consumption) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-07-04 Solution date: 2026-08-26 Disclosure date: 2026-08-26 CVE: CVE-2026-42391 CVSS: 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) Details: imap: Pre-login memory/CPU growth with ID command. An unauthenticated attacker can send an IMAP ID command with a very large number of parameters before logging in, which causes memory and CPU usage to grow disproportionately. Risk: The login process can be terminated by the out-of-memory handling, which also terminates all other connections handled by the same process. This can cause degradation or denial of service for IMAP logins. No publicly available exploits are known. Solution: Limit the number of connections handled by a single imap-login process. This has a performance impact though. Update to non-vulnerable version. --- Internal reference: DOV-9530 Type: CWE-400 (Uncontrolled Resource Consumption) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.11 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.11 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-07-04 Solution date: 2026-08-26 Disclosure date: 2026-08-26 CVE: CVE-2026-52687 CVSS: 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) Details: IMAP: COMPRESS ZSTD can cause excessive memory usage. An attacker that has valid credentials can select a compression algorithm for the IMAP connection whose decompressio n state requires a large amount of memory, and open several such connections. Risk: The memory limit of the process is reached with only a few connections, terminating the process and all connections it handles, which can cause degradation or denial of s ervice for IMAP. No publicly available exploits are known. Solution: Disable IMAP compression. Alternatively limit the number of connections handled by a single imap-login process, though this has a performance impact. Update to non-vulner able version.

1 0

Dovecot 2.4.2 auth unix socket rejects Postfix 3.10.6 handshake with EACCES
by root 27 Aug '26

27 Aug '26

Environment: Ubuntu 26.04 (resolute), kernel 7.0.0-30-generic, Postfix 3.10.6-4ubuntu2.1, Dovecot 2.4.2+dfsg1-3ubuntu2.1. Problem: Postfix smtpd (submission) connects to /var/spool/postfix/private/auth but write(VERSION...CPID...) returns EACCES. Log: "warning: SASL: Couldn't send handshake: Permission denied", then "fatal: no SASL authentication mechanisms". Socket permissions are correct (postfix:postfix 0660). Writing to the same socket as user postfix from python works. AppArmor in complain mode and removed profile - no change. Running postfix master manually (not via systemd) still fails. Only real smtpd process fails, python with same uid/gid succeeds. Workaround: inet listener on 127.0.0.1:3456 for auth works, AUTH succeeds.

3 2

POP3 and IMAP proxy for url filtering missmatch links and virus
by Jorge Bastos 27 Aug '26

27 Aug '26

Howdy, This is not quite dovecot related, but maybe can help me, I'm looking for a pop3/imap proxy for url check for missmatch links, and virus check of the links, Anyone knows a good tool for that? Thanks, Jorge, Howdy, This is not quite dovecot related, but maybe can help me, I'm looking for a pop3/imap proxy for url check for missmatch links, and virus check of the links, Anyone knows a good tool for that? Thanks, Jorge,

2 1

Re: Crash in imapd
by Benjamin NIVOIS 27 Aug '26

27 Aug '26

hello. perhaps not related but relevant. the root cause was a "2 bytes" empty message in the box "e-commerce" directory when Evolution starts a FETCH : >#21 0x000055d629ab5f8e in cmd_fetch (cmd=0x55d669274958) at ./src/imap/cmd-fetch.c:382 client = <optimized out> ctx = 0x55d669274ba8 args = 0x55d66927d200 next_arg = <optimized out> list_arg = 0x0 search_args = 0x0 qresync_args = {qresync_sample_seqset = 0x55d6692426d0, qresync_sample_uidset = 0x55d66929be60} messageset = 0x55d66927d370 "4764:4766,4409,2912:2917,103" send_vanished = <optimized out> ret = <optimized out> faulting message UID 2912 : no headers, 2 byes size (gdb) p mail->mail.mail.uid $2 = 2912 (gdb) p mail->mail.mail.box->vname $3 = 0x55d6692981f0 "e-commerce" doveadm fetch -u <user>"hdr" mailbox e-commerce uid 2912 hdr: doveadm fetch -u <user> "uid guid flags date.received size.physical" mailbox e-commerce uid 2912 uid: 2912 guid: d41d8cd98f00b204e9800998ecf8427e flags: Old date.received: 2020-07-17 00:05:34 size.physical: 2 basically, deleting the faulting message solved the issue. I've got the dovecot-sysreport available if needed -- Regards hello. perhaps not related but relevant. the root cause was a "2 bytes" empty message in the box "e-commerce" directory when Evolution starts a FETCH : >#21 0x000055d629ab5f8e in cmd_fetch (cmd=0x55d669274958) at ./src/imap/cmd-fetch.c:382 client = <optimized out> ctx = 0x55d669274ba8 args = 0x55d66927d200 next_arg = <optimized out> list_arg = 0x0 search_args = 0x0 qresync_args = {qresync_sample_seqset = 0x55d6692426d0, qresync_sample_uidset = 0x55d66929be60} messageset = 0x55d66927d370 "4764:4766,4409,2912:2917,103" send_vanished = <optimized out> ret = <optimized out> faulting message UID 2912 : no headers, 2 byes size (gdb) p mail->mail.mail.uid $2 = 2912 (gdb) p mail->mail.mail.box->vname $3 = 0x55d6692981f0 "e-commerce" doveadm fetch -u <user>"hdr" mailbox e-commerce uid 2912 hdr: doveadm fetch -u <user> "uid guid flags date.received size.physical" mailbox e-commerce uid 2912 uid: 2912 guid: d41d8cd98f00b204e9800998ecf8427e flags: Old date.received: 2020-07-17 00:05:34 size.physical: 2 basically, deleting the faulting message solved the issue. I've got the dovecot-sysreport available if needed -- Regards

1 1

Freebsd Dovecot24 port
by The Doctor 23 Aug '26

23 Aug '26

Something is not correct. Dovecot 2.3 ports does work, but not the 2.4 ports Here are errors I am seeing Aug 21 15:01:01 auth: Debug: conn unix:login (uid=30) [9]: client in: AUTH 1 PLAIN protocol=imap final-resp-ok secured=tls session=f5oT75RZ zsYKDgAE lip=204.209.81.1 rip=10.14.0.4 lport=993 rport=50 894 ssl_ja3_hash=b8f77ef1c9705bb58db7ce238ba640d7 local_name=pop3.nk.ca resp=AGRhdmUAIS0xLSFAIyQlXiYqKCkxMjM0NTY3ODkw (previous base64 data may contain sensitive data) Aug 21 15:01:01 auth(?,10.14.0.4,sasl:plain)<f5oT75RZzsYKDgAE>: Debug: sasl(plai n): Request create Aug 21 15:01:01 auth(?,10.14.0.4,sasl:plain)<f5oT75RZzsYKDgAE>: Debug: penalty(1 0.14.0.4): Delaying response for 0 seconds Aug 21 15:01:01 auth(?,10.14.0.4,sasl:plain)<f5oT75RZzsYKDgAE>: Debug: sasl(plai n): Started interaction with initial response (size=30) Aug 21 15:01:01 auth(dave,10.14.0.4,sasl:plain)<f5oT75RZzsYKDgAE>: Debug: sasl(p lain): Set authid 'dave' Aug 21 15:01:01 auth(dave,10.14.0.4,sasl:plain)<f5oT75RZzsYKDgAE>: Debug: sasl(plain): Performing plain passdb verification Aug 21 15:01:01 auth(dave,10.14.0.4,sasl:plain)<f5oT75RZzsYKDgAE>: Debug: passwd-file: Performing passdb lookup Aug 21 15:01:01 auth(dave,10.14.0.4,sasl:plain)<f5oT75RZzsYKDgAE>: Info: passwd-file: missing passwd file: scheme=CRYPT /etc/master.passwd Aug 21 15:01:01 auth(dave,10.14.0.4,sasl:plain)<f5oT75RZzsYKDgAE>: Debug: passwd-file: Finished passdb lookup Aug 21 15:01:01 auth(dave,10.14.0.4,sasl:plain)<f5oT75RZzsYKDgAE>: Debug: sasl(p lain): Finished plain passdb verification (status=user-unknown) Aug 21 15:01:01 auth(dave,10.14.0.4,sasl:plain)<f5oT75RZzsYKDgAE>: Debug: sasl(plain): Interaction failed Aug 21 15:01:01 auth(dave,10.14.0.4,sasl:plain)<f5oT75RZzsYKDgAE>: Debug: Auth request finished Aug 21 15:01:01 auth(dave,10.14.0.4,sasl:plain)<f5oT75RZzsYKDgAE>: Debug: delaying auth failure Aug 21 15:01:03 auth: Debug: conn unix:login (uid=30) [9]: client passdb out: FAIL 1 user=dave Aug 21 15:01:03 auth(dave,10.14.0.4)<f5oT75RZzsYKDgAE>: Debug: sasl(plain): Request destroy Aug 21 15:01:03 imap-login: Info: Login aborted: Connection closed (auth failed, 1 attempts in 2 secs) (auth_failed): user=<dave>, method=PLAIN, rip=10.14.0.4, lip=204.209.81.1, TLS Aug 21 15:01:03 auth: Debug: conn unix:login (uid=30) [9]: Disconnected: EOF (fd=26) Aug 21 15:01:08 master: Info: Dovecot v2.4.4 (8b687aa65c) starting up for imap, pop3, lmtp I switch back to dovecot 2.3 .X no problem. -- Member - Liberal International This is doctor(a)nk.ca Ici doctor(a)nk.ca Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism ; 31 years in the ISP business!

5 9

Safe upgrade path from 2.4.1 to 2.4.4 (CVE-2026-40020) on Debian 13
by Artem Ignatov 22 Aug '26

22 Aug '26

Hello, (Redirected here from support(a)dovecot.org - I understand that address is for commercial/Pro support, and this is a Community Edition question.) We run a production mail server on Debian GNU/Linux 13 (trixie), using the Dovecot package currently shipped in the Debian 13 stable repository: dovecot-core 1:2.4.1+dfsg1-6+deb13u6 We are affected by CVE-2026-40020 ("IMAP folders can be shared-spammed to everyone"), which as far as we understand is fixed upstream in Dovecot 2.4.4. Debian 13 stable does not yet ship a backported fix, so we are currently working around the issue by not using shared/ACL mailbox access at all, and waiting for an official Debian security update. We would appreciate the community's guidance on a few points: 1. Is a safe, supported upgrade path from 2.4.1 to 2.4.4 recommended for a production instance currently installed from Debian's own package (rather than compiling from source or using a third-party repository)? 2. Are there any breaking changes between 2.4.1 and 2.4.4 we should be aware of - configuration syntax, Maildir index file format compatibility, or anything that would require downtime or re-indexing on a live mail store? 3. Our setup uses SQL-based virtual users/passdb (via PostfixAdmin/MySQL), Sieve filtering, and per-user quotas. Are there any known interactions between these features and the 2.4.4 update that we should test for before rolling it out? 4. Do you have a general recommendation on whether to wait for the Debian security team to backport the fix into 13 stable, versus updating manually ahead of that? Any guidance, or a pointer to relevant release notes/changelog entries between 2.4.1 and 2.4.4, would be very helpful. Thank you, Artem Ignatov IT Administrator, GK INVEST

3 3

Global sieve variables don't work in 2.4.4
by inaugurator＠ya.ru 22 Aug '26

22 Aug '26

Hi everyone! I have created a minimal reproducible setup. First, let's prepare the environment and create the necessary directories: ```shell getent group vmail >/dev/null \ || groupadd -g 500 vmail; \ getent passwd vmail \ | awk -F: '$3 == "500" && $4 == "vmail"' >/dev/null \ || { id vmail >/dev/null 2>&1 && usermod -u 500 -g vmail vmail \ || useradd -u 500 -g vmail -M -s /usr/sbin/nologin vmail; } mkdir -p /mail && chown vmail:vmail -R /mail cat > /mail/global_bug.sieve <<EOF require ["variables", "include"]; global "global_var"; set "global_var" "hello"; EOF cat > /mail/before_bug.sieve <<EOF require ["variables", "include", "vnd.dovecot.debug"]; global "global_var"; include :global :optional "global_bug"; debug_log "\${global_var}"; EOF ``` Then, we configure dovecot.conf: ``` dovecot_config_version = 2.4.4 dovecot_storage_version = 2.4.4 auth_allow_cleartext = yes mail_driver = maildir mail_home = /mail/%{user} mail_inbox_path = .INBOX mail_uid = vmail mail_gid = vmail first_valid_uid = 500 protocols { imap = yes } mail_plugins { imap_sieve = yes } service imap-login { inet_listener imaps { port = 0 } } passdb anypass { driver = static fields { nopassword = yes } } sieve_global_extensions { vnd.dovecot.debug = yes } sieve_script global_bug { driver = file path = /mail/global_bug.sieve type = global } namespace inbox { inbox = yes separator = / mailbox INBOX { auto = subscribe sieve_script before_bug { driver = file path = /mail/before_bug.sieve cause = APPEND type = before } } } ``` If we run an APPEND command to the INBOX directory: ```shell curl -v -u "user1:hello" -k "imap://localhost:143/INBOX" --upload-file /tmp/test.eml ``` the log shows an empty message. ``` imap(user1)<3155434><YNISPNZYHtV/AAAB>: sieve: DEBUG: ``` However, if we change the configuration and the Sieve script by replacing "global" with "personal", I see my hello in debug log: ``` ... sieve_script global_bug { driver = file path = /mail/global_bug.sieve type = personal # !!! } ... require ["variables", "include", "vnd.dovecot.debug"]; global "global_var"; include :personal :optional "global_bug"; # !!! debug_log "\${global_var}"; ... imap(user1)<3155659><iiiIhNZYgpl/AAAB>: sieve: DEBUG: hello ``` Why am I unable to import a global variable into a before script if it is defined in a global script? Thank You in advance!

1 1

Dovecot 2.4: possible bug in quota-status service
by Othmar Truniger 21 Aug '26

21 Aug '26

Hi, I'm testing dovecot 2.4 (2.4.1 on debian trixie) after migrating from 2.3. When checking the quota-status service (quota-status -p postfix) over telnet, the response for new mail over quota returns an empty text for action. Example: # telnet 127.0.0.1 10022 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. recipient=mailtest(a)truniger.ch size=13000000 action= recipient=mailtest(a)truniger.ch size=12000000 action=OK ^] telnet> quit The manual says that an empty value for "quota_status_toolarge" defaults to "quota_status_overquota". But when looking a the actual source code of quote-status.c this does not seem to be the case - the return value is ,\0' for action: Code from line 231: switch (qret) { case QUOTA_ALLOC_RESULT_OK: /* under quota */ value = set->quota_status_success; break; case QUOTA_ALLOC_RESULT_OVER_MAXSIZE: /* even over maximum quota */ case QUOTA_ALLOC_RESULT_OVER_QUOTA_LIMIT: value = set->quota_status_toolarge; if (value[0] == '\0') break; /* fall through */ case QUOTA_ALLOC_RESULT_OVER_QUOTA: case QUOTA_ALLOC_RESULT_OVER_QUOTA_MAILBOX_LIMIT: value = set->quota_status_overquota; break; case QUOTA_ALLOC_RESULT_TEMPFAIL: case QUOTA_ALLOC_RESULT_BACKGROUND_CALC: ret = -1; break; } value = t_strdup(value); settings_free(set); if I'm reading this correctly the value of "value" stays at ,\0' when quota_status_toolarge is equal ,\0'. I can solve the problem by explicitly setting any value for quota_status_toolarge in the configuration. Regards, Othmar Hi, I'm testing dovecot 2.4 (2.4.1 on debian trixie) after migrating from 2.3. When checking the quota-status service (quota-status -p postfix) over telnet, the response for new mail over quota returns an empty text for action. Example: # telnet 127.0.0.1 10022 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. recipient=mailtest(a)truniger.ch size=13000000 action= recipient=mailtest(a)truniger.ch size=12000000 action=OK ^] telnet> quit The manual says that an empty value for "quota_status_toolarge" defaults to "quota_status_overquota". But when looking a the actual source code of quote-status.c this does not seem to be the case - the return value is '\0` for action: Code from line 231: switch (qret) { case QUOTA_ALLOC_RESULT_OK: /* under quota */ value = set->quota_status_success; break; case QUOTA_ALLOC_RESULT_OVER_MAXSIZE: /* even over maximum quota */ case QUOTA_ALLOC_RESULT_OVER_QUOTA_LIMIT: value = set->quota_status_toolarge; if (value[0] == '\0') break; /* fall through */ case QUOTA_ALLOC_RESULT_OVER_QUOTA: case QUOTA_ALLOC_RESULT_OVER_QUOTA_MAILBOX_LIMIT: value = set->quota_status_overquota; break; case QUOTA_ALLOC_RESULT_TEMPFAIL: case QUOTA_ALLOC_RESULT_BACKGROUND_CALC: ret = -1; break; } value = t_strdup(value); settings_free(set); if I'm reading this correctly the value of "value" stays at '\0` when quota_status_toolarge is equal '\0`. I can solve the problem by explicitly setting any value for quota_status_toolarge in the configuration. Regards, Othmar

1 0

[BUG] IMAP hibernation fails on FreeBSD 15.x with "Invalid peer_dev_major value"
by Jordan Ostrev 20 Aug '26

20 Aug '26

Hi, IMAP hibernation compiles and attempts to run on FreeBSD 15.x (tested with Dovecot 2.4.4 and FreeBSD 15.1), but fails at runtime with: plain imap-hibernate: Error: conn unix:imap-hibernate (uid=125): Failed to parse client input: Invalid peer_dev_major value: 18446744073709551615 Jun 24 21:27:08 classic dovecot[36888]: imap-hibernate: Error: conn unix:imap-hibernate (uid=125): Failed to parse client input: Invalid peer_dev_major value: 18446744073709551615 Jun 24 21:27:08 classic dovecot[36888]: imap(jordan(a)ostreff.info)<37120><ExaV/gNVAdt/AAAB>: Error: Couldn't hibernate imap client: /var/run/dovecot/imap-hibernate returned failure: Failed to parse client input: Invalid peer_dev_major value: 18446744073709551615 Root cause: In src/imap/imap-client-hibernate.c, the code serializes peer_dev_major and peer_dev_minor using major() and minor() macros: c str_printfa(cmd, "\tpeer_dev_major=%lu\tpeer_dev_minor=%lu\tpeer_ino=%llu", (unsigned long)major(peer_st.st_dev), (unsigned long)minor(peer_st.st_dev), (unsigned long long)peer_st.st_ino); On FreeBSD, major() and minor() can return UINT64_MAX (18446744073709551615) for file descriptors that are not block/character devices (such as sockets on tmpfs/devfs). This value exceeds UINT_MAX and cannot be parsed by str_to_uint() in imap-master-client.c. Historical context: This was discussed on the Dovecot mailing list in July 2019 (thread: "Hibernation errors") but apparently never resolved upstream. The same failure mode persists in Dovecot 2.4.4. Impact: IMAP hibernation is effectively non-functional on FreeBSD 15.x Processes remain running indefinitely instead of being hibernated Documentation note: The Dovecot 2.4 documentation states that hibernation "is not supported on kqueue based systems currently, such as FreeBSD." However, the code still compiles and attempts to run, producing these errors rather than being disabled at compile time or gracefully skipped at runtime. Would it make sense to either: Disable hibernation at compile time for kqueue systems, or Add validation for major()/minor() return values before serialization? Thanks, Jordan Hi, IMAP hibernation compiles and attempts to run on FreeBSD 15.x (tested with Dovecot 2.4.4 and FreeBSD 15.1), but fails at runtime with: plain imap-hibernate: Error: conn unix:imap-hibernate (uid=125): Failed to parse client input: Invalid peer_dev_major value: 18446744073709551615 Jun 24 21:27:08 classic dovecot[36888]: imap-hibernate: Error: conn unix:imap-hibernate (uid=125): Failed to parse client input: Invalid peer_dev_major value: 18446744073709551615 Jun 24 21:27:08 classic dovecot[36888]: imap(jordan(a)ostreff.info)<37120><ExaV/gNVAdt/AAAB>: Error: Couldn't hibernate imap client: /var/run/dovecot/imap-hibernate returned failure: Failed to parse client input: Invalid peer_dev_major value: 18446744073709551615 Root cause: In src/imap/imap-client-hibernate.c, the code serializes peer_dev_major and peer_dev_minor using major() and minor() macros: c str_printfa(cmd, "\tpeer_dev_major=%lu\tpeer_dev_minor=%lu\tpeer_ino=%llu", (unsigned long)major(peer_st.st_dev), (unsigned long)minor(peer_st.st_dev), (unsigned long long)peer_st.st_ino); On FreeBSD, major() and minor() can return UINT64_MAX (18446744073709551615) for file descriptors that are not block/character devices (such as sockets on tmpfs/devfs). This value exceeds UINT_MAX and cannot be parsed by str_to_uint() in imap-master-client.c. Historical context: This was discussed on the Dovecot mailing list in July 2019 (thread: "Hibernation errors") but apparently never resolved upstream. The same failure mode persists in Dovecot 2.4.4. Impact: o IMAP hibernation is effectively non-functional on FreeBSD 15.x o Processes remain running indefinitely instead of being hibernated Documentation note: The Dovecot 2.4 documentation states that hibernation "is not supported on kqueue based systems currently, such as FreeBSD." However, the code still compiles and attempts to run, producing these errors rather than being disabled at compile time or gracefully skipped at runtime. Would it make sense to either: 1. Disable hibernation at compile time for kqueue systems, or 2. Add validation for major()/minor() return values before serialization? Thanks, Jordan

3 12

IMAP access marking new messages as "old" for mutt
by Marc Haber 19 Aug '26

19 Aug '26

Hi, this might be a stupid question asked by someone who does not know enough about IMAP, but I'm going to tell you my user story anyway: tl;dr: can I keep dovecot from moving all "NEW" message to· "OLD" state when the Mailbox was opened once and nothing actually read? long version: My mail is delivered to a maildir on a machine I also have a shell account on. That Maildir is huge, it holds half a million messages. I usually access it directly with mutt accessing the spool. In the Mailbox, new messages automatically get the N flag and once I have opened it in mutt, I can mark it as "O" (old). I use that flag for messages that still need further work, I usually have a couple of hundred messages in that state. There is also a third state (I would call it "read") that doesnt display any flags in mutt. Occasionally, I need access to an attachment directly on my work box. In the past, I have moved that message to a sub-maildir which I then access with Thunderbird or neomutt via IMAP and dovecot (configured via userdb). I now want to give neomutt direct IMAP access to the BIG mailbox. I am impressed how quickly the neomutt/dovecot acesses this mailbox. However, once I have once opened that mailbox, all messages that had the N flag in the mutt-on-spool lose that flag immediately, replaced by the O flag. That destroys my method of seeing "O" messages as "needs work". Since that happens with both Thunderbird and neomutt when testing, I suspect, this is either mandated by the protocol (which would be a showstopper for me), or a dovecot issue, maybe even a thing that I could configure in dovecot. Hence, my question, can I configure dovecot to move a "NEW" message to "OLD" only if the message was actually READ/body-displayed by an IMAP client? And, if yes, how do I do that. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

2 1

RE: ai dovecot
by Marc 16 Aug '26

16 Aug '26

No I am curious if they use llms, because I am getting more and more impressed by it. I see suggestions referring to RFC compliant code, which I have been missing in quite a few developers working for me. I think if you are full time developer this can be really helpful. Not to mention those news items where software is ported and scanned for vulnerabilities. > > So you'd like the developers to subject their code to LLMs for audit? > What idiocy is that! > > On Sun, Aug 16, 2026 at 1:33 AM Marc <Marc(a)f1-outsourcing.eu > <mailto:Marc@f1-outsourcing.eu> > wrote: > > > > > > > > > I am just a bit curious, are llm's being used to check the > code or > > help in any other way? > > > > > > > > Why does it bother you? > > > > > > > ??? Can't you read? I am curious, not bothered. > > > > > -- > > Best regards, > Odhiambo WASHINGTON, > Nairobi,KE > +254 7 3200 0004/+254 7 2274 3223 > In an Internet failure case, the #1 suspect is a constant: DNS. > "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) > [How to ask smart questions: http://www.catb.org/~esr/faqs/smart- > questions.html]

1 0

mbox - maildir transition using dovecot lmtp local user auth struggles
by "Tóth Attila" 14 Aug '26

14 Aug '26

Approaching age 49 I passed the time long before when I was excited about a new version or a software upgrade. Why poke something that works? From time to time I'm forced to upgrade hardware and software against my will otherwise could serve many more years. I became the victim of mbox -> maildir transition. First I converted the good old Sendmail to Postfix. Initially it still used procmail delivering in mbox mailboxes, now I converted the mboxes to maildir and changed the way of delivery by dovecot lmtp, since that is the software I use for IMAP access. At least there seem to be no data-loss after a couple of doveadm backup and sync retries. There are just 4 local users, so dovecot was set for pam authentication and it worked (for 20+ years, although there were some bumps while upgrading from 2.3 to 2.4 syntax). Now dovecot lmtp started bouncing mails, because it was trying to authenticate a username including the domain name as well and the backend returned unknown user, since expected local user names. This wasn't a problem with mbox/procmail. I asked AI for help and first suggested to use auth_username_format = %Ln. It soon turned out, that this syntax is obsolete. So I dig into it myself and tried auth_username_format = %{user | lower}. It wasn't picked up by dovecot, symptoms persisted. I also tried auth_username_translation = %{user | split('@') | list_first}, which turned out to be also unsuccessful. I also tried to solve the issue on the postfix side by introducing regex handling, but either lmtp_generic_maps = regexp:/etc/postfix/lmtp_generic or recipient_canonical_maps = regexp:/etc/postfix/recipient_canonical had no influence on the symptoms (regex was: /^([^@]+)@atoth\.sote\.hu$/ ${1}). Also tried virtual conversion and lda. Nothing solved the fricking problem. I ended up using a workaround I'm ashamed to share. I kept passdb pam, but for userdb I created a userdb-file, where I included users both with the local name only and the full email address. This shameful concept is functional, but I have to admit it is disappointing: several ways back and forth for solving an issue were all unsuccessful. And it is exhausting. Any ideas appreciated. BR: Dw. -- dr Tóth Attila, Radiológus, 06-20-825-8057 Attila Toth MD, Radiologist, +36-20-825-8057

1 0

Debian 13 Dovecot 2.4.1 LMTP Error Absent ~/sieve
by Conrad T. Pino 14 Aug '26

14 Aug '26

Hello Dovecot List, Our upgrade from Debian 9 Dovecot 2.2.27 to Debian 13 Dovecot 2.4.1 went well. Only recently we added a new mailbox and LMTP delivery failed. Dovecot redacted error from Postfix log: 451 4.2.0 <user@domain> Temporarily unable to access necessary Sieve scripts (in reply to end of DATA command)) Dovecot redacted errors from Dovecot log: dovecot[736]: lmtp(user@domain): Error: sieve: file storage: Performing t_readlink() on active sieve symlink '(null)' failed: readlink() failed: Bad address dovecot[736]: lmtp(user@domain): Error: sieve: Failed to access active Sieve script in parsonal storage 'default': Internal error occurred. Refer to server log for more information. [2026-08-13] (temporary failure) LMTP delivery works after manually creating ~/sieve directory with correct permissions. I know a PostfixAdmin postcreation script can automate directory creation. Have I overlooked Dovecot setting to have Dovecot create ~/sieve directory during LMTP delivery? Best regards, Conrad T. Pino

1 0

ai dovecot
by Marc 14 Aug '26

14 Aug '26

I am just a bit curious, are llm's being used to check the code or help in any other way?

1 0

BUG 2.4 regression: a wrong password over PLAIN is reported as a temporary failure, and the invalid_grant branch is now dead code
by Ihor Rusyn 14 Aug '26

14 Aug '26

Summary With passdb oauth2 doing a password grant, a wrong password makes dovecot answer the IMAP client a NO [UNAVAILABLE] Temporary authentication failure. and log it at Error: level. 2.3 answered AUTHENTICATIONFAILED for the same exchange. PASSDB_RESULT_PASSWORD_MISMATCH is still in db-oauth2.c, but for the password grant it can no longer be reached. Environment Dovecot *2.4.4 (8b687aa65c)*, the official dovecot/dovecot:2.4.4-root image, unmodified. Compared against *2.3.21*. Reproduction Any RFC 6749 compliant authorization server. Point passdb oauth2 at its token endpoint with grant_type=password and attempt an IMAP LOGIN with a wrong password. The server answers, as §5.2 prescribes: HTTP 400 {"error":"invalid_grant","error_description":"Invalid credentials"} *2.3.21:* NO [AUTHENTICATIONFAILED], logged at info level. *2.4.4:* NO [UNAVAILABLE] Temporary authentication failure, logged as auth(user,ip,sasl:plain): Error: oauth2-grant: oauth2 failed: Password grant failed: Invalid credentials imap-login: Login aborted: Logged out (auth service reported temporary failure, 1 attempts in 3 secs) (temp_fail) Cause src/auth/db-oauth2.c is identical in both versions: passdb_result = PASSDB_RESULT_INTERNAL_FAILURE; if (result->error != NULL) error = result->error; else { error = db_oauth2_field_find(result->fields, "error"); if (error == NULL) error = "OAuth2 server returned failure without error field"; else if (strcmp("invalid_grant", error) == 0) passdb_result = PASSDB_RESULT_PASSWORD_MISMATCH; } What changed is what reaches result->error. In *2.3.21*, src/lib-oauth2/oauth2-request.c:113-129 set error only when the JSON *parser* failed. A well-formed error body parsed fine, so error was NULL, res.error stayed NULL, and db-oauth2.c took the else branch, found invalid_grant among the fields and returned PASSWORD_MISMATCH. In *2.4.4*, src/lib-oauth2/oauth2-request.c:136-149 added: /* check if fields contain error now */ const struct oauth2_field *error_field = array_lsearch(&req->fields, "error", request_field_cmp); if (error_field != NULL) { error = error_field->value; /* "invalid_grant" */ /* check for detailed error */ error_field = array_lsearch(&req->fields, "error_description", request_field_cmp); if (error_field != NULL) error = error_field->value; /* overwritten: "Invalid credentials" */ } req->json_parsed_cb(req, error); oauth2_request_continue() then does if (error != NULL) res.error = error;, so result->error is always set on failure and db-oauth2.c never reaches the branch that recognises invalid_grant. The machine-readable code is replaced by the human-readable description before anything can act on it. Note that error_description is *optional* in RFC 6749 §5.2 — so a fully compliant server triggers this simply by being helpful. Omitting it does not help either: error would then hold invalid_grant and still be assigned to res.error, taking the same branch. Why it matters - Mail clients treat [UNAVAILABLE] as a server problem and retry rather than prompting for the password, so users are not told their password is wrong. - Monitoring reads a user error as a service failure — on a farm this is the difference between a quiet log and a page. - RFC 5530 defines AUTHENTICATIONFAILED for a failed authentication and UNAVAILABLE for a temporarily unavailable server. Reporting the former as the latter tells the client something untrue about the server. There is no anti-enumeration benefit in the current behaviour: the same provider response is returned for a wrong password and for a non-existent account, so both are indistinguishable to the client under either mapping. Summary With passdb oauth2 doing a password grant, a wrong password makes dovecot answer the IMAP client a NO [UNAVAILABLE] Temporary authentication failure. and log it at Error: level. 2.3 answered AUTHENTICATIONFAILED for the same exchange. PASSDB_RESULT_PASSWORD_MISMATCH is still in db-oauth2.c, but for the password grant it can no longer be reached. Environment Dovecot 2.4.4 (8b687aa65c), the official dovecot/dovecot:2.4.4-root image, unmodified. Compared against 2.3.21. Reproduction Any RFC 6749 compliant authorization server. Point passdb oauth2 at its token endpoint with grant_type=password and attempt an IMAP LOGIN with a wrong password. The server answers, as S5.2 prescribes: HTTP 400 {"error":"invalid_grant","error_description":"Invalid credentials"} 2.3.21: NO [AUTHENTICATIONFAILED], logged at info level. 2.4.4: NO [UNAVAILABLE] Temporary authentication failure, logged as auth(user,ip,sasl:plain): Error: oauth2-grant: oauth2 failed: Password grant failed: Invalid credentials imap-login: Login aborted: Logged out (auth service reported temporary failure, 1 attempts in 3 secs) (temp_fail) Cause src/auth/db-oauth2.c is identical in both versions: passdb_result = PASSDB_RESULT_INTERNAL_FAILURE; if (result->error != NULL) error = result->error; else { error = db_oauth2_field_find(result->fields, "error"); if (error == NULL) error = "OAuth2 server returned failure without error field"; else if (strcmp("invalid_grant", error) == 0) passdb_result = PASSDB_RESULT_PASSWORD_MISMATCH; } What changed is what reaches result->error. In 2.3.21, src/lib-oauth2/oauth2-request.c:113-129 set error only when the JSON parser failed. A well-formed error body parsed fine, so error was NULL, res.error stayed NULL, and db-oauth2.c took the else branch, found invalid_grant among the fields and returned PASSWORD_MISMATCH. In 2.4.4, src/lib-oauth2/oauth2-request.c:136-149 added: /* check if fields contain error now */ const struct oauth2_field *error_field = array_lsearch(&req->fields, "error", request_field_cmp); if (error_field != NULL) { error = error_field->value; /* "invalid_grant" */ /* check for detailed error */ error_field = array_lsearch(&req->fields, "error_description", request_field_cmp); if (error_field != NULL) error = error_field->value; /* overwritten: "Invalid credentials" */ } req->json_parsed_cb(req, error); oauth2_request_continue() then does if (error != NULL) res.error = error;, so result->error is always set on failure and db-oauth2.c never reaches the branch that recognises invalid_grant. The machine-readable code is replaced by the human-readable description before anything can act on it. Note that error_description is optional in RFC 6749 S5.2 -- so a fully compliant server triggers this simply by being helpful. Omitting it does not help either: error would then hold invalid_grant and still be assigned to res.error, taking the same branch. Why it matters o Mail clients treat [UNAVAILABLE] as a server problem and retry rather than prompting for the password, so users are not told their password is wrong. o Monitoring reads a user error as a service failure -- on a farm this is the difference between a quiet log and a page. o RFC 5530 defines AUTHENTICATIONFAILED for a failed authentication and UNAVAILABLE for a temporarily unavailable server. Reporting the former as the latter tells the client something untrue about the server. There is no anti-enumeration benefit in the current behaviour: the same provider response is returned for a wrong password and for a non-existent account, so both are indistinguishable to the client under either mapping.

1 0

IMAP4rev2: extended LIST drops \Sent, \Drafts, \Trash and \Junk unless the client sends the RFC 6154 return option that IMAP4rev2 does not define
by dennis＠dennisameling.com 14 Aug '26

14 Aug '26

SYSTEM INFORMATION ================== Dovecot version: 2.4.4 (8b687aa65c), Pigeonhole 2.4.4 (3beb331a) OS: Linux 6.12.76-linuxkit aarch64, Debian 13.5 (official dovecot/dovecot:2.4.4 container image, digest sha256:723e3392fe16c6fad8ddc605ea767cc01b4bad 9cd9f13eb1dbac15e79c89b2d4) Host: Docker 29.6.2 (linux/arm64) on macOS 26, Apple silicon CPU architecture: aarch64 (arm64) Filesystem: Docker named volume (overlay2) inside the Docker Desktop VM. Not NFS. Feature: experimental IMAP4rev2 (imap4rev2_enable, mail_utf8_extensions) Client: our own IMAP client library (Rust), but reproduced below with openssl s_client so that no client code is involved The configuration is the image's own /etc/dovecot/dovecot.conf, unmodified: nothing of ours is in it. Rather than paste 200 lines of your own defaults, "doveconf -n" for it is docker run --rm --entrypoint doveconf dovecot/dovecot:2.4.4 -n and we will gladly send the output if you would prefer it inline. The three settings that bear on this report are imap4rev2_enable = yes, mail_utf8_extensions = yes and mailbox_list_utf8 = yes, all three of which the image sets itself. SUMMARY ======= In an IMAP4rev2 session, an extended LIST (one carrying any RETURN (...) clause) omits the special-use mailbox attributes unless the client also sends RETURN (SPECIAL-USE). IMAP4rev2 folded those attributes into the base protocol and defines no SPECIAL-USE return option, so a client that implements only RFC 9051 has no defined way to ask for them, and therefore cannot obtain them from any extended LIST at all. The practical effect for such a client is that every folder loses its role the moment the client asks for anything else -- in our case RETURN (STATUS (UNSEEN)), to fetch unread counts in the same round trip. It cannot find the \Sent folder to place a copy of a sent message in, cannot find \Trash to move a deleted message to, and renders the mailbox list without role icons or ordering. We are not asking for a workaround: we already send RETURN (SPECIAL-USE) on both dialects, since Dovecot advertises the SPECIAL-USE capability in a rev2 session too. This report is about what a strictly RFC 9051 client is able to do. That decision in our client is here, in case it is of interest -- the comment above it records what we found on your server: https://github.com/allodia-eu/email-calendar-sync-engine/blob/fa85b88121132… REPRODUCTION ============ No configuration is required. dovecot/dovecot:2.4.4 ships imap4rev2_enable = yes and mail_utf8_extensions = yes in its own /etc/dovecot/dovecot.conf, and its "@mailbox_defaults = english" creates Drafts/Junk/Sent/Trash with special-use attributes. docker run -d --name dovecot-stock -p 127.0.0.1:11999:31993 \ -e USER_PASSWORD=stock-test-pw \ dovecot/dovecot:2.4.4 { printf 'a1 LOGIN alice(a)example.com stock-test-pw\r\n'; sleep 2; printf 'a2 ENABLE IMAP4rev2\r\n'; sleep 1; printf 'a3 LIST "" "*"\r\n'; sleep 1; printf 'a4 LIST "" "*" RETURN (STATUS (UNSEEN))\r\n'; sleep 1; printf 'a5 LIST "" "*" RETURN (SPECIAL-USE STATUS (UNSEEN))\r\n'; sleep 1; printf 'a6 LOGOUT\r\n'; sleep 1; } \ | openssl s_client -connect 127.0.0.1:11999 -quiet TRANSCRIPT ========== Verbatim; the greeting and the CAPABILITY lines are elided. S: * ENABLED IMAP4REV2 S: a2 OK Enabled (0.001 + 0.000 secs). C: a3 LIST "" "*" S: * LIST (\HasNoChildren \Drafts) "/" Drafts S: * LIST (\HasNoChildren \Junk) "/" Junk S: * LIST (\HasNoChildren \Sent) "/" Sent S: * LIST (\HasNoChildren \Trash) "/" Trash S: * LIST (\HasNoChildren) "/" INBOX S: a3 OK List completed (0.001 + 0.000 secs). --> correct: the role attributes are present C: a4 LIST "" "*" RETURN (STATUS (UNSEEN)) S: * LIST () "/" Drafts S: * STATUS Drafts (UNSEEN 0) S: * LIST () "/" Junk S: * STATUS Junk (UNSEEN 0) S: * LIST () "/" Sent S: * STATUS Sent (UNSEEN 0) S: * LIST () "/" Trash S: * STATUS Trash (UNSEEN 0) S: * LIST () "/" INBOX S: * STATUS INBOX (UNSEEN 0) S: a4 OK List completed (0.034 + 0.000 + 0.033 secs). --> the problem: every role attribute is gone, and IMAP4rev2 gives the client no option to ask for them back C: a5 LIST "" "*" RETURN (SPECIAL-USE STATUS (UNSEEN)) S: * LIST (\Trash) "/" Trash S: * STATUS Trash (UNSEEN 0) S: * LIST (\Sent) "/" Sent S: * STATUS Sent (UNSEEN 0) S: * LIST (\Junk) "/" Junk S: * STATUS Junk (UNSEEN 0) S: * LIST (\Drafts) "/" Drafts S: * STATUS Drafts (UNSEEN 0) S: * LIST () "/" INBOX S: * STATUS INBOX (UNSEEN 0) S: a5 OK List completed (0.002 + 0.000 + 0.001 secs). --> present again, but only via the RFC 6154 return option, which RFC 9051 does not define WHY WE BELIEVE a4 IS NOT CORRECT FOR IMAP4rev2 ============================================== 1. RFC 9051 section 7.3.1 makes the special-use attributes ordinary LIST mailbox attributes: "In addition to the base mailbox name attributes defined above, an IMAP server MAY also include any or all of the following attributes that denote 'role' (or 'special-use') of a mailbox. These attributes are included along with base attributes defined above." Appendix E item 2 lists "the list of new mailbox attributes from SPECIAL-USE [RFC6154]" among what IMAP4rev2 folded in. 2. RFC 9051 section 6.3.9.2 defines the return options for IMAP4rev2 as exactly SUBSCRIBED, CHILDREN and STATUS. There is no SPECIAL-USE return option. Nor is SPECIAL-USE among the selection options in section 6.3.9.1, which are SUBSCRIBED, REMOTE and RECURSIVEMATCH; it survives in RFC 9051 only as an unexplained C: A002 LIST (SPECIAL-USE) "" "*" in the NAMESPACE examples in section 6.3.10, which may itself be worth an erratum. 3. Section 6.3.9 says "a client MUST NOT send an option for which the server has not advertised support", so a strictly rev2 client will not invent one. Taken together, an RFC 9051-only client can obtain the role attributes on a basic LIST but never on an extended one, which means it cannot combine roles with RETURN (STATUS ...) -- the single round trip that RFC 5819 exists to provide. Since RFC 9051 section 6.3.9 also states that return options "MUST NOT cause the server to report information about additional mailbox names", but says nothing about removing base attributes, we read a4 as a case where an attribute defined as base data is being withheld. Note the contrast with \HasNoChildren in the same transcript: it also disappears in a4, but CHILDREN is a return option in RFC 9051, so a rev2 client can ask for it back. For special-use there is no equivalent. WHAT WE BELIEVE CORRECT BEHAVIOUR WOULD BE ========================================== In a session where IMAP4rev2 has been ENABLEd, include the special-use attributes in extended LIST responses without requiring RETURN (SPECIAL-USE) -- that is, treat them as the base mailbox attributes that RFC 9051 section 7.3.1 defines them to be. The RFC 6154 return option would remain accepted for IMAP4rev1 sessions. NOTE ON IMAP4rev1: WE BELIEVE THAT BEHAVIOUR IS CORRECT ======================================================= The same server on an IMAP4rev1 session behaves identically, and there we read it as compliant. RFC 6154 section 2 says "The extended LIST command MAY return SPECIAL-USE attributes even if the client does not specify the return option", and MAY is not MUST. This report concerns only IMAP4rev2 sessions, where the way to ask was removed along with the need to. CONTACT ======= Happy to test a patch. The reproduction is a single "docker run", and we keep both an IMAP4rev1 and an IMAP4rev2 Dovecot fixture in our CI, so a fix can be regression-tested on both dialects.

2 1

Request for official Dovecot 2.4 RPMs for Amazon Linux 2023
by Yashar Fakhari 14 Aug '26

14 Aug '26

Hello Dovecot team, Would you consider providing official Dovecot 2.4 RPMs for Amazon Linux 2023 on both x86_64 and aarch64? I needed Dovecot 2.4 for FTS Flatcurve because Amazon Linux 2023 currently provides Dovecot 2.3 without a Flatcurve package, while the standalone Flatcurve project for 2.3 is EOL and development has moved into Dovecot core. I have developed a working experimental build process, and I hope the lessons from it could help make Amazon Linux 2023 easier to add to your release workflow: The entire build runs through GitHub Actions using Amazon Linux 2023 containers. GitHub repo: https://github.com/YasharF/dovecot.2.4.ALinux2023 Workflow files .github/workflow:- watch.yml monitors Dovecot's RPM repository for new releases.- build.yml, using build/build.sh, rebuilds the RPMs for both architectures with two documented spec adjustments.- verify.yml runs basic verification tests.- publish.yml publishes verified artifacts as a DNF-compatible repository. I am currently using the resulting RPMs in production. This project is intended only as a temporary bridge until AWS or Dovecot provides official packages. Official, continuously updated Dovecot packages would remain valuable even if AWS later adopts a newer release. As a distribution, AWS/Amazon Linux may freeze the packaged version and provide primarily security fixes rather than each subsequent Dovecot feature and bug-fix release. Thank you for considering this. Let me know if I can contribute in any other way for this. Best regards, Yashar Fakharihttps://github.com/YasharFhttps://linkedin.com/in/YasharF Hello Dovecot team, Would you consider providing official Dovecot 2.4 RPMs for Amazon Linux 2023 on both x86_64 and aarch64? I needed Dovecot 2.4 for FTS Flatcurve because Amazon Linux 2023 currently provides Dovecot 2.3 without a Flatcurve package, while the standalone Flatcurve project for 2.3 is EOL and development has moved into Dovecot core. I have developed a working experimental build process, and I hope the lessons from it could help make Amazon Linux 2023 easier to add to your release workflow: The entire build runs through GitHub Actions using Amazon Linux 2023 containers. GitHub repo: https://github.com/YasharF/dovecot.2.4.ALinux2023 Workflow files .github/workflow: - watch.yml monitors Dovecot's RPM repository for new releases. - build.yml, using build/build.sh, rebuilds the RPMs for both architectures with two documented spec adjustments. - verify.yml runs basic verification tests. - publish.yml publishes verified artifacts as a DNF-compatible repository. I am currently using the resulting RPMs in production. This project is intended only as a temporary bridge until AWS or Dovecot provides official packages. Official, continuously updated Dovecot packages would remain valuable even if AWS later adopts a newer release. As a distribution, AWS/Amazon Linux may freeze the packaged version and provide primarily security fixes rather than each subsequent Dovecot feature and bug-fix release. Thank you for considering this. Let me know if I can contribute in any other way for this. Best regards, Yashar Fakhari https://github.com/YasharF https://linkedin.com/in/YasharF

2 1

fts-flatcurve 2.4.4: after "doveadm fts optimize" a mailbox stops indexing new mail (empty current.<id> shard, missing iamglass)
by Ihor Rusyn 13 Aug '26

13 Aug '26

Hello, "doveadm fts optimize" leaves the mailbox in a state where no new mail can be indexed. The existing index survives and searches over already-indexed mail keep working, so the damage is invisible until the next message arrives. Version: 2.4.4 (8b687aa65c), packaged in a container image FTS: fts_flatcurve, substring_search = yes, min_term_size default (2) fts_autoindex = yes, fts_search_add_missing = yes Index store: NFSv3 (rsize/wsize 32768, local_lock=none) Mail store: NFSv3, maildir Reproduction ------------ 1) Starting point: a healthy index. # doveadm fts flatcurve check -u user(a)example.com INBOX INBOX guid=88885837bb33136365390000d09efc50 errors=0 shards=1 # ls /indexes/.../.INBOX/fts-flatcurve/*/ current.1786117302443530: flintlock iamglass postlist.glass termlist.glass # doveadm search -u user(a)example.com mailbox INBOX text a | tail -1 88885837bb33136365390000d09efc50 58 2) Optimize. Exits 0, prints nothing. # doveadm fts optimize -u user(a)example.com # echo $? 0 3) State afterwards: the compacted data is in a new index.<n> directory, and the pre-existing current.<id> directory is still present but EMPTY. # ls /indexes/.../.INBOX/fts-flatcurve/*/ current.1786117302443530: index.1464: flintlock iamglass postlist.glass termlist.glass # ls -ld .../fts-flatcurve/current.1786117302443530 drwx------ 2 dovecot dovecot 4096 Aug 7 16:08 .../current.1786117302443530 # doveadm fts flatcurve check -u user(a)example.com INBOX Error: fts-flatcurve(INBOX): Cannot open DB (RO; current.1786117302443530); DatabaseNotFoundError: Couldn't detect type of database Error: fts-flatcurve(INBOX): Check failed; DatabaseOpeningError: Directory does not contain a Xapian database Searching already-indexed mail still works at this point: # doveadm search -u user(a)example.com mailbox INBOX text a | tail -1 88885837bb33136365390000d09efc50 58 4) Deliver one message and index it. This is where it breaks: # printf 'From: a(a)b.c\nSubject: reproprobe\n\nbody\n' \ | doveadm save -u user(a)example.com -m INBOX Info: Mailbox INBOX: save: box=INBOX, uid=59, subject=reproprobe # doveadm index -u user(a)example.com INBOX Error: fts-flatcurve(INBOX): Cannot open DB (RW, current.1786117302443530): .../current.1786117302443530/iamglass: Failed to open glass revision file for reading (No such file or directory) Error: cmd index: Mailbox INBOX: Precache for UID=59 failed: Internal error 5) From now on SEARCH fails too, because fts_search_add_missing makes it index first: # doveadm search -u user(a)example.com mailbox INBOX text reproprobe Error: Mailbox INBOX: indexer failed to index mailbox Error: cmd search: Searching mailbox INBOX failed: Internal error occurred. Over IMAP the client sees: NO [SERVERBUG] Internal error occurred. It does not recover by itself ----------------------------- "doveadm index" and autoindexing both take the same write path and fail the same way. "doveadm fts rescan" does not help either -- it also cannot open the empty shard. The only repair we found is to delete the folder's fts-flatcurve directory and index the folder again. Impact ------ A quiet mailbox looks fine for as long as nothing is delivered to it, so this can sit unnoticed. We found it because a monitoring mailbox that receives one message per minute started returning SERVERBUG on SEARCH. In our case a maintenance run that called "doveadm fts optimize" per mailbox left 114 mailboxes in this state, which is all of the ones that had any mail. Possible cause (not verified) ----------------------------- In fts_flatcurve_xapian_optimize_box_do() every shard is first opened for writing ("We need to lock all of the mailboxes so nothing changes while we are optimizing"), and the old current.*/index.* directories are then deleted from disk while those write handles are still open. A handle that is closed afterwards appears to recreate its directory without a glass revision file, which matches what is left behind. Also, in the same function the result of fts_flatcurve_xapian_rename_db(backend, dbpath, NULL, error_r) is discarded: rename_db() does not update the path it is given and returns the new path only through newpath_r, which is NULL at this call site. I have not tried to confirm either of these beyond reading the code. Not the same as the known root-owned iamglass report ---------------------------------------------------- There is an older report where "doveadm fts optimize -A" run from cron as root left iamglass owned by root, producing the same error string. That is not this: here the directories are owned by the mail user (dovecot:dovecot, 0700) and the revision file does not exist at all. -- Best regards, Ihor Rusyn Hello, "doveadm fts optimize" leaves the mailbox in a state where no new mail can be indexed. The existing index survives and searches over already-indexed mail keep working, so the damage is invisible until the next message arrives. Version: 2.4.4 (8b687aa65c), packaged in a container image FTS: fts_flatcurve, substring_search = yes, min_term_size default (2) fts_autoindex = yes, fts_search_add_missing = yes Index store: NFSv3 (rsize/wsize 32768, local_lock=none) Mail store: NFSv3, maildir Reproduction ------------ 1) Starting point: a healthy index. # doveadm fts flatcurve check -u [1]user(a)example.com INBOX INBOX guid=88885837bb33136365390000d09efc50 errors=0 shards=1 # ls /indexes/.../.INBOX/fts-flatcurve/*/ current.1786117302443530: flintlock iamglass postlist.glass termlist.glass # doveadm search -u [2]user(a)example.com mailbox INBOX text a | tail -1 88885837bb33136365390000d09efc50 58 2) Optimize. Exits 0, prints nothing. # doveadm fts optimize -u [3]user(a)example.com # echo $? 0 3) State afterwards: the compacted data is in a new index.<n> directory, and the pre-existing current.<id> directory is still present but EMPTY. # ls /indexes/.../.INBOX/fts-flatcurve/*/ current.1786117302443530: index.1464: flintlock iamglass postlist.glass termlist.glass # ls -ld .../fts-flatcurve/current.1786117302443530 drwx------ 2 dovecot dovecot 4096 Aug 7 16:08 .../current.1786117302443530 # doveadm fts flatcurve check -u [4]user(a)example.com INBOX Error: fts-flatcurve(INBOX): Cannot open DB (RO; current.1786117302443530); DatabaseNotFoundError: Couldn't detect type of database Error: fts-flatcurve(INBOX): Check failed; DatabaseOpeningError: Directory does not contain a Xapian database Searching already-indexed mail still works at this point: # doveadm search -u [5]user(a)example.com mailbox INBOX text a | tail -1 88885837bb33136365390000d09efc50 58 4) Deliver one message and index it. This is where it breaks: # printf 'From: a(a)b.c\nSubject: reproprobe\n\nbody\n' \ | doveadm save -u [6]user(a)example.com -m INBOX Info: Mailbox INBOX: save: box=INBOX, uid=59, subject=reproprobe # doveadm index -u [7]user(a)example.com INBOX Error: fts-flatcurve(INBOX): Cannot open DB (RW, current.1786117302443530): .../current.1786117302443530/iamglass: Failed to open glass revision file for reading (No such file or directory) Error: cmd index: Mailbox INBOX: Precache for UID=59 failed: Internal error 5) From now on SEARCH fails too, because fts_search_add_missing makes it index first: # doveadm search -u [8]user(a)example.com mailbox INBOX text reproprobe Error: Mailbox INBOX: indexer failed to index mailbox Error: cmd search: Searching mailbox INBOX failed: Internal error occurred. Over IMAP the client sees: NO [SERVERBUG] Internal error occurred. It does not recover by itself ----------------------------- "doveadm index" and autoindexing both take the same write path and fail the same way. "doveadm fts rescan" does not help either -- it also cannot open the empty shard. The only repair we found is to delete the folder's fts-flatcurve directory and index the folder again. Impact ------ A quiet mailbox looks fine for as long as nothing is delivered to it, so this can sit unnoticed. We found it because a monitoring mailbox that receives one message per minute started returning SERVERBUG on SEARCH. In our case a maintenance run that called "doveadm fts optimize" per mailbox left 114 mailboxes in this state, which is all of the ones that had any mail. Possible cause (not verified) ----------------------------- In fts_flatcurve_xapian_optimize_box_do() every shard is first opened for writing ("We need to lock all of the mailboxes so nothing changes while we are optimizing"), and the old current.*/index.* directories are then deleted from disk while those write handles are still open. A handle that is closed afterwards appears to recreate its directory without a glass revision file, which matches what is left behind. Also, in the same function the result of fts_flatcurve_xapian_rename_db(backend, dbpath, NULL, error_r) is discarded: rename_db() does not update the path it is given and returns the new path only through newpath_r, which is NULL at this call site. I have not tried to confirm either of these beyond reading the code. Not the same as the known root-owned iamglass report ---------------------------------------------------- There is an older report where "doveadm fts optimize -A" run from cron as root left iamglass owned by root, producing the same error string. That is not this: here the directories are owned by the mail user (dovecot:dovecot, 0700) and the revision file does not exist at all. -- Best regards, Ihor Rusyn References Visible links 1. mailto:user@example.com 2. mailto:user@example.com 3. mailto:user@example.com 4. mailto:user@example.com 5. mailto:user@example.com 6. mailto:user@example.com 7. mailto:user@example.com 8. mailto:user@example.com

4 6

Reports to this list held twice for message size — please release them from moderation
by Ihor Rusyn 11 Aug '26

11 Aug '26

Hello, I have twice tried to send a bug report to this list, and both times the message was blocked for exceeding the size limit with error "The message is larger than the 40 KB maximum size" The report is long because it is meant to be actionable: environment details, exact reproduction steps, log excerpts and strace output. That is the material a maintainer asks for first — and it is exactly what the size limit rejects. If this list is where technical reports belong, a limit that blocks them works against its purpose. Could you please release both of my held messages from moderation and reply on the thread? If long reports are not wanted here, I would appreciate a pointer to where they should go instead. The subject of email was «2.4.4 fts-flatcurve: fts optimize silently destroys a folder's index when the index is on NFS», sent on today from this address. -- Best regards, Ihor Ru Hello, I have twice tried to send a bug report to this list, and both times the message was blocked for exceeding the size limit with error "The message is larger than the 40 KB maximum size" The report is long because it is meant to be actionable: environment details, exact reproduction steps, log excerpts and strace output. That is the material a maintainer asks for first -- and it is exactly what the size limit rejects. If this list is where technical reports belong, a limit that blocks them works against its purpose. Could you please release both of my held messages from moderation and reply on the thread? If long reports are not wanted here, I would appreciate a pointer to where they should go instead. The subject of email was <<2.4.4 fts-flatcurve: fts optimize silently destroys a folder's index when the index is on NFS>>, sent on today from this address. -- Best regards, Ihor Ru

3 2

2.4.4 fts-flatcurve: fts optimize silently destroys a folder's index when the index is on NFS
by Ihor Rusyn 11 Aug '26

11 Aug '26

Hello, Summary ======= On Dovecot 2.4.4 with fts_flatcurve and mail_index_path on NFS, "doveadm fts optimize" leaves behind an empty shard directory. That directory remains the shard every subsequent write opens, so from that point on the folder can no longer index new mail. The operation reports success and logs nothing at the time. The damage is permanent and, on a folder that receives no new mail, invisible. Two separate defects are involved, and both are reported below: (1) fts optimize deletes a shard directory whose files it still holds open. On a local filesystem the unlink succeeds invisibly; NFS cannot express "unlink but keep open" and silly-renames instead, so the directory survives. (2) unlink_directory() reports success when rmdir() failed, which is what makes (1) silent rather than loud. Environment =========== Dovecot 2.4.4 CE (8b687aa65c) container image sha256:d6b2f80db2e656a9250583712a82397e2752b35ad7e4e2e71c85fdc0d510137d base Debian 13 trixie fts_flatcurve (Xapian glass) libxapian30 1.4.29-3 (libxapian.so.30.14.1) substring_search = yes, min_term_size = 2 optimize_limit at its default of 10 dovecot_storage_version = 2.3.0 mail_index_path on NFSv3; mail storage on a separate NFS export NFS client is the host, not the container: Debian 12 bookworm, kernel 6.1.0-51-amd64 x86_64 nfs-common 1:2.6.2-4+deb12u1 mount options: rw,noatime,vers=3,rsize=32768,wsize=32768,hard, nordirplus,proto=tcp,timeo=600,retrans=2,sec=sys, local_lock=none Impact ====== An operator does not have to invoke optimize to be exposed: with the default optimize_limit = 10, flatcurve runs it itself once a folder accumulates ten shards. Every active folder therefore reaches this eventually. Already-indexed mail stays searchable, so the folder looks healthy. Only indexing of new mail fails. With fts_search_add_missing = yes, the first SEARCH after new mail arrives attempts to index it, fails, and the client receives NO [SERVERBUG]. I hit this while migrating a host from 2.3 to 2.4: 114 mailboxes were left in this state in a single run, and it surfaced only because a monitoring mailbox began answering SERVERBUG. Defect 1: fts optimize leaves an empty shard directory on NFS ============================================================= Steps to reproduce ------------------ 1. Configure fts_flatcurve with the index path on an NFSv3 mount. 2. Take a mailbox with mail in INBOX (a few hundred messages is enough) and build the index: doveadm index -u <user> INBOX Confirm one shard exists: ls <index>/.INBOX/fts-flatcurve/ -> current.<id> 3. Run: doveadm fts optimize -u <user> INBOX (Alternatively, let it fire on its own by driving the folder past optimize_limit shards.) 4. While it runs, list the shard directory repeatedly - .nfsXXXX entries appear inside current.<id>. 5. After it finishes, note the exit status is 0 and no error was logged. List the directory again: index.<n> was created as expected, and current.<id> is still there, now empty. 6. Deliver one new message, then: doveadm index -u <user> INBOX Expected vs actual ------------------ Expected: after optimize, only the compacted index.<n> remains, and subsequent indexing writes to a new shard. Actual: the stale empty current.<id> remains and is reopened for writing, so step 6 fails: Cannot open DB (RW, current.<id>): .../current.<id>/iamglass: Failed to open glass revision file for reading (No such file or directory) cmd index: Mailbox INBOX: Precache for UID=59 failed and IMAP SEARCH on that folder returns NO [SERVERBUG]. What I observed while diagnosing -------------------------------- strace of "doveadm fts optimize" on NFSv3 shows the old shard's files being unlinked while handles on them are still open, so the directory cannot be removed: unlink(...) = 0 (x7, every file in the shard) rmdir(...) = -1 ENOTEMPTY (Directory not empty) rename(...) = 0 (optimize -> index.N, proceeds regardless) Once the process exits, the NFS client reaps the .nfsXXXX files and the directory is simply empty. What does not help ------------------ NFSv4.1, mounting with nolock, "doveadm fts rescan", "doveadm index", and full re-indexing all take the same write path into the same empty shard and fail identically. Removing the empty directory (or the folder's whole fts-flatcurve tree) and re-indexing restores the folder; setting optimize_limit = 0 avoids the situation but leaves the index spread across many shards. Defect 2: unlink_directory() returns success when rmdir() failed ================================================================ The ENOTEMPTY above never reaches the caller. unlink_directory() in src/lib/unlink-directory.c returns 1 when the final rmdir() fails, the same value it returns on success: if (rmdir(dir) < 0 && errno != ENOENT) { *error_r = t_strdup_printf("rmdir(%s) failed: %m", dir); return errno == ENOENT ? 0 : 1; } The "errno != ENOENT" guard already establishes that errno is not ENOENT, so the ternary always yields 1. Callers cannot distinguish "directory removed" from "directory still there", and the error message it composed is discarded. Any condition that makes rmdir() fail with something other than ENOENT reproduces this, so the return value is wrong independently of NFS - every caller of unlink_directory() is affected. The code path is unchanged in current main. -- Best regards, Ihor Ru Hello, Summary ======= On Dovecot 2.4.4 with fts_flatcurve and mail_index_path on NFS, "doveadm fts optimize" leaves behind an empty shard directory. That directory remains the shard every subsequent write opens, so from that point on the folder can no longer index new mail. The operation reports success and logs nothing at the time. The damage is permanent and, on a folder that receives no new mail, invisible. Two separate defects are involved, and both are reported below: (1) fts optimize deletes a shard directory whose files it still holds open. On a local filesystem the unlink succeeds invisibly; NFS cannot express "unlink but keep open" and silly-renames instead, so the directory survives. (2) unlink_directory() reports success when rmdir() failed, which is what makes (1) silent rather than loud. Environment =========== Dovecot 2.4.4 CE (8b687aa65c) container image sha256:d6b2f80db2e656a9250583712a82397e2752b35ad7e4e2e71c85fdc0d510137d base Debian 13 trixie fts_flatcurve (Xapian glass) libxapian30 1.4.29-3 (libxapian.so.30.14.1) substring_search = yes, min_term_size = 2 optimize_limit at its default of 10 dovecot_storage_version = 2.3.0 mail_index_path on NFSv3; mail storage on a separate NFS export NFS client is the host, not the container: Debian 12 bookworm, kernel 6.1.0-51-amd64 x86_64 nfs-common 1:2.6.2-4+deb12u1 mount options: rw,noatime,vers=3,rsize=32768,wsize=32768,hard, nordirplus,proto=tcp,timeo=600,retrans=2,sec=sys, local_lock=none Impact ====== An operator does not have to invoke optimize to be exposed: with the default optimize_limit = 10, flatcurve runs it itself once a folder accumulates ten shards. Every active folder therefore reaches this eventually. Already-indexed mail stays searchable, so the folder looks healthy. Only indexing of new mail fails. With fts_search_add_missing = yes, the first SEARCH after new mail arrives attempts to index it, fails, and the client receives NO [SERVERBUG]. I hit this while migrating a host from 2.3 to 2.4: 114 mailboxes were left in this state in a single run, and it surfaced only because a monitoring mailbox began answering SERVERBUG. Defect 1: fts optimize leaves an empty shard directory on NFS ============================================================= Steps to reproduce ------------------ 1. Configure fts_flatcurve with the index path on an NFSv3 mount. 2. Take a mailbox with mail in INBOX (a few hundred messages is enough) and build the index: doveadm index -u <user> INBOX Confirm one shard exists: ls <index>/.INBOX/fts-flatcurve/ -> current.<id> 3. Run: doveadm fts optimize -u <user> INBOX (Alternatively, let it fire on its own by driving the folder past optimize_limit shards.) 4. While it runs, list the shard directory repeatedly - .nfsXXXX entries appear inside current.<id>. 5. After it finishes, note the exit status is 0 and no error was logged. List the directory again: index.<n> was created as expected, and current.<id> is still there, now empty. 6. Deliver one new message, then: doveadm index -u <user> INBOX Expected vs actual ------------------ Expected: after optimize, only the compacted index.<n> remains, and subsequent indexing writes to a new shard. Actual: the stale empty current.<id> remains and is reopened for writing, so step 6 fails: Cannot open DB (RW, current.<id>): .../current.<id>/iamglass: Failed to open glass revision file for reading (No such file or directory) cmd index: Mailbox INBOX: Precache for UID=59 failed and IMAP SEARCH on that folder returns NO [SERVERBUG]. What I observed while diagnosing -------------------------------- strace of "doveadm fts optimize" on NFSv3 shows the old shard's files being unlinked while handles on them are still open, so the directory cannot be removed: unlink(...) = 0 (x7, every file in the shard) rmdir(...) = -1 ENOTEMPTY (Directory not empty) rename(...) = 0 (optimize -> index.N, proceeds regardless) Once the process exits, the NFS client reaps the .nfsXXXX files and the directory is simply empty. What does not help ------------------ NFSv4.1, mounting with nolock, "doveadm fts rescan", "doveadm index", and full re-indexing all take the same write path into the same empty shard and fail identically. Removing the empty directory (or the folder's whole fts-flatcurve tree) and re-indexing restores the folder; setting optimize_limit = 0 avoids the situation but leaves the index spread across many shards. Defect 2: unlink_directory() returns success when rmdir() failed ================================================================ The ENOTEMPTY above never reaches the caller. unlink_directory() in src/lib/unlink-directory.c returns 1 when the final rmdir() fails, the same value it returns on success: if (rmdir(dir) < 0 && errno != ENOENT) { *error_r = t_strdup_printf("rmdir(%s) failed: %m", dir); return errno == ENOENT ? 0 : 1; } The "errno != ENOENT" guard already establishes that errno is not ENOENT, so the ternary always yields 1. Callers cannot distinguish "directory removed" from "directory still there", and the error message it composed is discarded. Any condition that makes rmdir() fail with something other than ENOENT reproduces this, so the return value is wrong independently of NFS - every caller of unlink_directory() is affected. The code path is unchanged in current main. -- Best regards, Ihor Ru

1 0

Tribulations trying to pin-down viable sieve script constraints in connection with imap events.
by sjh_dovecot_org＠shic.co.uk 10 Aug '26

10 Aug '26

Hi Dovecot experts... I've recently started what I expected to be a tiny project to migrate from a legacy ad-hoc procmail by embracing Sieve scripting. I have two different frustrations - depending upon which approach I adopt to trigger spam-training actions. *Option 1*: Trigger actions when messages are moved to/from Spam folder. This mostly works... but has has a niggle I can't see how to overcome. I don't have only one 'Spam' folder - I have a hierarchy of folders - with names like "Spam.2026.July" and "Spam.Unsubscribed.2023". My 'learn ham' sieve script uses "imap.mailbox" from environment to determine if the email is being moved out of the Spam hierarchy. This works well. Unfortunately, when triggering 'learn spam' - the value of imap.mailbox is always the destination mailbox 'Spam' - not the source mailbox from which the spammy email has been moved. I can't see any way to trigger a spam reporting action, within Sieve scripts, if (and only if) a message is moved from a folder that does not have a name matching 'Spam.*' into the folder 'Spam'. This restriction is required so that adjustments to filed spam messages do not result in a single email being wrongly presented multiple times for learning as a spam example. This multiple reporting might otherwise happen if, for example, a message was moved between 'Spam' and 'Spam.2025.July" ; "Spam.2025.August" and "Spam.ForReview.2025" several times. Have I overlooked a reliable way to determine the source folder, in a Sieve script, when a message is moved (copied) to the Spam folder? *Option 2*: Trigger actions when the Thunderbird 'Junk' and 'Not Junk' buttons are pressed I accept it would be preferable to avoid depending upon client-specific flags... but I do expect Thunderbird to be the mail client... and marking messages as Junk/Spam in Thunderbird does promise a neat user interface experience. I've read RFC 6785 (also RFC 5228 and RFC 5232). I understand that the "imap.changedflags" environment value is set both when flags have been added and when removed... and that it is expected that hasflag should be used to determine if the imap.changedflag flag was added or removed. This makes perfect sense, in principle... but the actual behaviour I see is peculiar. With a sieve script /var/dovecot-sieve/scripts/flags_changed.sieve (compiled with sievec) like this: require ["environment", "imap4flags", "imapsieve", "variables", "vnd.dovecot.debug"]; if header :matches "subject" "*" { debug_log "FLAG-EMAIL Subject: ${1}"; } if environment :matches "imap.changedflags" "*" { debug_log "FLAG-EMAIL changedflags : ${1}"; } if hasflag :matches "*" { debug_log "FLAG-EMAIL hasflag : ${1}"; } and configuration in /etc/dovecot/conf.d/90-sieve.conf like this (N.B. user sieve script does not interact with flags... type=after and type=before behave similarly): sieve_script flags_changed { type = after cause = flag path = /var/dovecot-sieve/scripts/flags_changed.sieve } I experimented with the "Junk" and "Not Junk" buttons for an email with a distinctive subject. The following nested bullet-list summarises the values I found for various scenarios. My experiment followed this order of scenarios - there should have been no flag changes, for the email in question, between each of the scenarios in the test sequence. * Scenario 1 - Fresh, not-deterimed-to-be-spam email arrives in Inbox... - Sieve script invocation 1 * imap.changedflags => NonJunk * hasflag => NonJunk - Notes: As expected. * Scenario 2 - Same email is marked as read by Thunderbird after it has been displayed onscreen for a while... - Sieve script invocation 2 * imap.changedflags => \Seen * hasflag => \seen - Notes: Flags are case insensitive - but odd lower case distinction. What happened to NonJunk flag from Scenario 1? * Scenario 3 - Junk button pressed to manually mark this email as spam... - Sieve script invocation 3 * imap.changedflags => Junk * hasflag => \seen - Sieve script invocation 4 * imap.changedflags => NonJunk * hasflag => \seen - Notes: Why neither Junk nor NonJunk flags set for hasflag? * Scenario 4 - "Not Junk" button is pressed to manually mark this email as ham... - Sieve script invocation 5 * imap.changedflags => NonJunk * hasflag => \seen - Sieve script invocation 6 * imap.changedflags => Junk * hasflag => \seen - Sieve script invocation 7 * imap.changedflags => \Seen * hasflag => NonJunk Perhaps it is relevant... where I have captured the value from hasflag... that only one token is ever reported - even where I'd expect multiple flags present. I would have expected at least to see both 'Junk' and 'NotJunk' alongside '\seen' for hasflag at appropriate stages in the sequence of scenarios. Is there a problem with how I've used the :match idiom (with "*") intending to capture all the flags associated with the message? (If so, what approach should I have used instead?) Is there a bug which prevents using the hasflag feature to disambiguate between a flag reported for imap.changedflags having been added versus having been removed? If not, where have I gone wrong? Versions... Server-side: Debian Trixie: dovecot-core/stable,stable-security,now 1:2.4.1+dfsg1-6+deb13u6 amd64 [installed] dovecot-imapd/stable,stable-security,now 1:2.4.1+dfsg1-6+deb13u6 amd64 [installed] dovecot-sieve/stable,stable-security,now 1:2.4.1+dfsg1-6+deb13u6 amd64 [installed] Client-side: Windows 11 Thunderbird 140.12.1esr (64-bit) Steve NonJunk \seen 5 Junk \seen 6 \Seen NonJunk 7 Weird... Is NonJunk reported for hasflag because it is now the only flag associated with the message (after \Seen flag removed)?

3 5

[patch] proposed patch for managing timeouts on doveadm iteration with -A
by John Fawcett 10 Aug '26

10 Aug '26

Hi having further investigated the timeouts mentioned in the previous thread, I am submitting this patch as a potential solution. Basically with -A doveadm parameter, the 155 second timeout is applied to the whole end to end transaction. With -F parameter the 155 second timeout is applied to each single user operation. Changing the logic of -A to follow -F looks a bit invasive. So this patch does more or less the same thing, i.e. giving each user operation 155 seconds timeout, done in a different way. Whenever another username is returned, the timeout is reset. PS I got help from Claude on this. best regards John

3 5

Bug report: Pigeonhole Sieve delivery plugin fails to load in Dovecot 2.4 — undefined symbol mail_deliver_ctx_get_log_var_expand_table
by Developer Sub N Grill 08 Aug '26

08 Aug '26

Hello Dovecot Team, I am reporting what appears to be a packaging/ABI issue affecting the Pigeonhole Sieve delivery plugin in Dovecot 2.4. I have performed extensive diagnostics and would appreciate any guidance. Environment Operating System: Debian 13 (Trixie), amd64 Repository: Official Dovecot CE repository (repo.dovecot.org/ce-2.4-latest/debian/trixie) Installed package version:2:2.4.4-5+debian13 Installed packages: dovecot-core dovecot-sieve dovecot-lmtpd dovecot-imapd dovecot-pop3d dovecot-managesieved dovecot-pgsql All packages are installed at the exact same version. Problem Description When enabling the Sieve delivery plugin with: mail_plugins { sieve = yes } Dovecot fails to load the plugin with the following error: sievec: Fatal: Couldn't load required plugin /usr/lib/dovecot/modules/lib90_sieve_plugin.so: dlopen() failed: /usr/lib/dovecot/modules/lib90_sieve_plugin.so: undefined symbol: mail_deliver_ctx_get_log_var_expand_table As a result, message delivery fails entirely whenever the Sieve delivery plugin is enabled. Disabling the plugin restores normal mail delivery. Diagnostics Performed1. Package verification All installed packages are version 2:2.4.4-5+debian13 from the official Dovecot CE repository. There are no mixed package versions. 2. Symbol verification I searched for the symbol mail_deliver_ctx_get_log_var_expand_table throughout the Dovecot libraries. Results: nm -D on libdovecot-lda.so.0.0.0 → symbol not found readelf -sW on libdovecot-lda.so.0.0.0 → symbol not found Recursive search across all .so files under: /usr/lib/dovecot/ /usr/lib/x86_64-linux-gnu/dovecot/ → symbol not exported anywhere The symbol string exists inside both: lib90_sieve_plugin.so libdovecot-lda.so.0.0.0 but only as plain text (visible via grep), never as an exported ELF symbol. 3. Dependency verification ldd on lib90_sieve_plugin.so shows dependencies on: libdovecot-sieve.so.0 libdovecot-storage.so.0 libdovecot.so.0 It does not directly link against libdovecot-lda.so. 4. Standalone sievec Compiling a Sieve script works correctly: sievec /tmp/test.sieve Exit status is 0 as long as no configuration enables the Sieve delivery plugin. The failure only occurs once: mail_plugins { sieve = yes } is present in the configuration. Reproduced on a Clean Debian 13 Installation To rule out configuration or upgrade issues, I reproduced the exact same problem on a completely clean debian:13-slim container. I installed only the Debian stable packages: apt-get install dovecot-core dovecot-sieve dovecot-lmtpd (version 1:2.4.1+dfsg1-6+deb13u6) Using the same production configuration with: mail_plugins { sieve = yes } produces the exact same error: sievec: Fatal: Couldn't load required plugin ... undefined symbol: mail_deliver_ctx_get_log_var_expand_table This indicates the problem is not caused by: mixed package versions an upgrade issue local modifications custom configuration The issue reproduces consistently on both: Dovecot CE 2.4.4 Debian 13's packaged Dovecot 2.4.1 Questions Is mail_deliver_ctx_get_log_var_expand_table a new internal function that should be exported in Dovecot 2.4? Was there an ABI change affecting the Pigeonhole plugin? Is this a known issue in the Dovecot 2.4.x packages? If so, is a fix planned (for example, in 2.4.5)? Is there any recommended workaround for using Sieve during message delivery (e.g. moving spam to the Junk folder) while this issue is unresolved? I am trying to use the new Dovecot 2.4 configuration syntax (sieve_script_type, sieve_script_precedence, and sieve_script_path), since sieve_before and the plugin {} block were removed in 2.4. Thank you for your time. I would be happy to provide additional logs, the complete doveconf -n output, or a core dump if that would be helpful. Best regards, Miguel A Morales Server: Debian 13 (amd64) Dovecot: 2.4.4-5+debian13 Hello Dovecot Team, I am reporting what appears to be a packaging/ABI issue affecting the Pigeonhole Sieve delivery plugin in Dovecot 2.4. I have performed extensive diagnostics and would appreciate any guidance. Environment o Operating System: Debian 13 (Trixie), amd64 o Repository: Official Dovecot CE repository (repo.dovecot.org/ce-2.4-latest/debian/trixie) o Installed package version: 2:2.4.4-5+debian13 Installed packages: o dovecot-core o dovecot-sieve o dovecot-lmtpd o dovecot-imapd o dovecot-pop3d o dovecot-managesieved o dovecot-pgsql All packages are installed at the exact same version. Problem Description When enabling the Sieve delivery plugin with: mail_plugins { sieve = yes } Dovecot fails to load the plugin with the following error: sievec: Fatal: Couldn't load required plugin /usr/lib/dovecot/modules/lib90_sieve_plugin.so: dlopen() failed: /usr/lib/dovecot/modules/lib90_sieve_plugin.so: undefined symbol: mail_deliver_ctx_get_log_var_expand_table As a result, message delivery fails entirely whenever the Sieve delivery plugin is enabled. Disabling the plugin restores normal mail delivery. Diagnostics Performed 1. Package verification All installed packages are version 2:2.4.4-5+debian13 from the official Dovecot CE repository. There are no mixed package versions. 2. Symbol verification I searched for the symbol mail_deliver_ctx_get_log_var_expand_table throughout the Dovecot libraries. Results: o nm -D on libdovecot-lda.so.0.0.0 -> symbol not found o readelf -sW on libdovecot-lda.so.0.0.0 -> symbol not found o Recursive search across all .so files under: o /usr/lib/dovecot/ o /usr/lib/x86_64-linux-gnu/dovecot/ -> symbol not exported anywhere o The symbol string exists inside both: o lib90_sieve_plugin.so o libdovecot-lda.so.0.0.0 but only as plain text (visible via grep), never as an exported ELF symbol. 3. Dependency verification ldd on lib90_sieve_plugin.so shows dependencies on: o libdovecot-sieve.so.0 o libdovecot-storage.so.0 o libdovecot.so.0 It does not directly link against libdovecot-lda.so. 4. Standalone sievec Compiling a Sieve script works correctly: sievec /tmp/test.sieve Exit status is 0 as long as no configuration enables the Sieve delivery plugin. The failure only occurs once: mail_plugins { sieve = yes } is present in the configuration. Reproduced on a Clean Debian 13 Installation To rule out configuration or upgrade issues, I reproduced the exact same problem on a completely clean debian:13-slim container. I installed only the Debian stable packages: apt-get install dovecot-core dovecot-sieve dovecot-lmtpd (version 1:2.4.1+dfsg1-6+deb13u6) Using the same production configuration with: mail_plugins { sieve = yes } produces the exact same error: sievec: Fatal: Couldn't load required plugin ... undefined symbol: mail_deliver_ctx_get_log_var_expand_table This indicates the problem is not caused by: o mixed package versions o an upgrade issue o local modifications o custom configuration The issue reproduces consistently on both: o Dovecot CE 2.4.4 o Debian 13's packaged Dovecot 2.4.1 Questions 1. Is mail_deliver_ctx_get_log_var_expand_table a new internal function that should be exported in Dovecot 2.4? Was there an ABI change affecting the Pigeonhole plugin? 2. Is this a known issue in the Dovecot 2.4.x packages? If so, is a fix planned (for example, in 2.4.5)? 3. Is there any recommended workaround for using Sieve during message delivery (e.g. moving spam to the Junk folder) while this issue is unresolved? I am trying to use the new Dovecot 2.4 configuration syntax (sieve_script_type, sieve_script_precedence, and sieve_script_path), since sieve_before and the plugin {} block were removed in 2.4. Thank you for your time. I would be happy to provide additional logs, the complete doveconf -n output, or a core dump if that would be helpful. Best regards, Miguel A Morales Server: Debian 13 (amd64) Dovecot: 2.4.4-5+debian13

3 2

Can't connect to MySQL without SSL
by dovecot＠fagschlunger.at 08 Aug '26

08 Aug '26

Hi! I try to migrate from dovecot 2.3 to dovecot CE 2.4, but within a docker container. But I always get the following error from Dovecot CE: Error: auth: mysql(host.docker.internal): Connect failed to database (foobar): TLS/SSL error: self-signed certificate in certificate chain - waiting for 1 seconds before retry This is how I configured the mysql connection: mysql host.docker.internal { host = host.docker.internal port = 3306 user = ... password = ... dbname = foobar ssl = no } So MySQL runs on the host machine directly, not in a container - therefore I'm using "host.docker.internal" as an host. But I don't need SQL encryption, since both MySQL and Dovecot run on the same machine. So why the heck does it look like, Dovecot is trying to connect using SSL? Best regards, Billie

5 7

Re: [patch] proposed patch for managing timeouts on doveadm iteration with -A
by MK 07 Aug '26

07 Aug '26

>On 26. Jul 2026, at 0.17, John Fawcett via dovecot <dovecot(a)dovecot.org> wrote: >> >> Hi >> >> having further investigated the timeouts mentioned in the previous thread, I am submitting this patch as a potential solution. >> >> Basically with -A doveadm parameter, the 155 second timeout is applied to the whole end to end transaction. With -F parameter the 155 second >timeout is applied to each single user operation. Changing the logic of -A to follow -F looks a bit invasive. So this patch does more or less the >same thing, i.e. giving each user operation 155 seconds timeout, done in a different way. Whenever another username is returned, the timeout is >reset. >> >> PS I got help from Claude on this. > >Some further improvements via Fable - does this still fix your problems? > >commit 9deefd88b37d4e9bfecdf6bd1c9fa8a3f9d6b100 >Author: Timo Sirainen <timo.sirainen(a)open-xchange.com> >Date: Wed Aug 5 21:33:42 2026 +0000 > > lib-auth-client: Extend LIST request timeout whenever a username is returned > > The auth lookup timeout (155 seconds by default) was applied to the whole > LIST request, i.e. the entire user enumeration. With large installations > listing all users can easily take longer than that, causing e.g. > doveadm -A to fail with "Auth server request timed out". > > Reset the request's timeout whenever another username is returned. This > turns the timeout into a "no progress for N seconds" stall detector, > matching how independent short-lived per-user requests (e.g. as used when > iterating -F user files) never accumulate a single deadline across the > whole run. > > The timeout handling assumes that requests expire in creation order, so > extending is only allowed while the request is alone on its connection. > This is always the case for LIST, which is asserted at init already. Timo can you say in which upcoming version this patch will be included? Oliver

1 0

Detection of HAVE_MYSQL_SSL_VERIFY_SERVER_CERT is broken
by Tomas Volf 31 Jul '26

31 Jul '26

Hello, detection of HAVE_MYSQL_SSL_VERIFY_SERVER_CERT is currently broken, and the macro is never defined. The test program fails, but for incorrect reason. --8<---------------cut here---------------start------------->8--- conftest.c:140:20: error: expected declaration specifiers or '...' before ',' token 140 | _au_m4_changequote(,) | ^ conftest.c:140:21: error: expected declaration specifiers or '...' before ')' token 140 | _au_m4_changequote(,) | ^ In file included from /gnu/store/6lmd3apzkmhwzj3yn0inyj484m9qml6y-mariadb-connector-c-3.4.5/include/mariadb/mysql.h:35, from conftest.c:141: /gnu/store/7iwcvd0gjrfq6bj7zvf3r59baw6vib5a-gcc-14.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/14.3.0/include/stdarg.h:103:9: error: unknown type name '__gnuc_va_list' 103 | typedef __gnuc_va_list va_list; | ^~~~~~~~~~~~~~ --8<---------------cut here---------------end--------------->8--- Fix is to delete the only occurrence of _au_m4_changequote([,]) in the m4/want_mysql.m4 file. However, that will reveal a compilation error here: --8<---------------cut here---------------start------------->8--- #ifdef HAVE_MYSQL_SSL_VERIFY_SERVER_CERT int ssl_verify_server_cert = ssl_set->ssl_client_require_valid_cert ? 1 : 0; mysql_options(db->mysql, MYSQL_OPT_SSL_VERIFY_SERVER_CERT, (void *)&ssl_verify_server_cert); #endif #else --8<---------------cut here---------------end--------------->8--- Variable `ssl_set' does not exist and should be `db->ssl_set'. Have a nice day, Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

1 0

Confusion about mailbox_list_layout=fs
by Roland Hieber 27 Jul '26

27 Jul '26

Hi, I am trying to understand how 'mailbox_list_layout = fs' is working when I have 'mail_driver = Maildir' (on Dovecot 2.4.1-4 from Debian trixie). If I look at 'doveconf -a', I see that 'mailbox_list_layout = fs' is already the default, however, the Maildirs from my freshly created test user are still created on disk in the format .INBOX.subfolder instead of INBOX/subfolder, which is in conflict with what the documentation says at <https://doc.dovecot.org/2.4.3/core/config/mailbox_formats/maildir.html#dire…>. However, if I set 'mailbox_list_layout = fs' *explicitely* in the global part of /etc/dovecot/conf.d/10-mail.conf, then delete all files and folders in the mail home of my test user, reload dovecot, send a test mail, and create a new subfolder for my test user in Thunderbird, the new subfolder gets created on disk as INBOX/subfolder, just like I expect. The behaviour is consistently reproducable in both directions: I also get maildirs with dots again after I delete mailbox_list_layout from 10-mail.conf, reload dovecot, and clear the mail home of my test user. What is going on here…? I don't see any change in 'doveconf -a' between these two use cases (the output is literally identical, and it's both showing 'mailbox_list_layout = fs'), and obviously it's missing from 'doveconf -n' because it's the default. I also found out that it is possible to override this setting per user by using the 'userdb_mailbox_list_layout' option in the extra fields of the userdb, but I'm not setting any extra fields there for my test user. Output of 'doveconf -n' (redacted where necessary) is attached. Regards, - Roland -- Roland Hieber, Pengutronix e.K. | rhi(a)pengutronix.de | Steuerwalder Str. 21 | https://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

2 2

Doveadm and iterate query
by Bogusław Juza 25 Jul '26

25 Jul '26

Hi! I have a problem with Dovecot on Debian 13: Dovecot 2.4.1, Debian Trixie > doveadm mailbox path -A INBOX >/dev/null doveadm(email@domain): Error: auth-master: userdb list: User listing returned failure doveadm: Error: cmd mailbox path: Failed to iterate through some users userdb sql { iterate_query = SELECT `email` AS `user` FROM `users` } In syslog file: dovecot: auth: Error: auth-worker: Aborted LIST request for *: Shutting down I have over 30k users in sql DB, doveadm with -A option is dying few second after start with this error, printing about 10% of users. I need much more time (FE command "doveadm expunge -A mailbox Spam savedbefore 3w" could run over 30 minutes). What I'm doing wrong? Bogusław Juza

5 12

Reporting a Patch needed: Fix-anvil-busy-loop-on-EPOLLHUP-when-a-multiplex-cha.patch
by David Lanning 24 Jul '26

24 Jul '26

The attached patch spec is what we had to deploy to cover the matter. The attached patch spec is what we had to deploy to cover the matter.

2 1

Strange characters in log file
by Doug Hardie 21 Jul '26

21 Jul '26

I am occasionally finding some strange characters in the log file. I have captured on entry that vi cannot handle. It simply won't go past this record. I suspect the issue is around 0347 in the record below. Any ideas how to prevent this from happening as it makes it difficult to find specific records in the log. vi is unable to delete the line with this issue. mail# head -1 imaplog.test | od -t x1c 0000000 4a 75 6c 20 31 37 20 30 32 3a 33 34 3a 35 35 20 J u l 1 7 0 2 : 3 4 : 5 5 0000020 6d 61 69 6c 20 64 6f 76 65 63 6f 74 5b 35 32 39 m a i l d o v e c o t [ 5 2 9 0000040 30 5d 3a 20 69 6d 61 70 28 64 6f 75 67 29 5b 31 0 ] : i m a p ( d o u g ) [ 1 0000060 30 2e 30 2e 31 2e 32 33 32 5d 3c 4e 74 79 78 52 0 . 0 . 1 . 2 3 2 ] < N t y x R 0000100 4d 74 57 4e 64 38 4b 41 41 48 6f 3e 3a 20 64 65 M t W N d 8 K A A H o > : d e 0000120 6c 65 74 65 3a 20 62 6f 78 3d 44 65 6c 65 74 65 l e t e : b o x = D e l e t e 0000140 64 20 4d 65 73 73 61 67 65 73 2c 20 75 69 64 3d d M e s s a g e s , u i d = 0000160 35 38 32 32 31 33 2c 20 6d 73 67 69 64 3d 3c 39 5 8 2 2 1 3 , m s g i d = < 9 0000200 31 30 35 30 36 39 31 2e 31 34 37 36 39 34 36 2e 1 0 5 0 6 9 1 . 1 4 7 6 9 4 6 . 0000220 31 37 38 33 35 38 37 39 33 35 37 36 36 40 6d 61 1 7 8 3 5 8 7 9 3 5 7 6 6 @ m a 0000240 72 6b 65 74 6f 2d 70 6c 61 74 66 6f 72 6d 2d 2d r k e t o - p l a t f o r m - - 0000260 65 6d 61 69 6c 2d 73 65 6e 64 65 72 2d 70 72 6f e m a i l - s e n d e r - p r o 0000300 64 2d 62 61 74 63 68 2d 63 6c 75 2e 2e 2e 2c 20 d - b a t c h - c l u . . . , 0000320 73 69 7a 65 3d 35 35 39 39 30 2c 20 66 72 6f 6d s i z e = 5 5 9 9 0 , f r o m 0000340 3d 57 4f 52 4c 44 e2 4d 2d 5e 40 4d 2d 5e 59 73 = W O R L D 342 M - ^ @ M - ^ Y s 0000360 20 54 69 6d 20 4c 61 6d 65 72 20 3c 65 64 69 74 T i m L a m e r < e d i t 0000400 6f 72 40 77 6e 67 2e 6f 72 67 3e 0a o r @ w n g . o r g > \n 0000414 -- Doug I am occasionally finding some strange characters in the log file. I have captured on entry that vi cannot handle. It simply won't go past this record. I suspect the issue is around 0347 in the record below. Any ideas how to prevent this from happening as it makes it difficult to find specific records in the log. vi is unable to delete the line with this issue. mail# head -1 imaplog.test | od -t x1c 0000000 4a 75 6c 20 31 37 20 30 32 3a 33 34 3a 35 35 20 J u l 1 7 0 2 : 3 4 : 5 5 0000020 6d 61 69 6c 20 64 6f 76 65 63 6f 74 5b 35 32 39 m a i l d o v e c o t [ 5 2 9 0000040 30 5d 3a 20 69 6d 61 70 28 64 6f 75 67 29 5b 31 0 ] : i m a p ( d o u g ) [ 1 0000060 30 2e 30 2e 31 2e 32 33 32 5d 3c 4e 74 79 78 52 0 . 0 . 1 . 2 3 2 ] < N t y x R 0000100 4d 74 57 4e 64 38 4b 41 41 48 6f 3e 3a 20 64 65 M t W N d 8 K A A H o > : d e 0000120 6c 65 74 65 3a 20 62 6f 78 3d 44 65 6c 65 74 65 l e t e : b o x = D e l e t e 0000140 64 20 4d 65 73 73 61 67 65 73 2c 20 75 69 64 3d d M e s s a g e s , u i d = 0000160 35 38 32 32 31 33 2c 20 6d 73 67 69 64 3d 3c 39 5 8 2 2 1 3 , m s g i d = < 9 0000200 31 30 35 30 36 39 31 2e 31 34 37 36 39 34 36 2e 1 0 5 0 6 9 1 . 1 4 7 6 9 4 6 . 0000220 31 37 38 33 35 38 37 39 33 35 37 36 36 40 6d 61 1 7 8 3 5 8 7 9 3 5 7 6 6 @ m a 0000240 72 6b 65 74 6f 2d 70 6c 61 74 66 6f 72 6d 2d 2d r k e t o - p l a t f o r m - - 0000260 65 6d 61 69 6c 2d 73 65 6e 64 65 72 2d 70 72 6f e m a i l - s e n d e r - p r o 0000300 64 2d 62 61 74 63 68 2d 63 6c 75 2e 2e 2e 2c 20 d - b a t c h - c l u . . . , 0000320 73 69 7a 65 3d 35 35 39 39 30 2c 20 66 72 6f 6d s i z e = 5 5 9 9 0 , f r o m 0000340 3d 57 4f 52 4c 44 e2 4d 2d 5e 40 4d 2d 5e 59 73 = W O R L D 342 M - ^ @ M - ^ Y s 0000360 20 54 69 6d 20 4c 61 6d 65 72 20 3c 65 64 69 74 T i m L a m e r < e d i t 0000400 6f 72 40 77 6e 67 2e 6f 72 67 3e 0a o r @ w n g . o r g > \n 0000414 -- Doug

2 4

AW: AW: [EXT] Re: doveadm backup / purge problems since migration from 2.3 to 2.4
by MK 21 Jul '26

21 Jul '26

>>> On 09/07/2026 13:30 EEST MK <dovecot-ml(a)mk.de> wrote: >>> >>> >>> >> On 09/07/2026 11:58 EEST MK via dovecot <dovecot(a)dovecot.org>> wrote: >>> >> >>> >> >>> >> 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 >>> >> >>> >>> >>> >Try adding >>> > >>> >log_debug=category=auth >>> > >>> >and see if it can shed light one this. >>> >>> I'll add it to the config and get back next time the problem occurs. >>> >>> >> 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. >>> >> >>> >>> >What does your purge script do? >>> >>> I have attached it so you can take a look. >>> Is it a known issue that the -A option doesn't work as well as it did in 2.3? >>> >>> >> >>And you are sure it's the purge doing it, and not running doveadm sync? > >If you mean delete everything, yes. There is nothing else running there. No other scripts, nothing other is accessing Dovecot. >A few times I have seen it live and the other times I can see in my logging that when the script starts the space is sinking and sinking near to >zero until the script ends. I'm logging the disk space every minute. > >It’s clear that these are two different problems right? (purge deletes everything and backup writes to mutch data) > >What do I have to search for in the logfiles if the problem oncours? What is interesting for you? The debug makes realy mutch log entries. Update to this. Since I activated the debugging on 09/07/2026 the problem did not occur again, really strange. I can't explain it sice I haven't changed anything other than enabling debugging. Oliver

1 0

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

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

16 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!

2 2

dsync does not like sieve
by Stéphane Veyret 14 Jul '26

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

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

crash in sieve-filter with 2.4.4
by Noah Meyerhans 13 Jul '26

13 Jul '26

Forwarded from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1139275 A certain poison pill message seems to crash sieve-filter. A reproducer script, email message, and sieve script are at https://salsa.debian.org/noahm/dovecot/-/tree/sieve-crash/debian/tests/siev… The problem is not reproducible with 2.4.1, so it seems to be a regression introduced since then. Coredump details follow: root@dovecot-test:/home/noahm/dovecot# coredumpctl info | cat PID: 110911 (sieve-filter) TID: 110911 (sieve-filter) UID: 65534 (nobody) GID: 65534 (nogroup) Signal: 6 (ABRT) Timestamp: Mon 2026-06-08 19:16:37 UTC (29s ago) Command Line: sieve-filter -u dep8 -e -W -D -C -v /srv/dovecot-dep8/test.sieve INBOX Executable: /usr/bin/sieve-filter Control Group: /user.slice/user-1000.slice/session-5.scope Unit: session-5.scope Slice: user-1000.slice Session: 5 Owner UID: 1000 (noahm) Boot ID: 46469969e01043559d913ef8ab625856 Machine ID: a497a098bd094c1c8f7c8ed02aa21853 Hostname: dovecot-test Storage: /var/lib/systemd/coredump/core.sieve-filter.65534.46469969e01043559d913ef8ab625856.110911.1780946197000000.zst (present) Size on Disk: 253.5K Message: Process 110911 (sieve-filter) of user 65534 dumped core. Module libgcc_s.so.1 from deb gcc-16-16.1.0-1.amd64 Module libstdc++.so.6 from deb gcc-16-16.1.0-1.amd64 Stack trace of thread 110911: #0 0x00007fe06b09fcfc n/a (libc.so.6 + 0x97cfc) #1 0x00007fe06b048d02 raise (libc.so.6 + 0x40d02) #2 0x00007fe06b0304b2 abort (libc.so.6 + 0x284b2) #3 0x00007fe06b26ed45 n/a (libdovecot.so.0 + 0x6ed45) #4 0x00007fe06b357597 default_fatal_handler (libdovecot.so.0 + 0x157597) #5 0x00007fe06b26ec72 i_panic (libdovecot.so.0 + 0x6ec72) #6 0x00007fe06b273b90 n/a (libdovecot.so.0 + 0x73b90) #7 0x00007fe06b3498fb n/a (libdovecot.so.0 + 0x1498fb) #8 0x00007fe06b34a784 n/a (libdovecot.so.0 + 0x14a784) #9 0x00007fe06b34a93b buffer_append (libdovecot.so.0 + 0x14a93b) #10 0x00007fe06b344cc6 dregex_code_match_groups (libdovecot.so.0 + 0x144cc6) #11 0x00007fe06b806a27 n/a (libdovecot-sieve.so.0 + 0x6da27) #12 0x00007fe06b806cd0 n/a (libdovecot-sieve.so.0 + 0x6dcd0) #13 0x00007fe06b7ee411 sieve_match_value (libdovecot-sieve.so.0 + 0x55411) #14 0x00007fe06b7ee711 sieve_match (libdovecot-sieve.so.0 + 0x55711) #15 0x00007fe06b7f5862 n/a (libdovecot-sieve.so.0 + 0x5c862) #16 0x00007fe06b7eccde sieve_interpreter_continue (libdovecot-sieve.so.0 + 0x53cde) #17 0x00007fe06b7fbfbe sieve_execute (libdovecot-sieve.so.0 + 0x62fbe) #18 0x00005638c0022fcf main (sieve-filter + 0x3fcf) #19 0x00007fe06b031f77 n/a (libc.so.6 + 0x29f77) #20 0x00007fe06b032027 __libc_start_main (libc.so.6 + 0x2a027) #21 0x00005638c0023791 _start (sieve-filter + 0x4791) ELF object binary architecture: AMD x86-64

2 1

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

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

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

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

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

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

Convert sqlite configuration from 2.3 to 2.4
by Horst B Simon 24 Jun '26

24 Jun '26

Hi, I succesful converted all configurations from dovecot 2.3 to 2.4, except for the sqlite configuration. I googled and all configuration are for mysql/mariadb and not for sqlite. The sqlite database is created with postfixadmin and my current configuration for dovecot 2.3 (dovecot-sql.conf.ext) is: driver = sqlite connect = /var/mail/postfixadmin.db default_pass_scheme = DES-CRYPT password_query = \ SELECT username as user, password, '/var/mail/%d/%n' as userdb_home, \ 'maildir:/var/mail/%n' as userdb_mail, 5000 as userdb_uid, 5000 as userdb_gid \ FROM mailbox WHERE username = '%u' AND active = '1' user_query = \ SELECT '/var/mail/%d/%n' as home, 'maildir:/var/mail/%n' as mail, \ 5000 AS uid, 5000 AS gid, printf('dirsize:storage=', quota) AS quota \ FROM mailbox WHERE username = '%u' AND active = '1' I tried the only converter, but it didn’t do any conversion. Any help appreciated. Thanks and Regards, Horst Hi, I succesful converted all configurations from dovecot 2.3 to 2.4, except for the sqlite configuration. I googled and all configuration are for mysql/mariadb and not for sqlite. The sqlite database is created with postfixadmin and my current configuration for dovecot 2.3 (dovecot-sql.conf.ext) is: driver = sqlite connect = /var/mail/postfixadmin.db default_pass_scheme = DES-CRYPT password_query = \ SELECT username as user, password, '/var/mail/%d/%n' as userdb_home, \ 'maildir:/var/mail/%n' as userdb_mail, 5000 as userdb_uid, 5000 as userdb_gid \ FROM mailbox WHERE username = '%u' AND active = '1' user_query = \ SELECT '/var/mail/%d/%n' as home, 'maildir:/var/mail/%n' as mail, \ 5000 AS uid, 5000 AS gid, printf('dirsize:storage=', quota) AS quota \ FROM mailbox WHERE username = '%u' AND active = '1' I tried the only converter, but it didn't do any conversion. Any help appreciated. Thanks and Regards, Horst

2 2

Incomplete Dovecot Log Entries
by Bryan Simmons 19 Jun '26

19 Jun '26

There are hundreds of dovecot “Disconnected: Connection closed” messages in the log file that do not have a corresponding connect record. Is this normal or are there configuration options that need to be modified? Note the user accounts listed, and other similar records, do not exist on this server. 2026-06-14T02:11:48.843517-04:00 mail dovecot: imap-login: Disconnected: Connection closed (auth failed, 3 attempts in 23 secs): user=<rantanplan_admin(a)nanomail.net>, method=PLAIN, rip=190.181.120.152, lip=10.0.1.211, TLS, session=<T8xvlDBUnNC+tXiY> 2026-06-14T02:12:16.614611-04:00 mail dovecot: imap-login: Disconnected: Connection closed (auth failed, 3 attempts in 24 secs): user=<rantanplan_admin>, method=PLAIN, rip=41.139.10.25, lip=10.0.1.211, TLS, session=<cvoGljBUS+YpiwoZ> 2026-06-14T03:23:55.523146-04:00 mail dovecot: imap-login: Disconnected: Connection closed (auth failed, 3 attempts in 23 secs): user=<rantanplan.info(a)nanomail.net>, method=PLAIN, rip=103.69.9.148, lip=10.0.1.211, TLS, session=<SOBYljFUlsdnRQmU> Thanks, Bryan

1 0

Announcing nauthilus-director: a Nauthilus-backed mail protocol director
by Christian Rößner 17 Jun '26

17 Jun '26

Hi, I would like to announce `nauthilus-director` for the first time on this list. `nauthilus-director` is an open-source mail protocol director and transparent proxy for Nauthilus-backed mail deployments. It sits in front of stateful mail backends, authenticates frontend sessions through Nauthilus, resolves routing and placement inside the director, selects healthy backend services, keeps active user affinity in Redis, and then proxies the established connection to the selected backend. The current focus is on deployments where backend placement, maintenance, drains, user movement and session affinity need to be explicit, observable and controllable. The director is not a mailbox server and not a general-purpose load balancer; it owns the narrow director responsibilities between clients, Nauthilus and backend mail services. Current capabilities include: - IMAP/IMAPS, POP3/POP3S, LMTP/LMTPS and ManageSieve proxying - Nauthilus-backed authentication over HTTP or gRPC - director-owned routing and backend selection - Redis-backed session affinity and runtime coordination - backend health, maintenance, runtime drains and placement overrides - an OpenAPI-based REST control API and `nauthilus-directorctl` - metrics, structured logging and OpenTelemetry tracing The demo stack includes Dovecot backend shards and exercises real IMAP, LMTP, POP3 and ManageSieve paths, so feedback from Dovecot operators would be especially useful. Related to this, Nauthilus itself has recently been released as version 3.0.0. Nauthilus is the central authentication and policy engine in this setup: it provides centralized authentication and identity handling for mail and web workloads, LDAP-backed or Lua-driven policy decisions, OIDC/SAML IdP functionality, MFA support, and Redis-backed state handling. In the director architecture, Nauthilus remains the authentication and policy authority, while `nauthilus-director` owns concrete backend placement and proxy lifecycle decisions. Project links: - nauthilus-director: https://github.com/croessner/nauthilus-director - Nauthilus: https://github.com/croessner/nauthilus - Documentation / website: https://nauthilus.org The director is still young, so I would be interested in feedback from people running Dovecot-backed infrastructures, especially around operational workflows, backend maintenance, migration scenarios and protocol behavior. The director is still in beta. Best regards, Christian Rößner -- Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.website PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5 Hi, I would like to announce `nauthilus-director` for the first time on this list. `nauthilus-director` is an open-source mail protocol director and transparent proxy for Nauthilus-backed mail deployments. It sits in front of stateful mail backends, authenticates frontend sessions through Nauthilus, resolves routing and placement inside the director, selects healthy backend services, keeps active user affinity in Redis, and then proxies the established connection to the selected backend. The current focus is on deployments where backend placement, maintenance, drains, user movement and session affinity need to be explicit, observable and controllable. The director is not a mailbox server and not a general-purpose load balancer; it owns the narrow director responsibilities between clients, Nauthilus and backend mail services. Current capabilities include: - IMAP/IMAPS, POP3/POP3S, LMTP/LMTPS and ManageSieve proxying - Nauthilus-backed authentication over HTTP or gRPC - director-owned routing and backend selection - Redis-backed session affinity and runtime coordination - backend health, maintenance, runtime drains and placement overrides - an OpenAPI-based REST control API and `nauthilus-directorctl` - metrics, structured logging and OpenTelemetry tracing The demo stack includes Dovecot backend shards and exercises real IMAP, LMTP, POP3 and ManageSieve paths, so feedback from Dovecot operators would be especially useful. Related to this, Nauthilus itself has recently been released as version 3.0.0. Nauthilus is the central authentication and policy engine in this setup: it provides centralized authentication and identity handling for mail and web workloads, LDAP-backed or Lua-driven policy decisions, OIDC/SAML IdP functionality, MFA support, and Redis-backed state handling. In the director architecture, Nauthilus remains the authentication and policy authority, while `nauthilus-director` owns concrete backend placement and proxy lifecycle decisions. Project links: - nauthilus-director: https://github.com/croessner/nauthilus-director - Nauthilus: https://github.com/croessner/nauthilus - Documentation / website: https://nauthilus.org The director is still young, so I would be interested in feedback from people running Dovecot-backed infrastructures, especially around operational workflows, backend maintenance, migration scenarios and protocol behavior. The director is still in beta. Best regards, Christian Roessner -- Roessner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.website PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5

3 3

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

New Backup Issue
by Doug Hardie 11 Jun '26

11 Jun '26

I have dovecot using maildir storage on the mail machine. I have an external drive directly connected to use a backup for the mailboxes. Doveadm backup works perfectly for this setup. I also have two external backup servers. Backup to those tends to fail with a variety of errors. I deleted the Maildir directory on the backup servers and created the original backups with doveadm backup. No issues were reported. However, the next backup generates errors: dsync-remote(jeanne)<HV6JE+i/KWo0NwAAq6l46g>: Warning: Deleting mailbox 'INBOX': UID=11166 GUID=1712570780.M604032P10319.mail,S=99689,W=101000 is missing locally dsync-remote(jeanne)<HV6JE+i/KWo0NwAAq6l46g>: Error: Couldn't delete mailbox INBOX: INBOX can't be deleted. dsync-local(jeanne)<HqU9Aei/KWoBMAAAZU03Dg>: Error: Remote command returned error 65: ssh sermons doveadm dsync-server -ujeanne -U dsync-remote(beneke)<eARRAem/KWpdNwAAq6l46g>: Warning: Deleting mailbox 'INBOX': UID=232 GUID=1641564460.M859673P8687.mail,S=5917,W=6035 is missing locally dsync-remote(beneke)<eARRAem/KWpdNwAAq6l46g>: Error: Couldn't delete mailbox INBOX: INBOX can't be deleted. dsync-local(beneke)<mw5bM+i/KWoJMAAAZU03Dg>: Error: Remote command returned error 65: ssh sermons doveadm dsync-server -ubeneke -U dsync-remote(doug)<6gmSJ+m/KWp7NwAAq6l46g>: Warning: Deleting mailbox 'INBOX': UID=92440 GUID=1465118975.V4eI7cfa32M232845.mail is missing locally dsync-remote(doug)<6gmSJ+m/KWp7NwAAq6l46g>: Error: Couldn't delete mailbox INBOX: INBOX can't be deleted. dsync-local(doug)<hwsCH+m/KWoNMAAAZU03Dg>: Error: Remote command returned error 65: ssh sermons doveadm dsync-server -udoug -U There is always one error per user, but they are different between the two backup machine. With the first error, I found the message 1712570780.M604032P10319.mail,S=99689,W=101000 in the mail server cur directory and deleted it. That messge did not exist in the backup server. I ran backup again and no issues. However, the next backup produced the following error: dsync-remote(jeanne)<dNWXGZbUKWoaOgAAq6l46g>: Warning: Deleting mailbox 'INBOX': UID=11167 GUID=1712574432.M425061P11306.mail,S=45149,W=45775 is missing locally dsync-remote(jeanne)<dNWXGZbUKWoaOgAAq6l46g>: Error: Couldn't delete mailbox INBOX: INBOX can't be deleted. dsync-local(jeanne)<Jg3tCZbUKWp5NQAAZU03Dg>: Error: Remote command returned error 65: ssh sermons doveadm dsync-server -ujeanne -U That message is in the cur directory on the mail server. It is not in the backup server. I don't understand the message that those files are missing locally (primary mail server I presume) when they are actually there and missing on the remote server. I don't know why they didn't get copied originally. The first email was recieved on Mon, 8 Apr 2024 so it can't be a timming issue. -- Doug

2 1

Replication performance question and environment variables sanitization
by Jesus Cea 10 Jun '26

10 Jun '26

Hi, there. I am using dovecot 2.3.21.1. I am experimenting with replication, currently doing it manually, using this: doveadm -Dv sync -u jcea ssh email doveadm dsync-server -u prueba_backup; echo $? It works fine so far, but I have a few hundreds of mailboxes in my imap4 account and an "empty" (no changes) sync takes 30 seconds, since apparently it compare every mailbox (according to the debug info printed). I am using "mdbox" storage in both sides. I would expect an event replication, where time is proportional to the volume of changes, not to the total data volume or number of mailboxes. Am I doing anything wrong?. It would be faster to use "replicator" + "mail_replica". Can I improve this in some way? Replication must be both ways, because in one server new emails are arriving and in the other imapserver I am doing my mail work. I want new email appearing in my work imapserver (living my own laptop) and my email processing to be replicated back to the server for backup/disaster recovery (lost laptop, broken HD) and access from a different laptop, phone, etc. Thanks. PS: By default dovecot sanitizes the environment and doesn't allow "SSH_AUTH_SOCK" for ssh-agent. Why?. That is very inconvenient. I am using this environment variable to overcome that: DOVECOT_PRESERVE_ENVS="HOME USER SSH_AUTH_SOCK SSH_AGENT_PID LOG_STDERR_TIMESTAMP TZ CORE_OUTOFMEM CORE_ERROR" Is this the right way to do this? -- Jesús Cea Avión _/_/ _/_/_/ _/_/_/ jcea(a)jcea.es - https://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ Twitter: @jcea _/_/ _/_/ _/_/_/_/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz

2 3

dovecot 2.4 and Outlook
by Jochen Bern 08 Jun '26

08 Jun '26

Since I don't remember seeing *this* mentioned here so far, but *do* remember people asking about Outlook-dovecot compatibility issues every now and then, here's a potential cause for seeing more of those in the immediate future: https://fedoramagazine.org/fedora-43-upgrade-revealed-20-years-old-outlook-… Kind regards, -- Jochen Bern Systemingenieur Binect GmbH

2 3

Using 2 LDAP sources for passdb
by Tom 03 Jun '26

03 Jun '26

I can't seem to find documentation that shows how to set up 2 LDAP passdb blocks. I can get each of them working properly, but only the second of the two works at any given time. I can't figure out the syntax needed to get both to work, even though I've been all over the Dovecot 2.4x official documentation. The docs seem to suggest settings that the server rejects. Anyone have any experience doing this, or know the correct syntax? Thanks in advance! passdb ldap { # works when standalone; fails when combined with 2nd block below #passdb_name = ldap1 #driver = ldap ldap_version = 3 bind = yes bind_userdn = %{user|username} ldap_auth_dn = cn=dovecot,ou=apps,dc=example,dc=com ldap_auth_dn_password = D0vec0t ldap_base = ou=apps,dc=foscore,dc=com ldap_uris = ldapi://%2Frun%2Fldapi filter = (&(objectClass=applicationProcess)(cn=%{user})) passdb_ldap_bind = yes passdb_ldap_bind_userdn = cn=%{user},ou=apps,dc=example,dc=com result_success = return-ok } passdb ldap { #driver = ldap #name = ldap_users ldap_version = 3 bind = yes bind_userdn = %{user|username} ldap_auth_dn = cn=dovecot,ou=apps,dc=example,dc=com ldap_auth_dn_password = D0vec0t ldap_base = ou=people,dc=example,dc=com ldap_uris = ldapi://%2Frun%2Fldapi filter = (&(objectClass=posixAccount)(uid=%{user|username})(memberOf=cn=mail,ou=%{user|domain},ou=groups,dc=example,dc=com)) passdb_ldap_bind = yes passdb_ldap_bind_userdn = uid=%{user|username},ou=people,dc=example,dc=com result_success = return-ok }

2 7

Building on FreeBSD 14.4
by Frank Volf 03 Jun '26

03 Jun '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 14

Re: User authentication for shared mailbox
by Stéphane Veyret 31 May '26

31 May '26

I managed to make it work. In case some other people want to do the same, the trick was to use the master user concept, as suggested by Aki Tuomi, with a lua script to check if user can be master. My configuration looks like this: passdb pam_master { driver = pam master = yes result_success = continue } passdb pam { } passdb lua { lua_file = /etc/dovecot/master-auth.lua result_failure = return-fail result_internalfail = return-fail result_success = continue-ok } passdb ldap { ldap_base = ou=Group,dc=example,dc=com fields { password = {SHA1}IQ== user = %{ldap:cn} } filter = (cn=%{user | username}) } and the lua script: function script_init() return 0 end function auth_passdb_lookup(req) if req.master_user then req:log_info("Looking for groups for " .. tostring(req.master_user)) handle = io.popen("/bin/groups " .. tostring(req.master_user)) output = handle:read("*a") req:log_debug("Searching " .. tostring(req.user) .. " in found groups " .. output) for group in output:gmatch("%w+") do if group == req.user then return dovecot.auth.PASSDB_RESULT_OK, { password="!" } end end end return dovecot.auth.PASSDB_RESULT_USER_UNKNOWN, "No such user" end -- Bien cordialement, / Plej kore, Stéphane Veyret I managed to make it work. In case some other people want to do the same, the trick was to use the master user concept, as suggested by Aki Tuomi, with a lua script to check if user can be master. My configuration looks like this: passdb pam_master { driver = pam master = yes result_success = continue } passdb pam { } passdb lua { lua_file = /etc/dovecot/master-auth.lua result_failure = return-fail result_internalfail = return-fail result_success = continue-ok } passdb ldap { ldap_base = ou=Group,dc=example,dc=com fields { password = {SHA1}IQ== user = %{ldap:cn} } filter = (cn=%{user | username}) } and the lua script: function script_init() return 0 end function auth_passdb_lookup(req) if req.master_user then req:log_info("Looking for groups for " .. tostring(req.master_user)) handle = io.popen("/bin/groups " .. tostring(req.master_user)) output = handle:read("*a") req:log_debug("Searching " .. tostring(req.user) .. " in found groups " .. output) for group in output:gmatch("%w+") do if group == req.user then return dovecot.auth.PASSDB_RESULT_OK, { password="!" } end end end return dovecot.auth.PASSDB_RESULT_USER_UNKNOWN, "No such user" end -- Bien cordialement, / Plej kore, Stephane Veyret

1 0

dsync between 2.3.16 and 2.4.2
by Jean-Daniel Beaubien 28 May '26

28 May '26

Hi, I currently have a doveadm backup running my prod and backup server. Both are currently running 2.3.16, and the following command runs fine: sudo doveadm -v backup -u XXXX -P remote:XXXX@192.168.111.XX I am in the process of updating my servers to ubuntu 26.04 which runs dovecot 2.4.2 and I am running into problems trying to run this command. For some reason, it tries to delete the INBOX on the destination and I get the following error: dsync-remote(XXXX)<7hkbKDl6F2rlxQAArPp36Q>: Error: brain S: Mailbox INBOX sync: mailbox_delete failed: The /private/specialuse attribute cannot be changed doveadm(228686): Error: Remote command returned error 65: ssh -lXXXX 192.168.111.XX doveadm dsync-server -uXXXX I am not sure what/why this is happening. I read the docs and man page, but could not find a solution. Anyone knows what is happening, and how to solve this? Thanks, -JD ----- Addendum ----- Another thing that might help someone else: I had to add a line to the config file to avoid the -U problem: dsync_remote_cmd = "ssh -l%{login} %{host} doveadm dsync-server -u%{user}" This seems to already be solved ( https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/B3TQF…) but not yet in the ubuntu 26.04 release? Hi, I currently have a doveadm backup running my prod and backup server. Both are currently running 2.3.16, and the following command runs fine: sudo doveadm -v backup -u XXXX -P remote:XXXX@192.168.111.XX I am in the process of updating my servers to ubuntu 26.04 which runs dovecot 2.4.2 and I am running into problems trying to run this command. For some reason, it tries to delete the INBOX on the destination and I get the following error: dsync-remote(XXXX)<7hkbKDl6F2rlxQAArPp36Q>: Error: brain S: Mailbox INBOX sync: mailbox_delete failed: The /private/specialuse attribute cannot be changed doveadm(228686): Error: Remote command returned error 65: ssh -lXXXX 192.168.111.XX doveadm dsync-server -uXXXX I am not sure what/why this is happening. I read the docs and man page, but could not find a solution. Anyone knows what is happening, and how to solve this? Thanks, -JD ----- Addendum ----- Another thing that might help someone else: I had to add a line to the config file to avoid the -U problem: dsync_remote_cmd = "ssh -l%{login} %{host} doveadm dsync-server -u%{user}" This seems to already be solved ([1]https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/B3T…) but not yet in the ubuntu 26.04 release? References Visible links 1. https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/B3TQF…

2 1

I can't find up to date documentation about dovecot authentication process design
by kristoffermollerhoj＠gmail.com 27 May '26

27 May '26

Hi, I am currently about to port a legacy / custom authentication mechanism from 2.3 to 2.4. Many things have changed in this area, and I have unfortunately not been able to find any valid documentation about this topic. I have looked here: https://doc.dovecot.org/2.4.4/developers/design/auth_process.html but as far as I can see all the content is about the code design for dovecot 2.3, not 2.4. Just to mention a few examples: There is not anymore a struct named mech_module, there is no such file as mech.h, and also the API for the central callback functions such as auth_new() and auth_initial() seems to have changed a lot (both arguments and return types). Maybe a somewhat unfinished version of the documentation can be found on a specific branch? Thank you, Kristoffer Møllerhøj.

4 5

Sent, Junk and Drafts are not created
by Thomas Jensen 26 May '26

26 May '26

I have a new dovecot 2.4.2 setup. All seems to work fine, except Sent, Junk and Drafts are not created. In 15-mailboxes.conf I have: namespace inbox { # These mailboxes are widely used and could perhaps be created automatically: mailbox Drafts { auto = create special_use = \Drafts } mailbox Junk { auto = create special_use = \Junk } mailbox Trash { auto = create special_use = \Trash } # For \Sent mailboxes there are two widely used names. We'll mark both of # them as \Sent. User typically deletes one of them if duplicates are created. mailbox Sent { auto = create special_use = \Sent } mailbox "Sent Messages" { auto = create special_use = \Sent } } But nothing is created. And dovecot -n return this: (note the "\\") root@rpix:~# dovecot -n # 2.4.2 (0962ed2104): /etc/dovecot/dovecot.conf # Pigeonhole version 2.4.2 (767418c3) # OS: Linux 7.0.0-15-generic x86_64 Ubuntu 26.04 LTS # Hostname: rpix.dk # 9 default setting changes since version 2.4.0 dovecot_config_version = 2.4.0 auth_default_domain = rpix.dk auth_mechanisms = plain login auth_username_format = %{user|lower} dovecot_storage_version = 2.4.0 fts_autoindex = yes fts_autoindex_max_recent_msgs = 999 fts_search_add_missing = yes mail_driver = maildir mail_home = /var/vmail/%{user | domain}/%{user | username} mail_path = ~/Maildir mail_privileged_group = mail protocols = imap lmtp sql_driver = mysql ssl = required passdb sql { default_password_scheme = ARGON2I query = SELECT username AS user,password FROM mailbox WHERE username = '%{user}' AND active='1' } userdb sql { iterate_query = SELECT username AS user FROM mailbox query = SELECT 2000 AS uid, 2000 AS gid FROM mailbox WHERE username = '%{user}' AND active='1' } mysql localhost { dbname = postfixadmin password = # hidden, use -P to show it user = postfixadmin } namespace inbox { inbox = yes mailbox Drafts { auto = create special_use = "\\Drafts" } mailbox Junk { auto = create special_use = "\\Junk" } mailbox Trash { auto = create special_use = "\\Trash" } mailbox Sent { auto = create special_use = "\\Sent" } mailbox "Sent Messages" { auto = create special_use = "\\Sent" } } service imap-login { inet_listener imap { } inet_listener imaps { } } service pop3-login { inet_listener pop3 { } inet_listener pop3s { } } service submission-login { inet_listener submission { } inet_listener submissions { } } service lmtp { unix_listener /var/spool/postfix/private/dovecot-lmtp { group = postfix mode = 0600 user = postfix } } service imap { } service pop3 { } service submission { } service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0666 user = postfix } } service auth-worker { } service dict { unix_listener dict { } } service stats { unix_listener stats-reader { group = www-data mode = 0660 user = www-data } unix_listener stats-writer { group = www-data mode = 0660 user = www-data } } ssl_server { cert_file = /etc/letsencrypt/live/mail/fullchain.pem key_file = /etc/letsencrypt/live/mail/privkey.pem prefer_ciphers = server } protocol lmtp { auth_username_format = %{user | lower} } What am I doing wrong? -- /Thomas Jensen, Denmark

3 3

Possible FTS language detection packaging issue in Dovecot 2.4.x Debian packages
by Jens Urban 26 May '26

26 May '26

Hello, Is anyone running Dovecot 2.4.4 with multilingual FTS flatcurve on Debian 12/13, using the packages from Dovecot.org? I suspect a packaging/build issue related to language detection. It looks like libexttextcat is not included in the Debian build. Simple reproduction with doveadm: doveadm fts tokenize -u localpart@domain 'This is the house. Das ist das Haus‘ —> Warning: Can't detect its language - assuming de …… My suspicion: If the "libexttextcat-dev" package was not installed during the "configure" step of the package creation process, then "HAVE_LANG_EXTTEXTCAT" will not be set. And if the define "HAVE_LANG_EXTTEXTCAT" is not set during the compilation of "src/lib-language/language.c", then "language_textcat_init" always returns "LANGUAGE_DETECT_RESULT_UNKNOWN;". Consequently, doveadm invariably translates this return value into the message: "Warning: Can't detect its language - assuming $DEFAULT-LANG". If I download the source code from Dovecot.org and build the dovecot vendor package myself, "language detection" works—provided that "libexttextcat-dev" has been installed beforehand. My simple test to check whether the installed version contains „libexttextcat“: (My build finds references to libexttextcat; the build from Dovecot.org finds none.) nm --print-file-name --dynamic --undefined-only /usr/lib/x86_64-linux-gnu/dovecot/* | grep textcat —> /usr/lib/x86_64-linux-gnu/dovecot/libdovecot-language.so.0.0.0: U special_textcat_Init —> /usr/lib/x86_64-linux-gnu/dovecot/libdovecot-storage.so.0.0.0: U textcat_ReleaseClassifyFullOutput Background: In my self-built package, exttextcat-related symbols appear in both libdovecot-language and libdovecot-storage; I assume this is expected due to the build/link layout. Regards, Jens Hello, Is anyone running Dovecot 2.4.4 with multilingual FTS flatcurve on Debian 12/13, using the packages from Dovecot.org? I suspect a packaging/build issue related to language detection. It looks like libexttextcat is not included in the Debian build. Simple reproduction with doveadm: doveadm fts tokenize -u localpart@domain 'This is the house. Das ist das HausaEUR~ aEUR"> Warning: Can't detect its language - assuming de aEUR|aEUR| My suspicion: If the "libexttextcat-dev" package was not installed during the "configure" step of the package creation process, then "HAVE_LANG_EXTTEXTCAT" will not be set. And if the define "HAVE_LANG_EXTTEXTCAT" is not set during the compilation of "src/lib-language/language.c", then "language_textcat_init" always returns "LANGUAGE_DETECT_RESULT_UNKNOWN;". Consequently, doveadm invariably translates this return value into the message: "Warning: Can't detect its language - assuming $DEFAULT-LANG". If I download the source code from Dovecot.org and build the dovecot vendor package myself, "language detection" worksaEUR"provided that "libexttextcat-dev" has been installed beforehand. My simple test to check whether the installed version contains aEURzlibexttextcataEURoe: (My build finds references to libexttextcat; the build from Dovecot.org finds none.) nm --print-file-name --dynamic --undefined-only /usr/lib/x86_64-linux-gnu/dovecot/* | grep textcat aEUR"> /usr/lib/x86_64-linux-gnu/dovecot/libdovecot-language.so.0.0.0: U special_textcat_Init aEUR"> /usr/lib/x86_64-linux-gnu/dovecot/libdovecot-storage.so.0.0.0: U textcat_ReleaseClassifyFullOutput Background: In my self-built package, exttextcat-related symbols appear in both libdovecot-language and libdovecot-storage; I assume this is expected due to the build/link layout. Regards, Jens

1 0

dovecot 2.4.4 community edition, bug in variables
by Terry Braun 23 May '26

23 May '26

I'm using this passdb sql to a postgres db passdb sql { query = SELECT NULL AS password, 'Y' as nopassword, userid AS user \ FROM users \ WHERE addr = '%{user}' AND password = '%{password}' } This succeed and the addr passed in as user is foo(a)example.com as expected I use this userdb sql userdb sql { query = SELECT home, uid, gid \ FROM users \ WHERE addr = '%{user}' # For using doveadm -A: # iterate_query = SELECT userid AS username, domain FROM users } This fails because postgres receives just "foo" not "foo(a)example.com" as user. maybe there is a bug in my stuff but I cannot see it. I can see the query in the postgres log where it clearly says: WHERE addr = 'foo' It also logs the passdb query: WHERE addr = 'foo(a)example.com' AND password='secret' thanks Terry

2 2

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

22 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

3 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

warning: /usr/lib/postfix/sbin/virtual: bad command startup -- throttling
by David Koski 22 May '26

22 May '26

Hello, I have set up a new dovecot mail server using MySQL backend. All users, passwords and related data are in SQL. I'm seeing the following warning in the mail.log file: warning: /usr/lib/postfix/sbin/virtual: bad command startup -- throttling It appears to have no impact on mail delivery. Since paths to user directories are yielded by the SQL database, I'm left wondering why this is even a warning. Regards, David Koski dkoski(a)sutinen.com # 2.4.1-4 (7d8c0e5759): /etc/dovecot/dovecot.conf # Pigeonhole version 2.4.1-4 (0a86619f) # OS: Linux 6.12.69+deb13-amd64 x86_64 Debian 13.5 # Hostname: B914839.online-server.cloud # 4 default setting changes since version 2.4.0 dovecot_config_version = 2.4.0 auth_debug = yes auth_debug_passwords = yes auth_mechanisms = plain login gssapi cram-md5 digest-md5 debug_log_path = /var/log/dovecot/debug.log default_vsz_limit = 512M dovecot_storage_version = 2.4.0 fts_autoindex = yes fts_autoindex_max_recent_msgs = 999 fts_search_add_missing = yes info_log_path = /var/log/dovecot/info.log lda_mailbox_autocreate = yes lda_mailbox_autosubscribe = yes log_debug = category=auth log_path = /var/log/dovecot/dovecot.log mail_driver = maildir mail_plugins { quota = yes } mailbox_directory_name_legacy = no protocols { imap = yes lmtp = yes sieve = yes } quota_exceeded_message = User %{user} has exceeded the storage volume. / User %{user} has exhausted allowed storage space. sieve_plugins { sieve_imapsieve = yes sieve_extprograms = yes } sql_driver = mysql ssl = required namespace inbox { inbox = yes prefix = separator = . type = private mailbox Drafts { auto = subscribe special_use = "\\Drafts" } mailbox Outbox { special_use = "\\Drafts" } mailbox Junk { auto = subscribe special_use = "\\Junk" } mailbox "Junk Email" { auto = no special_use = "\\Junk" } mailbox "Junk E-mail" { auto = no special_use = "\\Junk" } mailbox Trash { auto = subscribe special_use = "\\Trash" } mailbox "Deleted Items" { auto = no special_use = "\\Trash" } mailbox Spam { auto = no special_use = "\\Junk" } mailbox Archives { auto = no special_use = "\\Archive" } mailbox Sent { auto = subscribe special_use = "\\Sent" } mailbox "Sent Items" { auto = no special_use = "\\Sent" } mailbox "Sent Messages" { auto = no special_use = "\\Sent" } } service imap-login { inet_listener imap { } inet_listener imaps { } } service pop3-login { inet_listener pop3 { } inet_listener pop3s { } } service submission-login { inet_listener submission { } inet_listener submissions { } } service lmtp { unix_listener /var/spool/postfix/private/dovecot-lmtp { group = postfix mode = 0600 user = postfix } } service imap { } service pop3 { } service submission { } service auth { unix_listener auth-userdb { group = postfix } unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } } service auth-worker { } service dict { unix_listener dict { } } ssl_server { cert_file = /etc/letsencrypt/live/mail.sutinen.com/fullchain.pem key_file = /etc/letsencrypt/live/mail.sutinen.com/privkey.pem } protocol lda { mail_plugins { sieve = yes quota = yes } } protocol imap { mail_plugins { imap_sieve = yes } } protocol lmtp { mail_plugins { quota = yes sieve = yes notify = yes push_notification = yes } postmaster_address = postmaster(a)sutinen.com } service managesieve-login { inet_listener sieve { port = 4190 } inet_listener sieve_deprecated { port = 2000 } } service managesieve { } sieve_script personal { active_path = /var/vmail/sieve/%{user | domain }/%{user | username }/active-script.sieve driver = file path = /var/vmail/sieve/%{user | domain }/%{user | username }/scripts type = personal } sieve_script spam-global { path = /var/vmail/sieve/global/spam-global.sieve type = before } mailbox Spam { sieve_script spam { cause = copy path = /var/vmail/sieve/global/learn-spam.sieve type = before } } imapsieve_from Spam { sieve_script ham { cause = copy path = /var/vmail/sieve/global/learn-ham.sieve type = before } } mysql /var/run/mysqld/mysqld.sock { dbname = vmail password = # hidden, use -P to show it user = vmail } passdb sql { driver = sql query = CALL password_query('%{user}', '%{password}') } userdb sql { driver = sql query = CALL user_query_dovecot('%{user | username}', '%{user | domain}') }

3 2

Dovecot 2.4 authentication
by David Koski 22 May '26

22 May '26

Hello, I just put a new Postfix with Dovecot 2.4 server on line migrating the email from Dovecot 2.3. I have discovered a number of clients (all copiers so far) that no longer authenticate SMTP. Mechanisms configured: auth_mechanisms = plain login gssapi cram-md5 digest-md5 I found that if I disable all encrypted password methods (some copiers list them separately with a checkbox) and leave only plain/login on the client side, then it succeeds. But sometimes it is not necessary. It's almost as if it only tries once and gives up if it fails. I'm not sure how it is actually supposed to work. But it worked with Dovecot 2.3. I did test one account with an encrypted password like "{CRAM-MD5}6e3..." successfully. But other accounts failed. It almost looks like the encryption method must be specified on the client side to match the server before it will work consistently. I know that password encryption is unnecessary with STARTTLS but I have to live with it now. I have noticed that Thunderbird configured with encryption silently falls back to plain/login so I didn't notice a problem. Regards, David Koski dkoski(a)sutinen.com

2 4

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

"imap" command not usable in dovecot 2.4
by Mark Hills 20 May '26

20 May '26

Since upgrading to 2.4 (from 2.3) the "imap" command no longer works: $ /usr/libexec/dovecot/imap * PREAUTH [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS BINARY MOVE REPLACE SNIPPET=FUZZY PREVIEW=FUZZY PREVIEW SPECIAL-USE STATUS=SIZE SAVEDATE COMPRESS=DEFLATE INPROGRESS NOTIFY LITERAL+] Logged in as mark imap(mark)<6109><5GlNEEHaDWrdFwAABxE9Dg>: Fatal: Namespace inbox: mail_storage settings: Failed to parse configuration: Invalid setting mail_path=~/Maildir: mail_path setting used home directory (~/) but there is no mail_home and userdb didn't return it Whereas I would expect an authenticated IMAP session. Removing the offending /etc/dovecot.conf line temporarily: dovecot_config_version = 2.4.1 dovecot_storage_version = 2.4.0 protocols = imap lmtp sieve mail_driver = maildir #mail_path = ~/Maildir passdb passwd-file { passwd_file_path = /etc/dovecot/passwd } userdb passwd { } [...] And re-testing suggests the cause runs deeper: $ /usr/lib/exec/dovecot/imap [...] imap(mark)<6364><tetIC6/aDWrcGAAABxE9Dg>: Fatal: Namespace inbox: mail_storage settings: Failed to parse configuration: Failed to expand mail_path setting variables: Setting used home directory (%h) but there is no mail_home and userdb didn't return it Attempts to hard-wire it seem to suggest that usedb is not involved. I imagine this may be not consulted, because the process is pre-authenticated and running as a local UID: userdb passwd { fields_import_all = no fields { mail_home = /home/mark mail_path = /home/mark/Maildir } } $ /usr/libexec/dovecot/imap [...] imap(mark)<6656><qPqUB17cDWoAGgAABxE9Dg>: Fatal: Namespace inbox: mail_storage settings: Failed to parse configuration: Failed to expand mail_path setting variables: Setting used home directory (%h) but there is no mail_home and userdb didn't return it It seems like 2.3 looked up these fields from the user invoking it, but no longer is this the case? Running "imap" like this is very useful, especially when a client like Pine/Alpine can access over SSH. To get to here I had to workaround the missing "shadow" passdb module, which is also useful as Alpine Linux 3.23 neither uses PAM extensively nor provides dovecot built with PAM. -- Mark

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

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

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

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

Dovecot and Pigeonhole v2.4.4 Released
by Aki Tuomi 12 May '26

12 May '26

Hi! We are happy to publish version 2.4.4 of Dovecot and Pigeonhole. These contain CVEs, discovered by external researches. The majority of these have been discovered with help of automated code analysis tools like claude code security, which is why some of these are rather old, missed bugs. No new supported distros have been added or old removed, no new dependencies have been added. Note that there are experimental features in 2.4, one is enabled with `--enable-experimental-mail-utf8`, and another with `--enable-experimental-imap4rev2`, and you also need to set mail_utf8_extensions=yes and imap4rev2_enabled=yes to enable them in config. https://dovecot.org/releases/2.4/dovecot-2.4.4.tar.gz https://dovecot.org/releases/2.4/dovecot-2.4.4.tar.gz.sig https://pigeonhole.dovecot.org/releases/2.4/dovecot-pigeonhole-2.4.4.tar.gz https://pigeonhole.dovecot.org/releases/2.4/dovecot-pigeonhole-2.4.4.tar.gz… Binary packages in https://repo.dovecot.org/ Docker images in https://hub.docker.com/r/dovecot/dovecot --- * CVE-2026-27851: lib-var-expand: Safe filter marks all following pipelines safe. * CVE-2026-33603: auth: CRAM-SHA-*-PLUS channel binding could be faked. MITM attacker with a certificate trusted by the client could have bypassed the requirement for channel binding. * CVE-2026-40020: IMAP folders can be shared-spammed to everyone. * CVE-2026-42006: An attacker can cause uncontrolled memory usage with excessive bracing over IMAP. The fix in CVE-2026-27857 was incomplete. * indexer-worker, quota-status, script-login, program-client-local: Root privileges are now dropped permanently before serving requests. * indexer-worker: Default restart_request_count changed to 1 to work correctly after permanent root privilege drop. * lmtp: Add back service_extra_groups=$SET:default_internal_group that was incorrectly removed in v2.4.3. * master: inet_listener_reuse_port has been replaced by service_reuse_port. The new setting properly pre-creates all listener sockets at startup and assigns one unique socket per process. Using this allows evenly distributing incoming connections to login processes. See https://doc.dovecot.org/latest/core/config/service.html#service_reuse_port for details. - auth: Fix LDAP escaping of 0x13 control character. - auth: Use timing-safe comparison for certificate and public key fingerprints. - fts: Correctly handle internal http-client response errors. - fts: Don't send request to Tika if there is no body text. - fts: Fix address header indexing for RFC 2047 encoded-words. - fts: tika, fts-solr: Fix use-after-free crash during DNS lookup. - imap: Fix assertion panic on invalid REPLACE 0 command. - lib-auth-client: Avoid "unknown id" errors for aborted auth requests. - lib-dcrypt: Fix potential crash if trying to access untrusted/corrupted keys. - lib-dcrypt: Improve error message if keys aren't in hex format as expected. - lib-index: Fix potential crash if fsck fails. - lib-ldap: Fix using OpenLDAP default CA when ssl_client_ca_dir/file is unset. v2.4.3 regression. - lib-master, master: Fix behavior for services with client_limit>1 and restart_request_count so that processes reaching restart_request_count are no longer counted towards process_limit. - lib-master: Fix crash when reaching client_limit with restart_request_count>1. - lib-master: haproxy - Don't trust client certificate common name when HAProxy reports verification failure. - lib-sasl: cram-md5 - Fix out of bounds memory read. - lib-sasl: oauth2 - Fix one byte out of bounds read. - lib-sql: cassandra - Fix reusing Cassandra SSL connections. - lib-sql: sqlite - Fix sqlite_journal_mode=wal to actually work. - lib-storage: Auto-rename non-NFC subscription file entries to NFC on read. - lib-storage: Prevent non-atom SEARCH keywords from causing IMAP command injection. - lib-var-expand-crypt: Return error if hex decoding fails. - lib-var-expand: Fix crash (SIGFPE) with non-positive divisor for / and %. - log: Fix memory leak at deinit. - login-common: When process is full, don't destroy clients waiting on master auth. - login-proxy: Fix crash with rawlog and multiplexing during reconnection. - mail-compress: Fix panic when save method unavailable. - mail-crypt: Fix crash when HMAC-based algorithm is used. - mail-crypt: Use AEAD instead of HMAC with ChaCha20-Poly1305. - mdbox: Create files with O_NOFOLLOW. - push-notification: ox - Fix use-after-free crash during DNS lookup. - quota: quota-status - Limit input buffer size to 1 kB. ––- * CVE-2026-40016: sieve :contains and :matches operators could have been using excessive amount of CPU. Limit the CPU to sieve_max_cpu_time. - Fix potential crashes parsing corrupted Sieve binaries. - lib-sieve: matches - Fix trailing literal match when it fills value exactly. v2.4.3 regression.

2 2

Dovecot Security Advisory OXDC-2026-0002
by Aki Tuomi 12 May '26

12 May '26

Hi! We're sharing our latest advisory with you and like to thank everyone who contributed in finding and solving those vulnerabilities. This advisory is also published at https://documentation.open-xchange.com/dovecot/security/advisories/html/202… --- Classification: TLP:GREEN Internal reference: DOV-8967 Type: CWE-235 (Improper Handling of Extra Parameters) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Last affected revision: OX Dovecot Pro core 3.1.4, OX Dovecot CE core 2.4.3 First fixed revision: OX Dovecot Pro core 3.1.5, OX Dovecot CE core 2.4.4 Discovery date: 2026-03-29 Solution date: 2026-05-05 Disclosure date: 2026-05-05 Researcher credits: caprinuxx@yeswehack CVE: CVE-2026-27851 CVSS: 7.4 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) Details: lib-var-expand: Safe filter leaks to all following pipelines. When safe filter is used with variable expansion, all following pipelines on the same string are incorrectly interpreted as safe too, enabling unsafe data to be unescaped. Risk: This can enable SQL / LDAP injection attacks when used in authentication. No publicly available exploits are known. Solution: Avoid using safe filter until on fixed version. --- Internal reference: DOV-8948 Type: CWE-400 (Uncontrolled Resource Consumption) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Last affected revision: OX Dovecot Pro core 2.3.0 First fixed revision: OX Dovecot Pro core 3.1.5, OX Dovecot CE core 2.4.4 Discovery date: 2026-03-24 Solution date: 2026-05-05 Disclosure date: 2026-05-05 Researcher credits: djvirus@yeswehack CVE: CVE-2026-40016 CVSS: 5.3 (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H) Details: Sieve :contains/:matches O(N×M) Substring Match Bypasses sieve_max_cpu_time Limit (130× Overrun). Attacker can upload a malicious Sieve script over ManageSieve service (or locally) to bypass configured CPU time limits for Sieve up to 130 times of the configured limit. Risk: Attacker can use this to degrade server performance and bypass configured CPU time limits for Sieve scripts. No publicly available exploits are known. Solution: Install fixed version, or alternatively prevent direct access to Sieve scripts via ManageSieve or local access. --- Internal reference: DOV-9030 Type: CWE-99 (Improper Control of Resource Identifiers ('Resource Injection')) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Last affected revision: OX Dovecot Pro core 3.1.0, OX Dovecot CE core 2.4.0 First fixed revision: OX Dovecot Pro core 3.1.5, OX Dovecot CE core 2.4.4 Discovery date: 2026-04-08 Solution date: 2026-05-05 Disclosure date: 2026-05-05 Researcher credits: ylwango613@yeswehack CVE: CVE-2026-33603 CVSS: 6.8 (CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) Details: login: Base64 input can contain tabs that bypass IPC protection. Attacker can use a specially crafted base64 exchange between Dovecot and Client to fake SCRAM TLS channel binding. This requires that the attacker is able to position itself between Dovecot and the client connection. Risk: If successful, the attacker can eavesdrop communications between Dovecot and client as MITM proxy. No publicly available exploits are known. Solution: Install fixed version. --- Internal reference: DOV-9040 Type: CWE-284 (Improper Access Control) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Last affected revision: OX Dovecot Pro core 2.3.0 First fixed revision: OX Dovecot Pro core 3.1.5, OX Dovecot CE core 2.4.4 Discovery date: 2026-04-08 Solution date: 2026-05-05 Disclosure date: 2026-05-05 Researcher credits: ilhamaf@yeswehack CVE: CVE-2026-40020 CVSS: 3.1 (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L) Details: IMAP folders can be shared-spammed to everyone. Attacker can use the IMAP SETACL command to inject the anyone permission to user's dovecot-acl file even if imap_acl_allow_anyone=no. This causes folders to be spammed to all users. Risk: The impact is limited to being able to spam folders to other users, no unexpected access is gained. No publicly available exploits are known. Solution: Install to fixed version. --- Internal reference: DOV-9138 Type: CWE-400 (Uncontrolled Resource Consumption) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Last affected revision: OX Dovecot Pro core 3.0.5, OX Dovecot Pro core 3.1.4, OX Dovecot CE core 2.4.3 First fixed revision: OX Dovecot Pro core 3.1.5, OX Dovecot CE core 2.4.4 Discovery date: 2026-04-27 Solution date: 2026-05-05 Disclosure date: 2026-05-05 Researcher credits: D4RKCYPH3R@yeswehack CVE: CVE-2026-42006 CVSS: 4.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L) Details: imap-login: Excessive memory usage DoS - Try 2. An attacker can cause uncontrolled memory usage with excessive bracing over IMAP. The fix in CVE-2026-27857 was incomplete, only blocking one way of doing this, so there was still another way left open. In particular, the fix was for closing braces, but you could still use open braces to bypass the limit. Risk: Using excessive bracing, attacker can cause memory usage up to configured memory limit. No publicly available exploits are known. Solution: Install fixed version, or configure vsz_limit for imap process to low value.

1 0

Changed location of index files
by Lafiel Elentari 11 May '26

11 May '26

Hello. After upgrading to version 2.4, index files were moved to the user's home directory, and the `mail_path = ~/mail` parameter was no longer taken into account when processing index files. In addition, indexes for the `INBOX` folder no longer respect the `mail_index_path=` parameter and are stored in the `./INBOX/dovecot.index.*` folder, although they should be stored in the same folder where the messages are stored, given the current configuration. My configuration: ``` mail_home = mail_inbox_path = mail_index_path = mail_path = ~/mail userdb declarative { passwd_file_path = /var/data/mail/dovecot/passdb driver = passwd-file fields { home = /var/data/mail/vmail/%{user | domain}/%{user | username} mail_index_path = /var/data/mail/vmail/%{user | domain }/%{user | username} } } ``` Current location of index files: ``` /var/data/mail/vmail/example.com/user ├── INBOX │ ├── dovecot.index.cache │ └── dovecot.index.log ├── Sent │ ├── dovecot.index.cache │ └── dovecot.index.log ├── Drafts │ └── dovecot.index.log ├── Junk │ └── dovecot.index.log ├── Trash │ ├── dovecot.index.cache │ └── dovecot.index.log ├── dovecot.list.index ├── dovecot.list.index.log └─── mail ├── cur ├── new ├── tmp ├── Sent │ ├── cur │ ├── new │ ├── tmp │ └── dovecot-uidlist ├── Drafts │ ├── cur │ ├── new │ ├── tmp │ └── dovecot-uidlist ├── Junk │ ├── cur │ ├── new │ ├── tmp │ └── dovecot-uidlist ├── Trash │ ├── cur │ ├── new │ ├── tmp │ └── dovecot-uidlist ├── subscriptions ├── dovecot.mailbox.log ├── dovecot-uidlist ├── dovecot-uidvalidity └── dovecot-uidvalidity.69d94118 ``` Expected location of index files according to configuration: ``` /var/data/mail/vmail/example.com/user └─── mail ├── cur ├── new ├── tmp ├── Sent │ ├── cur │ ├── new │ ├── tmp │ ├── dovecot.index │ ├── dovecot.index.cache │ ├── dovecot.index.log │ └── dovecot-uidlist ├── Drafts │ ├── new │ ├── tmp │ ├── cur │ ├── dovecot.index │ ├── dovecot.index.cache │ ├── dovecot.index.log │ └── dovecot-uidlist ├── Junk │ ├── new │ ├── tmp │ ├── cur │ ├── dovecot.index │ ├── dovecot.index.cache │ ├── dovecot.index.log │ └── dovecot-uidlist ├── Trash │ ├── cur │ ├── new │ ├── tmp │ ├── dovecot.index │ ├── dovecot.index.cache │ ├── dovecot.index.log │ └── dovecot-uidlist ├── dovecot.index ├── dovecot.index.cache ├── dovecot.index.log ├── dovecot.list.index ├── dovecot.list.index.log ├── dovecot.mailbox.log ├── dovecot-uidlist ├── dovecot-uidvalidity ├── dovecot-uidvalidity.69d94118 └── subscriptions ``` -- Best regards, Lafiel Elentari mailto:lafiel@elven.pw

2 2

Dovecot 2.3.21.1 missing dbox-Mails folder causes IMAP folder which can not be deleted? Possible known bug?
by Benoit Panizzon 11 May '26

11 May '26

Hi Team Running Dovecot 2.3.21.1 in an ISP environment using dbox format as storage and built in dovecot replication to a secondary storage. => I know, it's not new - migration to 2.4 with completely replacing replication is pending. For quite some time we are fighting issues with customers which are unable to delete IMAP folder. Those folder end up in status \NoSelect When you issue a 'delete' for the folder, it is successful, but either the folder is back after logout/login or back right away when you list the folders. Usual remedy: completely delete mail index of affected mailbox on both, primary and secondary storage, delete complete mail storage on secondary, resync with doveadm force-resync, cross filters. Now I had a mailbox where even this did not solve the issue - but I noticed something weird. . delete "mailbox" => OK . delete "mailbox" => OK . create "mailbox" => OK . create "mailbox" => Mailbox does already exist . delete "mailbox" => OK . delete "mailbox" => Mailbox does not exist Now the Mailbox is gone from the file system and is not shown with list anymore. Now I had a closer look at the next affected mailbox on the filesystem. IMAP Foldername: LIST (\Noselect \HasNoChildren) "." INBOX.brokenmbox Filesystem, directories: INBOX/brokenmbox/ => There is no content, no hidden files inside the folder 'broeknmbox' . delete "INBOX.brokenmbox" => OK Checking Filesystem. Nothing changed, still the same. . create "INBOX.brokenmbox" => OK Checking Filesystem: Now we have: INBOX/broeknmbox/dbox-Mails/ all empty. . delete "INBOX.brokenmbox" => OK Checking Filesystem: broeknmbox/dbox-Mails/ are both gone within INBOX! Conclusion: Dovecot seems to get confused, when a directory without dbox-Mails subdirectory exists, fails to delete such directories but still lists them as IMAP folders. Is this a known bug? Is there anything which is know to cause this issue which we could tweak at our configuration? Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

1 0

Migration Planning for Dovecot 2.3 to 2.4
by Gregory Carter 05 May '26

05 May '26

Hello so I have started planning my 2.3 to 2.4 migration and finished the lab work today for that process. Does anyone know of any tools to migrate the configs from 2.3 to 2.4? Also if you are running 2.4 I would like to hear from you as to how well it is working out. Thanks. Hello so I have started planning my 2.3 to 2.4 migration and finished the lab work today for that process. Does anyone know of any tools to migrate the configs from 2.3 to 2.4? Also if you are running 2.4 I would like to hear from you as to how well it is working out. Thanks.

8 12

Dovecot sieve, help !
by Tommy Berglund 03 May '26

03 May '26

Hi! I need help and advice on how to get sieve working. Postfix dovecot works to receive and send mail but I can't get sieve to work. Domain and user are virtual in mariadb. Tips are welcome. Doveconf -n attached.

3 4

mail_inbox_path in manual
by Daniel Convissor (business) 01 May '26

01 May '26

Hi: Recently upgraded Debian to version 13/Trixie, which brings Dovecot up to 2.4 (with its significant configuration file changes). As mentioned on this list, Debian decided to manually put mail_inbox_path in their distribution's config files (and set it to /var/mail/%{user}).[1] This resulted in mayhem for me because that's not where our mail is. I assume this has happened to others as well. I figured out the problem by looking at mail.log after adding mail_debug=yes to my local Dovecot config file. Perhaps Dovecot's manual can be updated to clarify the situation, please? The Mail Location page[2] warns admins to not touch this setting. The upgrade page[3] does not mention needing to look out for Debian's choice. (Granted, this is a Debian problem, but the Dovecot manual is where people turn to figure out what is happening.) Thank you, --Dan [1] https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/message/Q6HI… [2] https://doc.dovecot.org/2.4.3/core/config/mail_location.html#mail_inbox_path [3] https://doc.dovecot.org/2.4.3/installation/upgrade/2.3-to-2.4.html -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y Designing transportation systems everyone can use https://www.AnalysisAndSolutions.com/

1 0

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

Is this a bug of `doveadm mailbox metadata set` with `-A` and `-s ""`
by Zhang Huangbin 24 Apr '26

24 Apr '26

Dear all, Recently i encountered an issue with `doveadm mailbox metadata set` (and `unset`) with either `-A` or `-F <path>`. When i run `doveadm mailbox metadata set` for single user, it correctly generates content in `dovecot-attributes` file: ``` doveadm mailbox metadata set -u <email> -s "" "/private/vendor/vendor.dovecot/http-notify" "user=all" ``` But if i run with `-A`, or `-F <path>`, Dovecot generates incorrect "path" and unreadable characters in `dovecot-attributes` file: ``` # doveadm mailbox metadata set -A -s "" "/private/vendor/vendor.dovecot/http-notify" "user=all" # for i in $(find . -name 'dovecot-attributes'); do echo $i; cat $i; done priv/4898662293abe1690d9a000063130d18/vendor/vendor.dovecot/pvt/server/?????? user=all priv/90e7b40fc8c1e9690924000063130d18/vendor/vendor.dovecot/pvt/server/vendor/vendor.dovecot/http-notify user=all priv/60ba353790c1e969f923000063130d18/vendor/vendor.dovecot/pvt/server/endor.dovecot/pvt/server/CV?? user=all ``` It's ok if i specify the mailbox in -s, for example: `-s "INBOX"`, `-s "Sent"`, but it's not what i want, because only emails delivered to specified mailbox will be pushed. Is this a bug?

1 1

[Bug Report] anvil panic: anvil-connection.c:727: unreached triggered by duplicate imap-login handshake with pid=-1
by Jeff Aitken 24 Apr '26

24 Apr '26

Environment: FreeBSD 14.4-RELEASE Dovecot 2.4.3 (e278b1e09b) Pigeonhole 2.4.3 (0bf9ee48) Postfix 3.11.1, rspamd 4.0.0 Description: The dovecot anvil process is crashing repeatedly with a panic in anvil-connection.c at line 727. The panic is triggered by i_unreached() in anvil_connection_destroy(). Total of ~18 crashes in the last 24 hours, happens to multiple users. The anvil process restarts successfully and works as expected other than the crashes. No other symptoms that I can see that appear related. Log messages: dovecot[87542]: anvil: Panic: file anvil-connection.c: line 727: unreached dovecot[87542]: anvil: Fatal: master: service(anvil): child 88408 killed with signal 6 (core not dumped) dovecot[87542]: anvil: Error: connect limit: disconnection for unknown (pid=88756, user=<username>, service=imap, ip=X.X.X.X, ...) dovecot[87542]: anvil: Warning: conn unix:anvil (uid=0): Handshake with duplicate service=imap-login pid=-1 - replacing the old connection Analysis (from claude): In anvil_connection_destroy(), when conn->added_to_hash is true, the code asserts that the connection must still be present in anvil_connections_hash. However, when a duplicate handshake is received for the same (service, pid) key, the old connection appears to be evicted from the hash table without clearing its added_to_hash flag. When the old connection is subsequently destroyed, hash_table_lookup_full() fails to find it, triggering i_unreached(). The pid=-1 in the duplicate handshake warning is also notable — this does not appear to be a valid process ID and may indicate that the handshake is being sent before the imap-login process has fully initialized. Workaround: Setting service_restart_request_count = unlimited and service_process_min_avail = 2 on the imap-login service seems to have reduces process turnover and appears to have reduced the frequency of the crash, but I’ve only got a couple of hours since that change so too early to say for sure. Suggested fix: When a duplicate handshake causes an existing connection to be evicted from anvil_connections_hash, the evicted connection's added_to_hash flag should be cleared to prevent the assertion failure in anvil_connection_destroy(). Appreciate any insight, and happy to provide additional info that would be helpful. —Jeff

1 0

Unable to get Dovecot 2.4 to allow unencrypted connection
by David Koski 24 Apr '26

24 Apr '26

Hello, In spite of: ssl = no auth_allow_cleartext = yes ..in a telnet session, I get: * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ STARTTLS LOGINDISABLED AUTH=GSSAPI AUTH=CRAM-MD5] Dovecot (Debian) ready. a1 login ln(a)zample.com <super-secret> * BAD [ALERT] Plaintext authentication not allowed without SSL/TLS, but your client did it anyway. If anyone was listening, the password was exposed. a1 NO [PRIVACYREQUIRED] Plaintext authentication disallowed on non-secure (SSL/TLS) connections. I need to see the network traffic to troubleshoot the way Outlook 2019 handles IMAP folders. Regards, David Koski dkoski(a)sutinen.com

3 9

Re: large mbox files
by Joseph Tam 23 Apr '26

23 Apr '26

On Wed, 22 Apr 2026, Marc wrote: > How are messages deleted from large mbox files, are these files > completely rewritten? I can't really believe that as some are bigger > than the free disk space available. I think it's a little better than that: bytes are shuffled up to fill the deleted message hole. I gather this from noting the difference in operation time from deleting a message from the top vs bottom of a large mailbox. Joseph Tam <jtam.home(a)gmail.com>

1 0

large mbox files
by Marc 23 Apr '26

23 Apr '26

How are messages deleted from large mbox files, are these files completely rewritten? I can't really believe that as some are bigger than the free disk space available.

2 1

doveadm expunge silently ignores multiple -u flags instead of erroring or processing all users
by Robert Kretowicz 21 Apr '26

21 Apr '26

Hello, I would like to report what I believe is a bug in doveadm expunge argument handling. Summary When multiple -u flags are passed to doveadm expunge, for example: doveadm expunge -u user1 -u user2 -u user3 mailbox '*' BEFORE 2015-01-01 the command exits with code 0 (success) but only processes one of the specified users. The remaining users are silently skipped with no warning or error message produced. Why this is a bug This is a silent failure on a destructive, irreversible operation. An administrator has no indication that most users were not processed. Good CLI tools should either: Accept multiple -u flags and process all specified users (consistent with how -F file works), or Reject the command immediately with a clear error such as: Error: -u flag specified multiple times. Use -F <file> for multiple users. Silently accepting invalid input and doing something unpredictable is the worst possible outcome, especially for a mail expunge operation. Environment OS: Debian GNU/Linux 12 (Bookworm) Dovecot version: 2.3.x (from Debian package) doveconf -n output available on request — omitted due to containing internal domain names. Workaround I am currently using bashfor user in user1 user2 user3; do doveadm expunge -u "$user" mailbox '*' BEFORE 2015-01-01 done Thank you for your time. Robert Kretowicz

2 1

Master user login attempted without master passdbs
by horst.simon.aus＠gmail.com 21 Apr '26

21 Apr '26

Hi, I have dovecot version v2.3.21.1 and my users (username(a)domain.name) are in mysql, all can logon to imap and sending mail, but when I am trying to create and enable sieve scripts from an weblient (horde webmail) it fails with authentication errors. It tries to use master user authentication and the logs are showing following: A pr 15 10:34:51 auth: Debug: client in: AUTH 1 PLAIN service=sieve secured session=yTdN4nRPFcF/AAAB lip=127.0.0.1 rip=127.0.0.1 lport=4190 rport=49429 resp=aG9yc3QAaG9yc3RAaGJzaW1vbi5uZXQAYXVnQDYmOXVzdA== (previous base64 data may contain sensitive data) Apr 15 10:34:51 auth: Info: plain(horst(a)hbsimon.net,127.0.0.1,<yTdN4nRPFcF/AAAB>): login user: Master user login attempted without master passdbs Apr 15 10:34:51 auth: Debug: auth(horst(a)hbsimon.net,127.0.0.1,<yTdN4nRPFcF/AAAB>): Auth request finished Apr 15 10:34:51 auth: Debug: auth client connected (pid=1478) Apr 15 10:34:53 auth: Debug: client passdb out: FAIL 1 user=horst(a)hbsimon.net Apr 15 10:34:53 managesieve-login: Info: Disconnected: Connection closed (auth failed, 1 attempts in 2 secs): user=<horst(a)hbsimon.net>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured, session=<yTdN4nRPFcF/AAAB> Apr 15 10:35:06 auth: Debug: client in: AUTH 1 PLAIN service=sieve secured session=VEgr43RPGMF/AAAB lip=127.0.0.1 rip=127.0.0.1 lport=4190 rport=49432 resp=aG9yc3QAaG9yc3RAaGJzaW1vbi5uZXQAYXVnQDYmOXVzdA== (previous base64 data may contain sensitive data) Apr 15 10:35:06 auth: Info: plain(horst(a)hbsimon.net,127.0.0.1,<VEgr43RPGMF/AAAB>): login user: Master user login attempted without master passdbs Apr 15 10:35:06 auth: Debug: auth(horst(a)hbsimon.net,127.0.0.1,<VEgr43RPGMF/AAAB>): Auth request finished Apr 15 10:35:06 auth: Debug: auth client connected (pid=1484) Apr 15 10:35:08 auth: Debug: client passdb out: FAIL 1 user=horst(a)hbsimon.net Apr 15 10:35:08 managesieve-login: Info: Disconnected: Connection closed (auth failed, 1 attempts in 2 secs): user=<horst(a)hbsimon.net>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured, session=<VEgr43RPGMF/AAAB> How can I bypass the master user login and use the assigned user or what should the master user be and how to create it? Thanks and Regards, Horst

4 7

Dovecot 2.4 SETQUOTA, how to allow (admin) users to set quota (and write it back to LDAP)
by Johannes Nohl 20 Apr '26

20 Apr '26

Is it true that Dovecot dismissed the functionality of SETQUOTA with version 2.4.0 - without any replacement? see https://dovecot.org/mailman3/archives/list/dovecot-news@dovecot.org/message… Does this also applies to 2.4.2 and 2.4.3, or does the mechanism of plugin imap_quota returned (manual reads that there are no options to this plugin)? IMAP always replies `c008 NO [NOPERM] Permission denied (0.001 + 0.000 secs).` If you can activate the former `quota_set` option, how to combine it with LDAP? I know that you can read Quota from LDAP with userdb field `quota_storage_size = {ldap:quotaBytes}B`. But how to set it? I also remember an old opinion that writing LDAP is to slow, you should store quota e.g. in a text file and write it back to LDAP time shifted. That would be fine for me - however, how to enable SETQUOTA then? Thank you for help. -- Johannes Nohl postmaster(a)i-t-cloud.de

3 3

Config: Reading value from file for password does not work
by René Neumann 19 Apr '26

19 Apr '26

Hi, I want to read the ldap auth-dn password from a file to avoid having it as part of the configuration (which may be checked into VCS). I specified ldap_auth_dn_password = </some/file where /some/file contains the password without extra whitespace (esp. there is no `\n`, I checked with xxd). But ldap auth does not succeed because of a wrong password. Password itself does work though, as checked with ldapsearch (even using the same file as password provider) `doveconf -x -P` *does* show the correct value. The same issue has been reported back in 2019 [1], without any reply though :-/ Any ideas? Thanks, René [1] https://dovecot.org/list/dovecot/2019-September/117100.html

2 3

[Bug Report] 2.4.3 on macOS: anvil panics at anvil-connection.c:727 on every IMAP client handshake
by I-K-D-T＠web.de 18 Apr '26

18 Apr '26

Hi Dovecot developers, I'm hitting a reproducible anvil panic on macOS when any IMAP client tries to connect. Every client handshake triggers an `i_unreached()` assertion in `anvil-connection.c:727`, causing the anvil child to be killed with SIGABRT. Dovecot keeps restarting anvil, but every subsequent connection attempt triggers the same panic, so the service effectively cannot accept logins. ## Environment - Dovecot: 2.4.3 (e278b1e09b), Pigeonhole 2.4.3 (0bf9ee48) -- from Homebrew - OS: macOS 15.6 (Sequoia, Darwin 24.6.0, arm64/Apple Silicon, APFS) - Mail client: Mozilla Thunderbird 149.0.2 - Dovecot started via `sudo brew services start dovecot` (launchd) ## Reproducing 1. Fresh macOS install of Dovecot 2.4.3 via Homebrew. 2. Configure a minimal single-user IMAP setup with `passdb static` / `userdb static`, SSL on port 993 with a self-signed cert, Maildir storage (config at end of this mail). 3. Start Dovecot as root via launchd (`sudo brew services start dovecot`). 4. Connect any IMAP client to localhost:993 (I used Thunderbird 149 with a permanent cert exception for the self-signed certificate). 5. The client hangs / reports "server closed the connection" / sees no folders. 6. `dovecot.log` fills with repeated entries like the following: ``` anvil: Warning: conn unix:anvil (uid=0): Handshake with duplicate service=imap-login pid=-1 - replacing the old connection anvil: Panic: file anvil-connection.c: line 727: unreached anvil: Error: Raw backtrace: 0 libdovecot.0.dylib backtrace_append + 72 -> 1 libdovecot.0.dylib backtrace_get + 44 -> 2 libdovecot.0.dylib default_fatal_finish + 72 -> 3 libdovecot.0.dylib default_error_handler -> 4 libdovecot.0.dylib i_internal_error_handler -> 5 libdovecot.0.dylib i_fatal -> 6 libdovecot.0.dylib default_write -> 7 anvil anvil_connection_input_line -> 8 libdovecot.0.dylib connection_input_read_stream + 196 -> 9 libdovecot.0.dylib connection_input_default + 72 -> 10 libdovecot.0.dylib io_loop_call_io + 116 -> 11 libdovecot.0.dylib io_loop_handler_run_internal + 284 -> 12 libdovecot.0.dylib io_loop_handler_run + 220 -> 13 libdovecot.0.dylib io_loop_run + 88 -> 14 libdovecot.0.dylib master_service_run + 292 -> 15 anvil main + 368 -> 16 dyld start + 6076 anvil: Fatal: master: service(anvil): child NNNN killed with signal 6 (core dumps disabled) ``` The key signature is the two-line sequence: ``` Warning: conn unix:anvil (uid=0): Handshake with duplicate service=imap-login pid=-1 - replacing the old connection Panic: file anvil-connection.c: line 727: unreached ``` Every IMAP client handshake produces this. The `pid=-1` in the handshake warning looks suspicious -- it appears anvil is either not receiving a valid pid from imap-login or is registering a second connection with the same service name before the first is cleaned up. ## Workarounds attempted (none succeeded) - User-level setup with default_login_user=andreas -> same panic - Root-level setup with default_login_user=andreas -> same panic - Root-level setup with default_login_user=_www (unprivileged macOS service account with uid=70) -> same panic - Adding `default_vsz_limit = unlimited` (required separately on macOS because setrlimit(RLIMIT_DATA) fails with EINVAL on Darwin) -> did not affect anvil - Plaintext IMAP on 143 (no TLS) vs. IMAPS on 993 with self-signed cert -> same panic in both - Restarting Dovecot via launchd (`sudo brew services stop/start dovecot`) -> the panic recurs on the next connection ## `doveconf -n` output ``` # 2.4.3 (e278b1e09b): /opt/homebrew/etc/dovecot/dovecot.conf # Pigeonhole version 2.4.3 (0bf9ee48) # OS: Darwin 24.6.0 arm64 apfs # Hostname: macbook-air-von-andreas.local dovecot_config_version = 2.4.3 auth_mechanisms = plain login default_internal_group = _www default_internal_user = _www default_login_user = _www default_vsz_limit = unlimited dovecot_storage_version = 2.4.3 info_log_path = /opt/homebrew/var/log/dovecot/dovecot-info.log listen = 127.0.0.1 log_path = /opt/homebrew/var/log/dovecot/dovecot.log mail_driver = maildir mail_gid = staff mail_home = /Users/andreas/mail/%{user} mail_path = /Users/andreas/mail/%{user} mail_uid = andreas protocols = imap ssl_server { cert_file = /opt/homebrew/etc/dovecot/ssl/dovecot.crt key_file = /opt/homebrew/etc/dovecot/ssl/dovecot.key } service imap-login { inet_listener imap { port = 143 } inet_listener imaps { port = 993 ssl = yes } } passdb static { password = # hidden } userdb static { fields { gid = staff home = /Users/andreas/mail/%{user} uid = andreas } } namespace inbox { mailbox_list_layout = fs inbox = yes prefix = separator = / } ``` ## What I would expect The anvil connection from imap-login should register with a valid pid (not -1) or anvil should tolerate the re-registration gracefully instead of hitting an i_unreached() assertion. ## Note on `dovecot-sysreport` Running `dovecot-sysreport` as the normal user fails with permission errors on `/opt/homebrew/var/run/dovecot/*` sockets (log-errors, master). The `grep -P` usage inside the script also fails on BSD grep (macOS). Let me know if a sysreport archive would be useful -- I can re-run with sudo and adjust grep if needed. Happy to provide further reproduction details, additional log output, or test any fix suggestions. Thanks for Dovecot. Andreas Marth I-K-D-T(a)web.de

2 1

still a compile error in 2.4.3
by matthias 14 Apr '26

14 Apr '26

Hi, I got this message while I compile the version 2.4.3: libtool: error: cannot find the library '../../src/lib-lua/libdovecot-lua.la' or unhandled argument '../../src/lib-lua/libdovecot-lua.la' Thanks Matthias

3 2

INBOX.dovecot.sieve not selectable
by 87auteur-niobium＠icloud.com 14 Apr '26

14 Apr '26

Hi folks, I’m seeing “INBOX.dovecot.sieve” listed on the response of the IMAP LIST command, but attempting to select the mailbox fails with “Internal server error occurred. Refer to the server log for more information”. I assume INBOX.dovecot.sieve is an internal/system folder that shouldn’t be on the LIST response. Is this a known issue? If it is, is it being tracked anywhere (I don’t see an “Issues” tab on GitHub for Dovecot Core)?

2 1

imap-login not passing DSN through
by Hadmut Danisch 14 Apr '26

14 Apr '26

Hi, I have a problem with postfix + dovecot 1:2.3.21+dfsg1-2ubuntu6.3 on Ubuntu Server 24.04: When using dovecot's imap-login to verify users and passwords againgst dovecot's user list, it doesn't pass the DSN flag through, therefore effectively disabling DSN. Postfix, submission port bound to 127.0.0.1, port 587: 250-myhostname 250-PIPELINING 250-SIZE 18432000 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-DSN 250-SMTPUTF8 250 CHUNKING but imap-login (configured to forward to 127.0.0.1:587): 250-myhostname 250-8BITMIME 250-AUTH PLAIN 250-BURL imap 250-CHUNKING 250-ENHANCEDSTATUSCODES 250-SIZE 250 PIPELINING So both the size limit and DSN are not passed through, SMTPUTF8 either. Even setting imap_capability = +DSN in 20-imap.conf doesn't help. What is keeping dovecot's imap-login from offering DSN? best regards Hadmut Hi, I have a problem with postfix + dovecot 1:2.3.21+dfsg1-2ubuntu6.3 on Ubuntu Server 24.04: When using dovecot's imap-login to verify users and passwords againgst dovecot's user list, it doesn't pass the DSN flag through, therefore effectively disabling DSN. Postfix, submission port bound to 127.0.0.1, port 587: 250-myhostname 250-PIPELINING 250-SIZE 18432000 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-DSN 250-SMTPUTF8 250 CHUNKING but imap-login (configured to forward to 127.0.0.1:587): 250-myhostname 250-8BITMIME 250-AUTH PLAIN 250-BURL imap 250-CHUNKING 250-ENHANCEDSTATUSCODES 250-SIZE 250 PIPELINING So both the size limit and DSN are not passed through, SMTPUTF8 either. Even setting imap_capability = +DSN in 20-imap.conf doesn't help. What is keeping dovecot's imap-login from offering DSN? best regards Hadmut

1 1

doveadm batch crash
by Jonathan Casiot 13 Apr '26

13 Apr '26

Hi I'm having an issue with doveadm batch - the following command always crashes: doveadm batch : mailbox status all inbox Whereas the following work as expected: doveadm mailbox status all inbox doveadm batch : mailbox list Any assistance gratefully received. Debug output from the crash: Debug: Loading modules from directory: /usr/lib64/dovecot Debug: Module loaded: /usr/lib64/dovecot/lib01_acl_plugin.so Debug: Module loaded: /usr/lib64/dovecot/lib10_mail_crypt_plugin.so Debug: Module loaded: /usr/lib64/dovecot/lib90_stats_plugin.so Debug: Loading modules from directory: /usr/lib64/dovecot/doveadm Debug: Module loaded: /usr/lib64/dovecot/doveadm/lib10_doveadm_acl_plugin.so Debug: Skipping module doveadm_expire_plugin, because dlopen() failed: /usr/lib64/dovecot/doveadm/lib10_doveadm_expire_plugin.so: undefined symbol: expire_set_deinit (this is usually intentional, so just ignore this message) Debug: Skipping module doveadm_quota_plugin, because dlopen() failed: /usr/lib64/dovecot/doveadm/lib10_doveadm_quota_plugin.so: undefined symbol: quota_user_module (this is usually intentional, so just ignore this message) Debug: Skipping module doveadm_fts_lucene_plugin, because dlopen() failed: /usr/lib64/dovecot/doveadm/lib20_doveadm_fts_lucene_plugin.so: undefined symbol: lucene_index_iter_deinit (this is usually intentional, so just ignore this message) Debug: Skipping module doveadm_fts_plugin, because dlopen() failed: /usr/lib64/dovecot/doveadm/lib20_doveadm_fts_plugin.so: undefined symbol: fts_user_get_language_list (this is usually intentional, so just ignore this message) Debug: Module loaded: /usr/lib64/dovecot/doveadm/libdoveadm_mail_crypt_plugin.so doveadm(jc): Debug: Effective uid=1001, gid=100, home=/home/jc doveadm(jc): Debug: acl: No acl_shared_dict setting - shared mailbox listing is disabled doveadm(jc): Debug: mail_crypt_plugin: mail_crypt_curve setting missing - generating EC keys disabled doveadm(jc): Debug: Namespace inbox: type=private, prefix=, sep=., inbox=yes, hidden=no, list=yes, subscriptions=yes location=mdbox:~/mdbox:ALT=~/Archive/tape/mdbox doveadm(jc): Debug: fs: root=/home/jc/mdbox, index=, indexpvt=, control=, inbox=, alt=/home/jc/Archive/tape/mdbox doveadm(jc): Debug: acl: initializing backend with data: vfile doveadm(jc): Debug: acl: acl username = jc doveadm(jc): Debug: acl: owner = 1 doveadm(jc): Debug: acl vfile: Global ACLs disabled doveadm(jc): Panic: file mail-storage.c: line 875 (mailbox_set_reason): assertion failed: (reason != NULL) doveadm(jc): Error: Raw backtrace: /usr/lib64/dovecot/libdovecot.so.0(+0xa0e9e) [0x7fc993023e9e] -> /usr/lib64/dovecot/libdovecot.so.0(default_fatal_handler+0x2a) [0x7fc993023f0a] -> /usr/lib64/dovecot/libdovecot.so.0(i_fatal+0) [0x7fc992fb3c97] -> /usr/lib64/dovecot/libdovecot-storage.so.0(+0x49856) [0x7fc993301856] -> /usr/bin/doveadm(+0x348e2) [0x5631dbb5f8e2] -> /usr/bin/doveadm(+0x2e1ad) [0x5631dbb591ad] -> /usr/bin/doveadm(+0x2bd2c) [0x5631dbb56d2c] -> /usr/bin/doveadm(+0x2c92a) [0x5631dbb5792a] -> /usr/bin/doveadm(doveadm_mail_try_run+0x215) [0x5631dbb58285] -> /usr/bin/doveadm(main+0x46a) [0x5631dbb473fa] -> /lib64/libc.so.6(__libc_start_main+0xf5) [0x7fc992bd83d5] -> /usr/bin/doveadm(+0x1c565) [0x5631dbb47565] Aborted (core dumped) And doveconf -n output: # 2.2.36 (1f10bfa63): /etc/dovecot/dovecot.conf # OS: Linux 3.10.0-957.1.3.el7.x86_64 x86_64 CentOS Linux release 7.6.1810 (Core) # Hostname: ### redacted ### first_valid_gid = 100 first_valid_uid = 1000 last_valid_gid = 100 last_valid_uid = 1999 listen = * login_greeting = IMAP ready login_log_format_elements = user=<%u> method=%m rip=%r lip=%l mpid=%e session=<%{session}> %k mail_attribute_dict = file:%h/mdbox/dovecot-attributes mail_location = mdbox:~/mdbox:ALT=~/Archive/tape/mdbox mail_plugins = acl stats mail_crypt mailbox_list_index = yes mdbox_rotate_size = 16 M 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 = separator = . } passdb { driver = pam } plugin { acl = vfile mail_crypt_global_private_key = <### redacted ### mail_crypt_global_public_key = <### redacted ### mail_crypt_save_version = 2 stats_memory_limit = 16 M stats_refresh = 30 secs stats_track_cmds = yes } postmaster_address = ### redacted ### protocols = imap service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } } service imap-login { process_limit = 200 process_min_avail = 4 service_count = 1 } service stats { fifo_listener stats-mail { group = users mode = 01224 } } ssl = required ssl_cert = <### redacted ### ssl_key = # hidden, use -P to show it ssl_prefer_server_ciphers = yes ssl_protocols = !SSLv2 !SSLv3 !TLSv1 userdb { driver = passwd } verbose_proctitle = yes protocol imap { imap_idle_notify_interval = 10 mins imap_metadata = yes mail_max_userip_connections = 20 mail_plugins = acl stats mail_crypt imap_acl imap_stats } Regards, -- Jonathan

2 3

decode2text
by Joan Moreau 13 Apr '26

13 Apr '26

Hi I can't find decode2text.sh in the git Where is it maintained ? Thank you Joan Hi I can't find decode2text.sh in the git Where is it maintained ? Thank you Joan

2 3

Fwd: [EXT] In Yocto-Mailinglist, there were two version of dovecot 2.4.3 found?
by Martin Maurer 10 Apr '26

10 Apr '26

Hello, resent to get clarification, about different content of 2.4.3 release tar file Best regards, Martin -------- Weitergeleitete Nachricht -------- Betreff: Re: [EXT] In Yocto-Mailinglist, there were two version of dovecot 2.4.3 found? Datum: Fri, 10 Apr 2026 14:37:36 +0300 (EEST) Von: Aki Tuomi <aki.tuomi(a)open-xchange.com> An: Martin Maurer <martin.maurer(a)mmeacs.de> Kopie (CC): dovecot-owner(a)dovecot.org <dovecot-owner(a)dovecot.org> Please send mails to dovecot(a)dovecot.org, which is our public mailing list. Aki > On 10/04/2026 14:18 EEST Martin Maurer <martin.maurer(a)mmeacs.de> wrote: > > Hi, > > in Yocto mailing list there was found out, that two different version > of dovecot 2.4.3 seems to exist: > > > https://github.com/dovecot/core/releases/download/2.4.3/dovecot-2.4.3.tar.gz > > > sha256:e0b30330fe51e47ecfcf641bc16041184d91bdd0ac3db789b7cef54e3a75ac9b > > > https://dovecot.org/releases/2.4/dovecot-2.4.3.tar.gz > > SHA256: ff0be85228122f250627b19e67505fdb7fb2f72a702ef6bf35f27fce54c072e5 > > > When downloading both and comparing them: > > The doc/man directory seem to be different. > > When I had looked correctly, all others files seems to be identical. > > > Can you explain, what could have happened? > > In Yocto the SHA256 checksum is checked, and this seems to fail, when > the one or the other download place is used. > > Is this as planned or had an error happened? > > > Many thanks for the clarification! > > > Best regards, > > Martin Hello, resent to get clarification, about different content of 2.4.3 release tar file Best regards, Martin -------- Weitergeleitete Nachricht -------- Betreff: Re: [EXT] In Yocto-Mailinglist, there were two version of dovecot 2.4.3 found? Datum: Fri, 10 Apr 2026 14:37:36 +0300 (EEST) Von: Aki Tuomi [1]<aki.tuomi(a)open-xchange.com> An: Martin Maurer [2]<martin.maurer(a)mmeacs.de> Kopie (CC): [3]dovecot-owner(a)dovecot.org [4]<dovecot-owner(a)dovecot.org> Please send mails to [5]dovecot(a)dovecot.org, which is our public mailing list. Aki On 10/04/2026 14:18 EEST Martin Maurer [6]<martin.maurer(a)mmeacs.de> wrote: Hi, in Yocto mailing list there was found out, that two different version of dovecot 2.4.3 seems to exist: [7]https://github.com/dovecot/core/releases/download/2.4.3/dovecot-2.4.3.tar… sha256:e0b30330fe51e47ecfcf641bc16041184d91bdd0ac3db789b7cef54e3a75ac9b [8]https://dovecot.org/releases/2.4/dovecot-2.4.3.tar.gz SHA256: ff0be85228122f250627b19e67505fdb7fb2f72a702ef6bf35f27fce54c072e5 When downloading both and comparing them: The doc/man directory seem to be different. When I had looked correctly, all others files seems to be identical. Can you explain, what could have happened? In Yocto the SHA256 checksum is checked, and this seems to fail, when the one or the other download place is used. Is this as planned or had an error happened? Many thanks for the clarification! Best regards, Martin References Visible links 1. mailto:aki.tuomi@open-xchange.com 2. mailto:martin.maurer@mmeacs.de 3. mailto:dovecot-owner@dovecot.org 4. mailto:dovecot-owner@dovecot.org 5. mailto:dovecot@dovecot.org 6. mailto:martin.maurer@mmeacs.de 7. https://github.com/dovecot/core/releases/download/2.4.3/dovecot-2.4.3.tar.gz 8. https://dovecot.org/releases/2.4/dovecot-2.4.3.tar.gz

1 0

Source tarballs for dovecot 2.4.3 republished
by Aki Tuomi 10 Apr '26

10 Apr '26

Hi! We have republished the source tarballs for 2.4.3 due to missing man pages in the tarball. Regards, AKi

1 0

Dovecot Proxy with mysql passdb and oauth2 authentication: upgrade from 2.3.21 to 2.4.3 does not work
by Urban Loesch 07 Apr '26

07 Apr '26

Hi, I am running a Dovecot IMAP/POP3 proxy in my test environment using the latest version, 2.3.21, installed from the Dovecot repository. It functions as a pure IMAP/POP3 proxy for 7 different IMAP backends (currently always Dovecot 2.3.21). The proxy retrieves all its information from a MySQL database mainly the ip-address to which backend he should pass the connection and forwards all authentication information to the backend. This has always worked without any issues so far. Now I'm trying to upgrade the proxy from 2.3.21 to 2.4.3. I tried to convert my 2.3.21 configuration to 2.4.3 with your very helpfull tool from https://dovecot.org/upgrader/. But now when I try to start dovecot I get the followong error in my logs: ... 2026-04-07T12:00:57.692994+02:00 imap-dev dovecot: auth: Debug: Loading modules from directory: /usr/lib/dovecot/modules/auth 2026-04-07T12:00:57.695908+02:00 imap-dev dovecot: auth: Debug: Module loaded: /usr/lib/dovecot/modules/auth/libdriver_mysql.so 2026-04-07T12:00:57.696532+02:00 imap-dev dovecot: auth: Fatal: Cannot initialize oauth2: Missing oauth2_introspection_mode setting 2026-04-07T12:00:57.697569+02:00 imap-dev dovecot: master: Error: service(auth): command startup failed, throttling for 4.000 secs ... As I just said, the server only works as a proxy (no mailboxes hosted on itself, etc). Have you any idea how I can solve this issues? Below my current .deb packages installed and "doveconf -n" from 2.4.3. Many thanks in advance Urban ----------------------- # dpkg -l |grep dovecot ii dovecot-core 2:2.4.3-1+debian12 amd64 secure POP3/IMAP server - core files ii dovecot-imapd 2:2.4.3-1+debian12 amd64 secure POP3/IMAP server - IMAP daemon ii dovecot-ldap 2:2.4.3-1+debian12 amd64 secure POP3/IMAP server - LDAP support ii dovecot-lmtpd 2:2.4.3-1+debian12 amd64 secure POP3/IMAP server - LMTP server ii dovecot-managesieved 2:2.4.3-1+debian12 amd64 secure POP3/IMAP server - ManageSieve server ii dovecot-mysql 2:2.4.3-1+debian12 amd64 secure POP3/IMAP server - MySQL support ii dovecot-pop3d 2:2.4.3-1+debian12 amd64 secure POP3/IMAP server - POP3 daemon ii dovecot-sieve 2:2.4.3-1+debian12 amd64 secure POP3/IMAP server - Sieve filters support ------------------------ # 2.4.3-1+debian12 (c1b22ef978): /etc/dovecot/dovecot.conf # Pigeonhole version 2.4.3-1+debian12 (99939e07) # OS: Linux 6.1.0-31-amd64 x86_64 Debian 12.13 # Hostname: imap-dev.domain.com dovecot_config_version = 2.4.3 auth_cache_negative_ttl = 0 auth_cache_size = 128 M auth_cache_ttl = 0 auth_debug = yes auth_debug_passwords = yes auth_failure_delay = 5 secs auth_mechanisms = plain login oauthbearer xoauth2 auth_username_chars = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_%@ auth_username_translation = %@ dovecot_storage_version = 2.4.0 login_log_format_elements = user=<%{user}> method=%{mechanism} rip=%{remote_ip} lip=%{local_ip} mpid=%{mail_pid} %{secured} %{ssl_security} managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date index ihave duplicate mime foreverypart extracttext protocols = imap sieve sql_driver = mysql ssl_min_protocol = TLSv1 verbose_proctitle = yes namespace inbox { inbox = yes 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" } } passdb sql { default_password_scheme = PLAIN query = SELECT NULL AS password, 'y' AS nodb, SUBSTRING_INDEX(SUBSTRING_INDEX(param, '[', -1), ']', 1) AS host, '%{user}' AS destuser, 'Y' AS nologin, 'Y' AS nopassword, 'Y' AS proxy, '%{mechanism}' AS proxy_mech FROM mail_username WHERE user = '%{user}' AND allow_login = 'y' AND ('%{protocol}' = 'imap' OR '%{protocol}' = 'sieve'); } mysql devdb1.domain.com { dbname = mailconfig_dev password = # hidden, use -P to show it user = imap-dev } sieve_script personal { driver = file path = ~/sieve } service imap-login { process_min_avail = 2 restart_request_count = unlimited vsz_limit = 512 M } service managesieve-login { inet_listener sieve { port = 4190 } } service pop3-login { process_min_avail = 2 restart_request_count = unlimited vsz_limit = 256 M } service tcpwrap { unix_listener login/tcpwrap { group = $SET:default_login_user mode = 0600 user = $SET:default_login_user } } ssl_server { cert_file = /etc/letsencrypt/live/domain.com/fullchain.pem dh_file = /etc/dovecot/dh.pem key_file = /etc/letsencrypt/live/domain.com/privkey.pem prefer_ciphers = server } protocol imap { imap_capability = IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE login_greeting = Domain-Dev IMAP Server ready. } protocol pop3 { login_greeting = Domain-Dev POP3 Server ready. pop3_enable_last = yes pop3_uidl_format = %{uid | substr(0, 8)}%{uidvalidity | substr(0, 8)} }

1 0

Dovecot and Pigeonhole v2.4.3 released
by Aki Tuomi 07 Apr '26

07 Apr '26

Hi! We are happy to publish version 2.4.3 of Dovecot and Pigeonhole. These contain several CVEs, discovered by external researches. The majority of these have been discovered with help of automated code analysis tools like claude code security, which is why some of these are rather old, missed bugs. No new supported distros have been added or old removed, no new dependencies have been added. Note that there are experimental features in 2.4, one is enabled with `--enable-experimental-mail-utf8`, and another with `--enable-experimental-imap4rev2`, and you also need to set mail_utf8_extensions=yes and imap4rev2_enabled=yes to enable them in config. https://dovecot.org/releases/2.4/dovecot-2.4.3.tar.gz https://dovecot.org/releases/2.4/dovecot-2.4.3.tar.gz.sig https://pigeonhole.dovecot.org/releases/2.4/dovecot-pigeonhole-2.4.3.tar.gz https://pigeonhole.dovecot.org/releases/2.4/dovecot-pigeonhole-2.4.3.tar.gz… Binary packages in https://repo.dovecot.org/ Docker images in https://hub.docker.com/r/dovecot/dovecot --- * CVE-2025-59028: Invalid base64 authentication can cause DoS for other logins. * CVE-2025-59031: decode2text.sh OOXML extraction may follow symlinks and read unintended files during indexing. Fixed by dropping the script. * CVE-2026-24031: SQL injection possible if auth_username_chars is configured empty. Fixed escaping to always happen. v2.4 regression. * CVE-2026-27859: Excessive RFC 2231 MIME parameters in email would cause excessive CPU usage. Fixed by limiting number of parameters to process. * CVE-2026-27860: LDAP query injection possible if auth_username_chars is configured empty. Fixed escaping to always happen. v2.4 regression. * CVE-2026-27857: Sending excessive parenthesis causes imap-login to use excessive memory. * CVE-2026-27856: Doveadm credentials were not checked using timing-safe checking function. * CVE-2026-27855: OTP driver vulnerable to replay attack. * Remove default service/*/service_extra_groups=$SET:default_internal_group. They are now replaced by default mail_access_groups=$SET:default_internal_group. * The version file has been renamed as version.txt to avoid clash with C++ headers. * auth: oauth2 - Do not export token automatically, must be exported using fields. * config: Don't accept 0 as meaning unlimited anymore for last_valid_uid, last_valid_gid, mail_cache_max_headers_count, mail_cache_max_header_name_length, mail_vsize_bg_after_count, mail_sort_max_read_count, message_max_size, submission_max_recipients and quota_mail_size. * imap, pop3: Don't autoexpunge if Dovecot is shutting down or process is killed. * imap: LIST - Handle invalid mUTF-7 mailbox names as never matching anything * lazy-expunge: Change lazy_expunge_only_last_instance default to yes. * lda: Use EX_TEMPFAIL (75) if configuration is invalid instead of 89. v2.4 regression. * lib-master: Increase ANVIL_DEFAULT_LOOKUP_TIMEOUT_MSECS from 5s to 30s * lib: crc32 - Use zlib's built-in CRC32 function + Improve UTF-8 support for mail storage. + auth: Add default auth-token UNIX socket for token-based authentication. + doc: solr-config-9.xml - Make it compatible with Solr 9.8.0 + doveadm: dsync - Search mails when exporting to reduce number of mails exported by dsync-server. + dovecot-sysreport: Add -D|--destdir support. + imap, imap-hibernate: Use DOVECOT-TOKEN authentication for unhibernation. Default imap-master socket permissioms have been changed due to this. + imap: Add APPENDLIMIT capability when configured with quota_mail_size. + imap: Support STATUS (DELETED) for IMAP4rev2. + imapc: Add support for SEARCH MIMEPART + imapc: Improve error forwarding. + imapc: Support SORT and ESORT extensions. + imapc: Support STATUS (DELETED) for IMAP4rev2. + lib-sql: Support parameterized queries. + lib-test: Add new test-dir API for better temporary test directory handling. + lmtp: Advertize SIZE capability when configured with quota_mail_size. + lmtp: Support XCLIENT DESTADDR and DESTPORT + pop3-login: proxy - Add support for XCLIENT DESTIP and DESTPORT + submission-login: proxy - Add support for XCLIENT DESTIP and DESTPORT + Various optimizations have been made to the code. - Fix building dovecot with BSD, Solaris and macOS. - auth: Crash would occur if users were iterated but userdb_ldap_iterate_fields was not set. - auth: Fix request leak when client authenticates with unsupported mechanism. - auth: Some passdbs would default to PLAIN instead of CRYPT scheme. - config: Section and setting names could have been intermixed, resulting in the setting being silently ignored. - configure: Fix checking if BUILD_IMAP_HIBERNATE is set - doveadm: dsync - -e parameter was handled wrong with dsync-server. - fts-flatcurve: Mailbox leak would occur if mailbox failed to open. - imap: Fix potential issues with unhibernation and process state handling. - imapc: SEARCH failure handling was done wrong. - imapc: UID STORE commands included extra comma in uidset. - lib-auth-client: auth-master - Fix panic when reconnecting after handshake timeout. - lib-compression: Lz4 algorithm would assert-crash with malicious data. - lib-dcrypt: Fix digest algorithm handling. - lib-dict: Escape username paths to prevent traversal issues with dict-fs. - lib-http: Fix HTTP parsing edge cases and state handling. - lib-iostream: Disallow empty ssl_min_protocol. - lib-json: Fix incorrect character handling logic. - lib-ldap: Fix various TLS related bugs. - lib-mail: Fix charset translation and MIME parsing edge cases. - lib-mail: Fix multiple bounds checks and parsing issues in message handling. - lib-var-expand: Multiple fixes and improvements for expansion handling. - lib: Fix punycode decoding out-of-bounds reads. - lib: Fix unicode normalization edge cases causing crashes. - lib-http: Chunked transfer trailer size was not limited. - login-common: Improve logging and internal error handling. - login-common: login_log_format_elements was split by spaces naively, which could break variable expansion. Use template aware splitting now. - master: Dovecot would fail to start if listen directive was used and dovenull or dovecot user was missing. - pop3c: Connection might've hung with SSL. - util: Fix handling of environment variables containing control characters. - Many other bugs have been fixed. --- * CVE-2026-27858: managesieve-login can allocate large amount of memory during authentication. * CVE-2025-59032: ManageSieve panic occurs with sieve-connect as a client. * lib-sieve: Don't accept 0 as meaning unlimited anymore for sieve_quota_script_count and sieve_quota_storage_size. * managesieve-login: If mail_max_userip_connections is reached, return LIMIT/CONNECTIONS resp-code. * managesieve-login: proxy - Return unexpected backend failures as TRYLATER/NORETRY resp-code. * managesieve: Remove default service_extra_groups=$SET:default_internal_group. + managesieve-login: proxy - Add support for XCLIENT DESTIP and DESTPORT. - imapsieve: Fix panic occurring upon implicit flag changes. - lib-sieve: include-extension - Fix crash occurring when previous global command has no arguments. - lib-sieve: Fix erroneous attempt to read active script for non-personal storage. - lib-sieve: ldap: Fix linking non-shared LIBDOVECOT.

8 11

Bug report: filter `default` in LDAP context does not suppress error logging
by Johannes Nohl 07 Apr '26

07 Apr '26

Bug report: Expanding variables with filter `default` in LDAP context does not suppress error logging if LDAP attribute is missing. Expected behaviour: Missing LDAP attribute does not throw an error. Example `nologin = %{ldap:missingAttribute | default}` Details: Please note: The missing attribute is called `shadowInactive` in reality. There might be another issue, the field nologin is boolean and set true if any value is assigned -- while default without parameter returns empty (thus, you cannot use default with nologin without workaround). The intended behaviour is documented clearly, however due to a bug in rendering you need to look into the doc sources (my PR for that was accepted already: https://doc.dovecot.org/2.4.2/core/config/auth/databases/ldap.html#ldap-spe… https://github.com/dovecot/documentation/pull/1478#pullrequestreview-403461… Full context: passdb ldap { driver = ldap ldap_filter = (&(objectClass=posixAccount)(mail=%{user})) fields { user = %{ldap:uid} nologin = %{ldap:shadowInactive | default} reason = The account for this email address is disabled. } } The same error was reported already a year ago, although among others, see point 4: https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/TLJ2O… Please excuse my first attempt of 31-03-2026. It was unreadable. Aki already tried to help but was - I guess - distracted from the main point. I found a workaround for the missing attribute translation to boolean fields (if someone is interested) https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/67Z4C… I tested with dovecot 2.4.2 and 2.4.3 (openSUSE repos) against local LDAP. The check for disabled users throws permanently errors in the log file, whenever the user is missing the ldap attribute for disabled. Thus, for each login of all enabled users (you will probably agree that this not acceptable). This results in the following log line: 2026-03-31T00:46:31.102690+02:00 mailserver dovecot: auth(test,ipv4,sasl:plain)<YE81n0VOVuofEeSD>: Error: ldap: auth_passdb_post settings: Failed to parse configuration: Failed to expand passdb_fields/nologin setting variables: ldap: No such attribute 'shadowinactive' Thank you Johannes -- Johannes Nohl postmaster(a)i-t-cloud.de

2 3

[Dovecot] migration from IMAP/POP3 courier server to a remote dovecot server
by nik600 06 Apr '26

06 Apr '26

Dear all i'm planning a transparent migration from a courier server that provides both IMAP and POP3 access to users to a remote dovecot server with both IMAP and POP3 access. I have to migrate about 2500 users for 250 GB of space. I'm using dovecot 2.2.5.4 on debian6 squeeze. To make a transparent migration i have to maintain old IMAP UIDs and POP3 UIDs, so i've read http://wiki2.dovecot.org/Migration and http://wiki2.dovecot.org/Migration/Courier and http://wiki2.dovecot.org/Migration/Dsync And decided that probably the best tool to use is Dsync, as the courier-dovecot-migrate.pl<http://www.dovecot.org/tools/courier-dovecot-migrate.pl> script works only locally. I've tested the dsync following instructions reported above but after the migration of one test-account the client re-download messages. If i want to keep both IMAP UIDs and POP3 UIDs i have to sync both imapc and pop3c with two commands? doveadm -o imapc_user=foo -o pop3c_user=foo -o imapc_password=bar -o pop3c_password=bar backup -R -u user@domain imapc: doveadm -o imapc_user=foo -o pop3c_user=foo -o imapc_password=bar -o pop3c_password=bar backup -R -u user@domain pop3c: Or imapc is enough? Do you have any suggestion? Thanks -- /*************/ nik600 http://www.kumbe.it

2 3

oath-toolkit pam authentication with dovecot
by "Tóth Attila" 04 Apr '26

04 Apr '26

Anybody has experience in deploying oath-toolkit totp authentication for dovecot? It works for ssh in a challenge response fashion, but I have concernes against concatenating the password with the totp digits, because I have difficulties even with su+oath_toolkit... Thx: Dw. -- dr Tóth Attila, Radiológus, 06-20-825-8057 Attila Toth MD, Radiologist, +36-20-825-8057

2 1

enabling fts_flatcurve on debian
by Stefan G. Weichinger 03 Apr '26

03 Apr '26

Which xapian-related packages do I need? I have issues enabling the plugin ... pls advise

2 6

2.4 upgrade : INBOX does not exist
by Stefan G. Weichinger 02 Apr '26

02 Apr '26

Today I upgraded a server at a customer. I modified the config I had built over the last week, with the help of this list. So far nearly everything works, but thunderbird complains about non-existing mailboxes like INBOX. But we can access it, it's a bit strange. In the filesystem it looks like: # ls -la /home/vmail/our.tld/user\(a)our.tld/ insgesamt 7096 drwx------ 69 vmail vmail 4096 2. Apr 19:00 . drwx------ 129 vmail vmail 12288 2. Apr 18:56 .. drwx------ 5 vmail vmail 4096 8. Jun 2021 .Administrator drwx------ 5 vmail vmail 4096 2. Apr 18:40 .Administrator.Archiv drwx------ 5 vmail vmail 4096 2. Apr 18:40 '.Administrator.Domainwechsel AquaCC' drwx------ 5 vmail vmail 4096 11. Mai 2025 .Archives drwx------ 5 vmail vmail 4096 2. Apr 18:40 .Archives.2001 drwx------ 5 vmail vmail 4096 2. Apr 18:40 .Archives.2002 drwx------ 5 vmail vmail 4096 2. Apr 18:40 .Archives.2003 drwx------ 5 vmail vmail 4096 12. Aug 2024 .Archives.2004 drwx------ 5 vmail vmail 4096 2. Apr 18:40 .Archives.2005 drwx------ 5 vmail vmail 4096 12. Aug 2024 .Archives.2006 drwx------ 5 vmail vmail 4096 12. Aug 2024 .Archives.2007 drwx------ 5 vmail vmail 4096 10. Feb 18:17 .Archives.2008 drwx------ 5 vmail vmail 4096 12. Aug 2024 .Archives.2009 drwx------ 5 vmail vmail 4096 12. Aug 2024 .Archives.2010 drwx------ 5 vmail vmail 4096 10. Feb 18:10 .Archives.2011 drwx------ 5 vmail vmail 4096 12. Aug 2024 .Archives.2012 drwx------ 5 vmail vmail 4096 12. Aug 2024 .Archives.2013 drwx------ 5 vmail vmail 4096 10. Feb 18:09 .Archives.2014 drwx------ 5 vmail vmail 4096 12. Aug 2024 .Archives.2015 drwx------ 5 vmail vmail 4096 2. Apr 17:51 .Archives.2016 drwx------ 5 vmail vmail 4096 11. Feb 11:57 .Archives.2017 drwx------ 5 vmail vmail 4096 10. Jun 2025 .Archives.2018 drwx------ 5 vmail vmail 4096 11. Feb 11:57 .Archives.2019 drwx------ 5 vmail vmail 4096 10. Feb 18:23 .Archives.2020 drwx------ 5 vmail vmail 4096 1. Apr 20:18 .Archives.2021 drwx------ 5 vmail vmail 4096 30. Mär 09:37 .Archives.2022 drwx------ 5 vmail vmail 4096 1. Apr 20:18 .Archives.2023 drwx------ 5 vmail vmail 4096 1. Apr 20:18 .Archives.2024 drwx------ 5 vmail vmail 4096 2. Apr 17:48 .Archives.2025 drwx------ 5 vmail vmail 4096 2. Apr 17:59 .Archives.2026 drwx------ 2 vmail vmail 323584 2. Apr 19:00 cur -rw------- 1 vmail vmail 0 2. Aug 2021 dovecot-acl-list -rw------- 1 vmail vmail 70712 2. Apr 18:37 dovecot.index -rw------- 1 vmail vmail 6266860 2. Apr 19:01 dovecot.index.cache -rw------- 1 vmail vmail 32160 2. Apr 19:00 dovecot.index.log -rw------- 1 vmail vmail 46940 2. Apr 06:20 dovecot.index.log.2 -rw------- 1 vmail vmail 91 18. Aug 2020 dovecot-keywords -rw------- 1 vmail vmail 65 2. Apr 18:37 .dovecot.lda-dupes drwx------ 5 vmail vmail 4096 2. Apr 18:37 .dovecot.lda-dupes.locks -rw------- 1 vmail vmail 6504 2. Apr 18:49 dovecot.list.index -rw------- 1 vmail vmail 3356 2. Apr 19:02 dovecot.list.index.log -rw------- 1 vmail vmail 2904 7. Jän 13:53 dovecot.mailbox.log -rw------- 1 vmail vmail 186894 2. Apr 18:59 dovecot-uidlist -rw------- 1 vmail vmail 8 7. Jän 13:53 dovecot-uidvalidity -r--r--r-- 1 vmail vmail 0 21. Apr 2020 dovecot-uidvalidity.5e9efc52 drwx------ 5 vmail vmail 4096 2. Apr 12:02 .Drafts drwx------ 5 vmail vmail 4096 12. Jun 2025 '.Entw&APw-rfe' drwx------ 5 vmail vmail 4096 6. Mai 2020 .Gesendet drwx------ 5 vmail vmail 4096 2. Apr 18:22 .INBOX.Administrator drwx------ 5 vmail vmail 4096 2. Apr 18:21 .INBOX.Alerts [..] We have mail_home = /home/vmail/%{user | domain}/%{user} I tried mail_home = /home/vmail/%{user | domain}/%{user | username} but that breaks things completely. In 2.3 we had these namespaces: namespace { type = private separator = / prefix = #location defaults to mail_location. inbox = yes } namespace { type = public separator = / prefix = Oeffentlich/ location = maildir:/home/vmail/oeffentlich subscriptions = yes } I tried "prefix = INBOX/" ... not good. I share the config, a little bit anonymized, acls removed ... # doveconf -n # 2.4.1-4 (7d8c0e5759): /etc/dovecot/dovecot.conf # Pigeonhole version 2.4.1-4 (0a86619f) # OS: Linux 6.12.74+deb13+1-amd64 x86_64 Debian 13.4 # Hostname: xxxx dovecot_config_version = 2.4.1 auth_allow_weak_schemes = yes auth_cache_size = 4M auth_debug = yes auth_mechanisms = plain login auth_verbose = yes default_process_limit = 300 dovecot_storage_version = 2.4.0 import_environment { CORE_ERROR = %{env:CORE_ERROR} CORE_OUTOFMEM = %{env:CORE_OUTOFMEM} LISTEN_FDS = %{env:LISTEN_FDS} LISTEN_PID = %{env:LISTEN_PID} MALLOC_MMAP_THRESHOLD_ = 131072 NOTIFY_SOCKET = %{env:NOTIFY_SOCKET} PATH = %{env:PATH} TZ = :/etc/localtime } info_log_path = /var/log/dovecot.info listen = * [::] log_path = /var/log/dovecot.log mail_debug = yes mail_driver = maildir mail_gid = 5000 mail_home = /home/vmail/%{user | domain}/%{user} mail_path = ~ mail_plugins { acl = yes notify = yes quota = no } mail_uid = 5000 protocols = imap sieve lmtp 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 editheader = yes mboxmetadata = yes servermetadata = yes spamtest = yes spamtestplus = yes virustest = yes } sieve_global_extensions { vnd.dovecot.debug = yes vnd.dovecot.environment = yes vnd.dovecot.pipe = yes } sieve_pipe_bin_dir = /usr/lib/dovecot/sieve sieve_plugins = sieve_imapsieve sieve_extprograms sieve_spamtest_score_max_value = 15 sieve_spamtest_status_header = X-Spamd-Result: .*? \[([[:digit:]]+\.[[:digit:]]+) / [[:digit:]]+\.[[:digit:]]+\]; sql_driver = mysql ssl = required verbose_proctitle = yes mysql /var/run/mysqld/mysqld.sock { dbname = postfix_db password = # hidden, use -P to show it user = postfix_user } passdb sql { default_password_scheme = MD5-CRYPT query = SELECT username as user, password FROM mailbox WHERE ((username = '%{user | username}(a)domain1.at') OR (username = '%{user | username}(a)domain2.at')) AND active = '1' } userdb sql { iterate_query = SELECT userid AS username, domain FROM users query = SELECT username as user FROM mailbox WHERE ((username = '%{user | username}(a)domain1.at') OR (username = '%{user | username}(a)domain2.at') ) AND active = '1' } namespace inbox { inbox = yes prefix = separator = / type = private } namespace oeffentlich { mail_path = /home/vmail/oeffentlich prefix = Oeffentlich/ separator = / subscriptions = yes type = public mailbox Oeffentlich { acl [DELETED for now] } service imap-login { process_min_avail = 8 inet_listener imap { port = 0 ssl = no listen = } inet_listener imaps { port = 993 ssl = yes listen = } } service lmtp { extra_groups = $SET:default_internal_group user = vmail unix_listener /var/spool/postfix/private/dovecot-lmtp { group = postfix mode = 0660 user = postfix } } service imap { } service auth { client_limit = 1200 user = root unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0666 user = postfix } unix_listener auth-client { group = postfix mode = 0660 user = postfix } unix_listener auth-userdb { mode = 0660 } } service auth-worker { } service dict { unix_listener dict { } } ssl_server { cert_file = /etc/letsencrypt/pfsense/cloud_imap_mail_smtp_LE_cert.fullchain key_file = /etc/letsencrypt/pfsense/cloud_imap_mail_smtp_LE_cert.key } protocol lda { mail_plugins = sieve } protocol imap { imap_idle_notify_interval = 29 mins mail_max_userip_connections = 50 mail_plugins { imap_acl = yes imap_quota = no imap_sieve = yes } } protocol lmtp { mail_plugins = sieve postmaster_address = logs(a)xunil.at } service managesieve-login { inet_listener sieve { port = 4190 } } service managesieve { } protocol sieve { managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date ihave } sieve_script personal { active_path = /home/vmail/%{user | domain}/%{user}/sieve/scripts/.dovecot.sieve driver = file path = /home/vmail/%{user | domain}/%{user}/sieve/scripts } sieve_script before-0 { driver = file path = /usr/lib/dovecot/sieve/global-spam.sieve type = before } service anvil { unix_listener anvil { group = $SET:default_internal_group mode = 0660 } } I assume I am not far from full success, I'd just like to get rid of these errors because tomorrow dozens of users will access their mailboxes ... Thanks for any pointers!

1 1

BUG-Report: mysql: SSL support not compiled in (remove ssl_client_ca_file and ssl_client_ca_dir settings) third attempt!
by Klaus Tachtler 02 Apr '26

02 Apr '26

Hello everyone, Problem info: ============ An error occurs, while trying to establish a TLS/SSL secured connection to a database (mariadb), which has the ability to accept TLS/SSL connections. Analysis from Archlinux Gitlab Issue, which could be found under following link by - Toolybird: https://gitlab.archlinux.org/archlinux/packaging/packages/dovecot/-/issues/… > Thanks for reporting. It would appear to be some kind of (upstream?) > bug in the autofoo. The error message can be traced back to > HAVE_MYSQL_SSL being undefined when it should be defined. This is > reflected in log: https://reproducible.archlinux.org/api/v0/builds/946041/log > It took quite some debugging, but adding the following hack before the > autoreconf call appears to make it work: > checking for mysql_ssl_set in -llibmariadb... no > sed -i 's/mysql_driver="libmariadb"/mysql_driver="mariadb"/' m4/ > want_mysql.m4 > After that it now shows: > checking for mysql_ssl_set in -lmariadb... yes Steps to reproduce: ================== 1. Configure dovecot 2.4.2-4 as described below 2. Restart dovecot 2.4.2-4 3. Try send an email (echo "Test-E-Mail" | /usr/sbin/sendmail root) 4. Determine error messages inside dovecot 2.4.2-4-Log > 01 Dec 22 04:57:38 server dovecot[842]: auth: Error: > mysql(db.idmz.tachtler.net): mysql: SSL support not compiled in > (remove ssl_client_ca_file and ssl_client_ca_dir settings) > 02 Dec 22 04:57:38 server dovecot[842]: auth-worker: Error: > mysql(db.idmz.tachtler.net): mysql: SSL support not compiled in > (remove ssl_client_ca_file and ssl_client_ca_dir settings) Additional info: =============== OS version: Archlinux package version(s): dovecot 2.4.2-4 necessary config file part: > 45 sql_driver = mysql > 46 > 47 mysql db.idmz.tachtler.net { > 48 host = db.idmz.tachtler.net > 49 port = 3306 > 50 user = postfixuser > 51 password = secret > 52 dbname = postfix > 53 ssl = yes > 54 ssl_client_ca_file = /etc/dovecot/ssl/certs/CAcert.pem > 55 ssl_client_cert_file = > /etc/dovecot/ssl/certs/client.idmz.tachtler.net.pem > 56 ssl_client_key_file = > /etc/dovecot/ssl/private/client.idmz.tachtler.net.key.pem > 57 ssl_cipher_list = DHE-RSA-AES256-SHA > 58 } WITHOUT the following line, a database connections is possible and works as expected: > 53 ssl = yes > 54 ssl_client_ca_file = /etc/dovecot/ssl/certs/CAcert.pem > 55 ssl_client_cert_file = > /etc/dovecot/ssl/certs/client.idmz.tachtler.net.pem > 56 ssl_client_key_file = > /etc/dovecot/ssl/private/client.idmz.tachtler.net.key.pem > 57 ssl_cipher_list = DHE-RSA-AES256-SHA Thanky you in advance for your help! Klaus Tachtler. -- --------------------------------------- e-Mail : klaus(a)tachtler.net Homepage: https://www.tachtler.net DokuWiki: https://dokuwiki.tachtler.net ---------------------------------------

3 17

Error: sieve: fail2ban: line 23: read(<lmtp DATA local>) failed: Seeking past EOF by 2364 bytes
by Graham Cobb 01 Apr '26

01 Apr '26

Hi, dovecot is crashing for me while doing sieve processing for messages received via lmtp. This is reproducible, and seems to hit every message which runs a particular sieve script. Any thoughts or help would be appreciated! The error is: Error: sieve: fail2ban: line 23: read(<lmtp DATA local>) failed: Seeking past EOF by 2364 bytes Note: the number of bytes is always one of: 2169, 2272, 2259, 2364. I have many of these. I cannot see how the "Seeking past EOF" error can be caused by a bug in my sieve script. But please let me know if it can! Background: I have (and have had for many years) a complex set of sieve scripts for controlling my incoming email. They have worked fine for all that time. However, recently (ish), processing which uses a particular script is crashing dovecot. The actual log extract is below. The sieve script line 23, mentioned in the error report, is a large "if anyof (" statement containing many clauses like: body :raw :regex "country:[[:space:]]+KR", I can provide the full sieve script if required. This is what I see in the dovecot log (note: I reformatted the backtrace to make it easier to read. I also changed all my server names): Mar 29 03:03:52 SERVER dovecot-HOST: lmtp(4008073): Connect from local Mar 29 03:03:52 SERVER dovecot-HOST: lmtp(cobb)<4008073><PiAQHoiIyGmJKD0Ay7SJiA>: Error: sieve: fail2ban: line 23: read(<lmtp DATA local>) failed: Seeking past EOF by 2364 bytes Mar 29 03:03:52 SERVER dovecot-HOST: lmtp(cobb)<4008073><PiAQHoiIyGmJKD0Ay7SJiA>: Error: sieve: Execution of script 'auto:personal/.dovecot' was aborted due to temporary failure (user logfile /home/cobb/.dovecot.sieve.log may reveal additional details) Mar 29 03:03:52 SERVER dovecot-HOST: lmtp(cobb)<4008073><PiAQHoiIyGmJKD0Ay7SJiA>: Panic: file istream-concat.c: line 27 (i_stream_concat_close): assertion failed: (cstream->cur_input == cstream->input[cstream->cur_idx]) Mar 29 03:03:52 SERVER dovecot-HOST: lmtp(cobb)<4008073><PiAQHoiIyGmJKD0Ay7SJiA>: Error: Raw backtrace: #1 [unw_get_proc_name() failed: -10] -> #2 [unw_get_proc_name() failed: -10] -> #3 i_panic[0x7f41540655e6] -> #4 [unw_get_proc_name() failed: -10] -> #5 io_stream_unref[0x7f415413c120] -> #6 i_stream_unref[0x7f4154145c30] -> #7 index_storage_mailbox_close[0x7f4154383e70] -> #8 mailbox_close[0x7f41542fd9e0] -> #9 mailbox_free[0x7f4154302ab0] -> #10 lmtp_local_deinit[0x55dfa9c4e320] -> #11 client_state_reset[0x55dfa9c4f0d0] -> #12 smtp_server_transaction_free[0x7f4154091880] -> #13 smtp_server_connection_reset_state[0x7f4154093c90] -> #14 smtp_server_command_call_hooks[0x7f415408be60] -> #15 smtp_server_command_send_replies[0x7f4154090050] -> #16 [unw_get_proc_name() failed: -10] -> #17 [unw_get_proc_name() failed: -10] -> #18 io_loop_call_io[0x7f4154151710] -> #19 io_loop_handler_run_internal[0x7f41541534b0] -> #20 io_loop_handler_run[0x7f4154153640] -> #21 io_loop_run[0x7f4154153820] -> #22 master_service_run[0x7f41540a6330] -> #23 main[0x55dfa9c4a260] -> #24 __libc_start_call_main[0x7f4153e32c30] -> #25 __libc_start_main_alias_2[0x7f4153e32ce0] -> #26 _start[0x55dfa9c4a470] Mar 29 03:03:54 SERVER dovecot-HOST: lmtp(cobb)<4008073><PiAQHoiIyGmJKD0Ay7SJiA>: Fatal: master: service(lmtp): child 4008073 killed with signal 6 (core dumped) Mar 29 03:04:05 SERVER postfix/lmtp[4008072]: 005083DC75D: to=<MYADDRESS@MYDOMAIN>, orig_to=<ANOTHER@ANOTHERDOMAIN>, relay=SERVERNAME[private/dovecot-lmtp], delay=1740676, delays=1740674/0.25/0.04/1.5, dsn=4.4.2, status=deferred (lost connection with SERVERNAME[private/dovecot-lmtp] while sending end of data -- message may be sent more than once) The only message in .dovecot.sieve.log is: fail2ban: line 23: error: failed to read input message: internal error occurred: refer to server log for more information. [2026-04-01 18:54:13]. Thanks in advance for any thoughts! Graham

2 1

Broken table in dovecot-pw manual
by Célestin Matte 01 Apr '26

01 Apr '26

Hello, I just noticed while reading the dovecot-pw man on Arch Linux that the table in the -r option is broken (missing newline between row): | Scheme | Minimum | Maximum | Default | | ------ | ------- | ------- | ------- | | BLF-CRYPT | 4 | 31 | 5 | | SHA256-CRYPT | 1000 | 999999999 | 5000 | | SHA512-CRYPT | 1000 | 999999999 | 5000 | Regards, -- Célestin Matte

2 1

dovecot.list.index.log owned by root: why?
by Stefan G. Weichinger 01 Apr '26

01 Apr '26

I use these sql-queries to let all mailboxes be accessed by the uid=1001: passdb sql { default_password_scheme = MD5-CRYPT passdb_sql_query = SELECT username as user, password, \ '/home/vmail/%{user | domain }/%{user}' as userdb_home, 'maildir:/home/vmail/%{user | domain }/%{user}' as userdb_mail,\ 1001 as userdb_uid, 1001 as userdb_gid FROM mailbox WHERE username = '%{user}' AND active = '1' } userdb prefetch { } ( I assume this following query isn't used then anymore) userdb sql { userdb_sql_query = SELECT username as user, password, \ '/home/vmail/%{user | domain }/%{user}' as userdb_home, 'maildir:/home/vmail/%{user | domain }/%{user}' as userdb_mail,\ 1001 as userdb_uid, 1001 as userdb_gid \ FROM mailbox WHERE username = '%{user}' AND active = '1' userdb_sql_iterate_query = SELECT userid AS username, domain FROM users } id 1001 uid=1001(vmail) gid=1001(vmail) groups=1001(vmail),118(dovecot) I get errors like: Apr 01 11:43:05 imap(logs(a)xunil.at)<1564491><N8oZ6WJO/uwgAQRwHwsMRX9ul+gRMpfY>: Error: open(/home/vmail/xunil.at/logs(a)xunil.at/dovecot.list.index.log) failed: Permission denied (euid=1001(vmail) egid=1001(vmail) missing +r perm: /home/vmail/xunil.at/logs(a)xunil.at/dovecot.list.index.log) ls -l /home/vmail/xunil.at/logs(a)xunil.at/ total 944 drwx------ 2 vmail vmail 622592 Apr 1 11:43 cur -rw------- 1 vmail vmail 0 Jul 30 2021 dovecot-acl-list -rw------- 1 vmail vmail 3304 Apr 1 11:35 dovecot.index -rw------- 1 vmail vmail 202444 Apr 1 11:43 dovecot.index.cache -rw------- 1 vmail vmail 2908 Apr 1 11:43 dovecot.index.log -rw------- 1 vmail vmail 32892 Apr 1 11:35 dovecot.index.log.2 -rw------- 1 vmail vmail 91 Feb 9 2024 dovecot-keywords -rw------- 1 root root 5744 Apr 1 10:30 dovecot.list.index -rw------- 1 root root 480 Apr 1 10:52 dovecot.list.index.log [..] Why do these 2 files get owned by root now ... ? All files below "/home/vmail" should be owned by vmail:vmail I ran chown, and chgrp, sure .. but the errors return. How to fix this? Thanks in advance!

2 5

cannot get IOS or MacOSX to connect to dovecot:995 since upgraded Mac or iPhone
by Bill Scheding 01 Apr '26

01 Apr '26

Versions: [wls(a)www.wls.org]$ uname -a Linux www.wls.org 3.10.0-1160.119.1.el7.x86_64 #1 SMP Tue Jun 4 14:43:51 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux [wls(a)ww.wls.org]$ dovecot --version 2.2.36 (1f10bfa63) My Certs: Testing cert dovecot.key unable to load certificate 139668060415888:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:707:Expecting: TRUSTED CERTIFICATE lrwxrwxrwx 1 root root 21 Mar 25 15:44 dovecot.key -> dovecot.key.old_sep_2 Testing chain dovecot.pem SHA1 Fingerprint=4A:29:34:1D:D5:9C:67:59:FA:31:7E:FF:F4:53:F8:DB:25:73:15:07 subject= /OU=IMAP server/CN=imap.example.com/emailAddress=postmaster@example.com issuer= /OU=IMAP server/CN=imap.example.com/emailAddress=postmaster@example.com serial=C8AA4C688A3F2638 b5bd7939 notBefore=Sep 2 20:17:33 2018 GMT notAfter=Sep 2 20:17:33 2019 GMT lrwxrwxrwx 1 root root 21 Mar 25 15:44 dovecot.pem -> dovecot.crt.old_sep_2 New Certs: Testing key ca.key.3.13.4 RSA key ok lrwxrwxrwx 1 root root 31 Mar 13 14:14 ca.key.3.13.4 -> ../../tls/private/ca.key.3.13.4 Testing chain ca.crt.3.13.4 SHA1 Fingerprint=79:69:88:2A:E0:BF:58:A8:21:E3:88:12:8D:45:20:4F:FD:68:33:63 subject= /C=XX/ST= /L= /O= /OU=IMAP server/CN=imap.example.com/emailAddress=postmaster@example.com issuer= /C=XX/ST= /L= /O= /OU=IMAP server/CN=imap.example.com/emailAddress=postmaster@example.com serial=B912DD19FEDC441C 402b4e2a notBefore=Mar 13 20:02:58 2026 GMT notAfter=Mar 13 20:02:58 2027 GMT lrwxrwxrwx 1 root root 29 Mar 13 14:13 ca.crt.3.13.4 -> ../../tls/certs/ca.crt.3.13.4 They install OK, dovecot starts; but iPhone and mac cannot connect to pop3 Cannot get my iPhone or Mac to accept new certs from lets encrypt, et. al. This is a new problem, started recently. My existing cert expired in 2016 William

2 1

[BUG] 2.4.3 SIGSEGV in fts_solr
by Nick O'Connor 01 Apr '26

01 Apr '26

Dovecot 2.4.3 crashes with SIGSEGV in indexer-worker and lmtp during FTS Solr indexing. The crash is a use-after-free triggered when the HTTP client does a DNS lookup for the Solr host. Environment: - Dovecot 2.4.3 (Alpine 3.23 / musl) - Linux x86_64 - Filesystem: maildir on ZFS - Solr 10.0.0 - fts_solr plugin with DNS-based Solr URL dovecot -n: # 2.4.3 (e278b1e09b): /etc/dovecot/dovecot.conf # Pigeonhole version 2.4.3 (0bf9ee48) # OS: Linux 6.12.74+deb13+1-amd64 x86_64 dovecot_config_version = 2.4.0 auth_mechanisms = oauthbearer xoauth2 dovecot_storage_version = 2.4.0 fts_autoindex = yes fts_search_add_missing = yes mail_always_cache_fields = date.save mail_driver = maildir mail_plugins { fts = yes fts_solr = yes } protocols = imap lmtp sieve ssl = required fts solr { url = http://solr.example.com/solr/dovecot } (LDAP userdb/passdb, pigeonhole sieve, imapsieve for spam learning, and oauth2 passdb omitted) How to reproduce: The crash occurs in the indexer-worker when processing multiple user mailboxes sequentially for FTS indexing, using a DNS hostname for the Solr URL. Steps: 1. Configure fts_solr with a DNS-based URL (not an IP address) 2. Have the indexer-worker process mailboxes for more than one user (e.g. fts_autoindex = yes with multiple users, or manual doveadm index -A) 3. The first user session completes successfully. On the second user session, the indexer-worker crashes with SIGSEGV during the DNS lookup for the Solr host. Reproduces reliably on musl (Alpine) due to aggressive memory reuse. Likely also affects glibc but may not crash immediately due to delayed reuse of freed memory. Root cause: The solr_http_client singleton outlives the user session that created it. Its event chain holds a ref on the mail_storage_service_user event, keeping it alive after the user is freed. The SETTINGS_EVENT_INSTANCE on that event still points to the already-freed settings_instance. On the next user session, dns_lookup() walks the stale event chain and dereferences the dangling pointer in settings_instance_get(). Stack trace (from core dump, debug build with musl-dbg): #0 strlen(s=0x415641d189485741) -- SIGSEGV, freed/reused memory #1 p_strdup() strfuncs.c:56 #2 event_add_str(key="protocol", value=...) lib-event.c:1099 #3 settings_instance_get() settings.c:2521 #4 settings_get_real() settings.c:2706 #5 settings_get_full() settings.c:2915 #6 settings_get(dns_client_setting_parser_info) settings.c:2976 #7 dns_client_init() dns-lookup.c:465 #8 dns_client_init_handle_failure() dns-lookup.c:317 #9 dns_lookup("solr.example.com") dns-lookup.c:337 #10 http_client_host_shared_lookup() http-client-host.c:166 #11 http_client_host_shared_refresh() http-client-host.c:195 #12-#19 http_client queue/host/request submit chain #20 http_client_request_continue_payload() http-client-request.c:1170 #21 http_client_request_send_payload() http-client-request.c:1261 #22 solr_connection_post_more() solr-connection.c:269 Proposed fix: Destroy solr_http_client in solr_connection_deinit() so it is recreated with a fresh event chain on the next user session: --- a/src/plugins/fts-solr/solr-connection.c +++ b/src/plugins/fts-solr/solr-connection.c @@ -117,6 +117,8 @@ void solr_connection_deinit(struct solr_connection **_conn) *_conn = NULL; event_unref(&conn->event); + if (solr_http_client != NULL) + http_client_deinit(&solr_http_client); i_free(conn->http_host); i_free(conn->http_base_url); I've been running for few days with the patch applied. FTS indexing across multiple user sessions completes without crashes using a DNS-based Solr URL. Please let me know if there's anything else that would be helpful. The core files have sensitive information so I've omitted them from the report. -Nick Dovecot 2.4.3 crashes with SIGSEGV in indexer-worker and lmtp during FTS Solr indexing. The crash is a use-after-free triggered when the HTTP client does a DNS lookup for the Solr host. Environment: - Dovecot 2.4.3 (Alpine 3.23 / musl) - Linux x86_64 - Filesystem: maildir on ZFS - Solr 10.0.0 - fts_solr plugin with DNS-based Solr URL dovecot -n: # 2.4.3 (e278b1e09b): /etc/dovecot/dovecot.conf # Pigeonhole version 2.4.3 (0bf9ee48) # OS: Linux 6.12.74+deb13+1-amd64 x86_64 dovecot_config_version = 2.4.0 auth_mechanisms = oauthbearer xoauth2 dovecot_storage_version = 2.4.0 fts_autoindex = yes fts_search_add_missing = yes mail_always_cache_fields = date.save mail_driver = maildir mail_plugins { fts = yes fts_solr = yes } protocols = imap lmtp sieve ssl = required fts solr { url = http://solr.example.com/solr/dovecot } (LDAP userdb/passdb, pigeonhole sieve, imapsieve for spam learning, and oauth2 passdb omitted) How to reproduce: The crash occurs in the indexer-worker when processing multiple user mailboxes sequentially for FTS indexing, using a DNS hostname for the Solr URL. Steps: 1. Configure fts_solr with a DNS-based URL (not an IP address) 2. Have the indexer-worker process mailboxes for more than one user (e.g. fts_autoindex = yes with multiple users, or manual doveadm index -A) 3. The first user session completes successfully. On the second user session, the indexer-worker crashes with SIGSEGV during the DNS lookup for the Solr host. Reproduces reliably on musl (Alpine) due to aggressive memory reuse. Likely also affects glibc but may not crash immediately due to delayed reuse of freed memory. Root cause: The solr_http_client singleton outlives the user session that created it. Its event chain holds a ref on the mail_storage_service_user event, keeping it alive after the user is freed. The SETTINGS_EVENT_INSTANCE on that event still points to the already-freed settings_instance. On the next user session, dns_lookup() walks the stale event chain and dereferences the dangling pointer in settings_instance_get(). Stack trace (from core dump, debug build with musl-dbg): #0 strlen(s=0x415641d189485741) -- SIGSEGV, freed/reused memory #1 p_strdup() strfuncs.c:56 #2 event_add_str(key="protocol", value=...) lib-event.c:1099 #3 settings_instance_get() settings.c:2521 #4 settings_get_real() settings.c:2706 #5 settings_get_full() settings.c:2915 #6 settings_get(dns_client_setting_parser_info) settings.c:2976 #7 dns_client_init() dns-lookup.c:465 #8 dns_clien t_init_handle_failure() dns-lookup.c:317 #9 dns_lookup("solr.example.com") dns-lookup.c:337 #10 http_client_host_shared_lookup() http-client-host.c:166 #11 http_client_host_shared_refresh() http-client-host.c:195 #12-#19 http_client queue/host/request submit chain #20 http_client_request_continue_payload() http-client-request.c:1170 #21 http_client_request_send_payload() http-client-request.c:1261 #22 solr_connection_post_more() solr-connection.c:269 Proposed fix: Destroy solr_http_client in solr_connection_deinit() so it is recreated with a fresh event chain on the next user session: --- a/src/plugins/fts-solr/solr-connection.c +++ b/src/plugins/fts-solr/solr-connection.c @@ -117,6 +117,8 @@ void solr_connection_deinit(struct solr_connection **_conn) *_conn = NULL; event_unref(&conn->event); + if (solr_http_client != NULL) + http_client_deinit(&solr_http_client); i_free(conn->http_host); i_free(conn->http_base_url); I've been running for few days with the patch applied. FTS indexing across multiple user sessions completes without crashes using a DNS-based Solr URL. Please let me know if there's anything else that would be helpful. The core files have sensitive information so I've omitted them from the report. -Nick

1 0

migration from 2.3 to 2.4 : postfix can't deliver via lmtp
by Stefan G. Weichinger 31 Mar '26

31 Mar '26

I am in the process of upgrading and rewriting my config. I can access IMAP etc ... so my database access is working. I have issues with LMTP: postfix can't deliver to dovecot. The postfix-confiog wasn't touched at all. the error: Mar 27 11:46:37 co dovecot: auth(stefan(a)oops.co.at): Error: userdb: client doesn't have lookup permissions for this user: userdb reply doesn't contain uid (to bypass this check, set: service auth { unix_listener /run/dovecot/auth-userdb { mode=0777 } }) What I don't understand: I configure this: service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0666 user = postfix } } service auth-worker { user = postfix } service lmtp { user = vmail unix_listener /var/spool/postfix/private/dovecot-lmtp { group = postfix mode = 0660 user = postfix } } protocol lmtp { mail_plugins = sieve postmaster_address = logs(a)xunil.at } And in postfix: virtual_transport = lmtp:unix:private/dovecot-lmtp virtual_uid_maps = static:5000 virtual_gid_maps = static:5000 local_transport = virtual local_recipient_maps = $virtual_mailbox_maps smtpd_sasl_auth_enable = yes smtpd_sasl_type = dovecot smtpd_sasl_path = private/auth Where does "/run/dovecot/auth-userdb" come from? I understand that according to my config /var/spool/postfix/private/auth should be used? ls /var/spool/postfix/private/auth -l srw-rw-rw- 1 postfix postfix 0 Mar 27 11:45 /var/spool/postfix/private/auth ls /var/spool/postfix/private/dovecot-lmtp -l srw-rw---- 1 postfix postfix 0 Mar 27 11:45 /var/spool/postfix/private/dovecot-lmtp I'd appreciate any quick help here ... while googling and testing around ... thanks!

2 17

upgrade to 2.4
by John Hill 31 Mar '26

31 Mar '26

Dovecot may go down as one of the best/worst software in its category. I'm staying on Debian 12 doing backports, till the dust settles several times. --john

1 0

Fwd: dovecot mailing list probe message
by Jaco Kroon 30 Mar '26

30 Mar '26

Hi, It seems like the list system is breaking DKIM - triggering bounces, resulting in unsuscribes. Is there recommendations on how to deal with this? Looks like it relates 100% to the addition of the footer: ______________________________________________ dovecot mailing list -- dovecot(a)dovecot.org To unsubscribe send an email to dovecot-leave(a)dovecot.org Kind regards, Jaco -------- Forwarded Message -------- Subject: dovecot mailing list probe message Date: Mon, 30 Mar 2026 06:32:58 +0000 From: dovecot-bounces+a190cb9ae5d94d8fa6e2af68fc964a7aaa13256b(a)dovecot.org To: jaco(a)uls.co.za This is a probe message. You can ignore this message. The dovecot(a)dovecot.org mailing list has received a number of bounces from you, indicating that there may be a problem delivering messages to jaco(a)uls.co.za. A sample is attached below. Please examine this message to make sure there are no problems with your email address. You may want to check with your mail administrator for more help. You don't need to do anything to remain an enabled member of the mailing list. If you have any questions or problems, you can contact the mailing list owner at dovecot-owner(a)dovecot.org Hi, It seems like the list system is breaking DKIM - triggering bounces, resulting in unsuscribes. Is there recommendations on how to deal with this? Looks like it relates 100% to the addition of the footer: ______________________________________________ dovecot mailing list -- [1]dovecot(a)dovecot.org To unsubscribe send an email to [2]dovecot-leave(a)dovecot.org Kind regards, Jaco -------- Forwarded Message -------- Subject: dovecot mailing list probe message Date: Mon, 30 Mar 2026 06:32:58 +0000 From: [3]dovecot-bounces+a190cb9ae5d94d8fa6e2af68fc964a7aaa13256b(a)dovecot.org To: [4]jaco(a)uls.co.za This is a probe message. You can ignore this message. The [5]dovecot(a)dovecot.org mailing list has received a number of bounces from you, indicating that there may be a problem delivering messages to [6]jaco(a)uls.co.za. A sample is attached below. Please examine this message to make sure there are no problems with your email address. You may want to check with your mail administrator for more help. You don't need to do anything to remain an enabled member of the mailing list. If you have any questions or problems, you can contact the mailing list owner at [7]dovecot-owner(a)dovecot.org References Visible links 1. mailto:dovecot@dovecot.org 2. mailto:dovecot-leave@dovecot.org 3. mailto:dovecot-bounces+a190cb9ae5d94d8fa6e2af68fc964a7aaa13256b@dovecot.org 4. mailto:jaco@uls.co.za 5. mailto:dovecot@dovecot.org 6. mailto:jaco@uls.co.za 7. mailto:dovecot-owner@dovecot.org

3 4

Update to v2.4.3 breaks ldap connection
by markus-dovecot＠doits.de 30 Mar '26

30 Mar '26

Unfortunately the upgrade to v2.4.3 broke the ldap connection. I have configured an ldap connection like this: ``` ldap_uris = ldaps://xxx.com ldap_auth_dn = uid=xxx,ou=general accounts,dc=xxx,dc=com ldap_auth_dn_password = xxx ldap_base = dc=xxx,dc=com passdb ldap { ldap_bind = yes [...] } ``` v2.4.3 cannot connect and says: ``` auth: Error: ldap(ldaps://xxx.com636): Can't connect to server: ldaps://xxx.com ``` Ldap server logs: ``` ACCEPT from IP=[XXX]:45674 (IP=[::]:636) TLS established tls_ssf=256 ssf=256 tls_proto=TLS1.3 tls_cipher=AES-256-GCM closed (connection lost) ``` Downgrade to dovecot v2.4.2 makes it work again. Was there any ldap change in v2.4.3 that required a config change? Using ubuntu 24.04 with the dovecot ppa, now forced version 2.4.2 by using https://repo.dovecot.org/ce-2.4.2/ubuntu/noble

4 6

Dovecot 2.4.3 virtual now broken even more
by sev monster 30 Mar '26

30 Mar '26

As of 2.4.2, Dovecot no longer crashed and broken config vars no longer caused it to error out, so I finally (reluctantly) switched to it over 2.3, though I had to disable/change a few things to get it to work. However, my virtual namespaces were still broken, since the `autosubscribe = yes` option would cause the driver to attempt to create the virtual directories, and fail when they already existed. Turning off autosubscribe meant that the folders were not visible to my users without manually subscribing. With 2.4.3, now the virtual configs that "worked" before now cause Dovecot to error out completely! Yay It seems this commit introduced a "feature" that restricts the virtual driver to the fs list format: https://github.com/dovecot/core/commit/b4a4a32361b8f0e68ef230add6467eddd0ff… But why? Is fs the only format that works? But maildir++ worked in both 2.3 and in previous versions of 2.4. The 2.4.3 docs (still) also recommend switching to maildir++ if desired: https://doc.dovecot.org/2.4.3/core/plugins/virtual.html#virtual-mailbox-plu… In my config, I use maildir for everything. That means in my mailboxes and all my namespaces. But with this change, I must now use fs as my list format for the virtuals. But, I can't do that, because all `list = yes` namespaces in use by a mailbox must use the same list format... So now my previously invisible virtual folders now cause Dovecot to fall over and I have to completely remove the virtual declarations from my config. What am I supposed to do now?

3 2

Executing a sieve-extprograms pipe script as non-root
by Roland Hieber 29 Mar '26

29 Mar '26

Hi, Ultimately I'm trying to call procmail via a `pipe "procmail";` in my Sieve script on Dovecot 2.4.1. I have therefore created the respective wrapper script in /usr/lib/dovecot/sieve-pipe/procmail, but I noted that the script is apparently run as root. With some debug output in the wrapper script, I see: # `id` output uid=0(root) gid=1059(rhi) groups=1059(rhi),116(dovecot) # `pstree -s -u $$` systemd(1)---dovecot(1064)---lmtp(266577,rhi)---procmail(266706,root)---pstree(266711) This Dovecot gets mail delivered via LMTP from another server. 1059 (rhi) is my local user ID on the IMAP server both in /etc/passwd and in /etc/dovecot/users (using auth-passwdfile.conf.ext in 10-auth.conf instead of auth-system.conf.ext), since mail needs to be delivered and chown'ed correctly into Maildirs that should be user-accessible. However I don't understand how the `procmail` wrapper can be run as the root user rights when the LMTP process starting it is running as my own user?!? I'd like to prevent procmail from running as root as far as possible, so for now I've been able to work around this by wrapping the procmail call into an additional `sudo -U $USER` (after determining the user who owns the target maildir), but I'd like to understand the problem a bit further and like to know if this is really how calling sieve-extprograms is supposed to work – I'd have expected that the external scripts are also run as my unprivileged user. I'm running a fairly standard config on Debian stable (dovecot package version 1:2.4.1+dfsg1-6+deb13u2) with only minimal changes by enabling the passwdfile backend and some sieve plugins. Thanks for any insights, - Roland -- Roland Hieber, Pengutronix e.K. | rhi(a)pengutronix.de | Steuerwalder Str. 21 | https://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

6 8

dovecot 2.4.x director
by Maciej Milaszewski 27 Mar '26

27 Mar '26

HI Has anyone managed to create a fork or other solution that provides director functionality? A small setup where it can be managed, for example, with Rabit/Redis, is one thing, but not a larger environment. The documentation for 2.4.x seems to have something like this: https://doc.dovecot.org/2.4.3/howto/lua_director.html "This is an unsupported method of running Dovecot. Caveat emptor. It is only intended for small-scale deployments – this is NOT designed to scale for more than a few servers."

2 1

Dovecot Security Advisory OXDC-2026-0001
by Aki Tuomi 27 Mar '26

27 Mar '26

Hi! We're sharing our latest advisory with you and like to thank everyone who contributed in finding and solving those vulnerabilities. This advisory is also published at https://documentation.open-xchange.com/dovecot/security/advisories/html/202… --- Internal reference: DOV-7830 Type: CWE-1250 (Improper Preservation of Consistency Between Independent Representations of Shared State) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Last affected revision: OX Dovecot CE core 2.4.0 First fixed revision: OX Dovecot CE core 2.4.1 Discovery date: 2025-07-24 Solution date: 2026-03-27 Disclosure date: 2026-03-27 Researcher credits: Erik <erik(a)broadlux.com> CVE: CVE-2025-30189 CVSS: 7.4 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) Details: v2.4 regression: auth cache broken with several passdb / userdb. When cache is enabled, some passdb/userdb drivers incorrectly cache all users with same cache key, causing wrong cached information to be used for these users. Risk: After cached login, all subsequent logins are for same user. No publicly available exploits are known. Solution: Install fixed version or disable caching either globally or for the impacted passdb/userdb drivers. --- Internal reference: DOV-8349 Type: CWE-20 (Improper Input Validation) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Last affected revision: OX Dovecot CE core 2.4.0 First fixed revision: OX Dovecot CE core 2.4.3 Discovery date: 2025-11-04 Solution date: 2026-03-27 Disclosure date: 2026-03-27 CVE: CVE-2025-59028 CVSS: 5.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) Details: Invalid base64 authentication can cause DoS for other logins. When sending invalid base64 SASL data, login process is disconnected from the auth server, causing all active authentication sessions to fail. Risk: Invalid BASE64 data can be used to DoS a vulnerable server to break concurrent logins. No publicly available exploits are known. Solution: Install fixed version or disable concurrency in login processes (heavy perfomance penalty on large deployments). --- Internal reference: DOV-8508 Type: CWE-20 (Improper Input Validation) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Last affected revision: OX Dovecot CE core 2.4.0 First fixed revision: OX Dovecot CE core 2.4.3 Discovery date: 2025-11-29 Solution date: 2026-03-27 Disclosure date: 2026-03-27 CVE: CVE-2025-59032 CVSS: 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) Details: v2.4/v3.1 regression: Pigeonhole: ManageSieve panic occurs with sieve-connect as a client. ManageSieve AUTHENTICATE command crashes when using literal as SASL initial response. Risk: This can be used to crash ManageSieve service repeatedly, making it unavailable for other users. No publicly available exploits are known. Solution: Control access to ManageSieve port, or disable the service if it's not needed. Alternatively upgrade to a fixed version. --- Internal reference: DOV-8584 Type: CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Last affected revision: OX Dovecot Pro core 2.3.0 First fixed revision: OX Dovecot CE core 2.4.3 Discovery date: 2025-12-29 Solution date: 2026-03-27 Disclosure date: 2026-03-27 Researcher credits: cavid@yeswehack CVE: CVE-2025-59031 CVSS: 4.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) Details: decode2text.sh OOXML extraction may follow symlinks and read unintended files during indexing. Dovecot has provided a script to use for attachment to text conversion. This script unsafely handles zip-style attachments. Risk: Attacker can use specially crafted OOXML documents to cause unintended files on the system to be indexed and subsequently ending up in FTS indexes. No publicly available exploits are known. Solution: Do not use the provided script, instead, use something else like FTS tika. --- Internal reference: DOV-8591 Type: CWE-22 (Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Last affected revision: OX Dovecot Pro core 2.3.0 First fixed revision: OX Dovecot CE core 2.4.0 Discovery date: 2026-01-07 Solution date: 2026-03-27 Disclosure date: 2026-03-27 Researcher credits: strokep@yeswehack CVE: CVE-2026-0394 CVSS: 5.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N) Details: auth: Path traversal in passwd-file passdb using `%d` (domain) escapes base directory and opens `/etc/passwd`Pre-auth path traversal in passwd-file passdb using `%d` (domain) escapes base directory and opens `/etc/passwd`. When dovecot has been configured to use per-domain passwd files, and they are placed one path component above /etc, or slash has been added to allowed characters, path traversal can happen if the domain component is directory partial. Risk: This allows inadvertently reading /etc/passwd (or some other path which ends with passwd). If this file contains passwords, it can be used to authenticate wrongly, or if this is userdb, it can unexpectly make system users appear valid users. No publicly available exploits are known. Solution: Upgrade to fixed version, or use different authentication scheme that does not rely on paths. Alternatively you can also ensure that the per-domain passwd files are in some other location, such as /etc/dovecot/auth/%d. --- Internal reference: DOV-8775 Type: CWE-90 (Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Last affected revision: OX Dovecot CE core 2.4.0 First fixed revision: OX Dovecot CE core 2.4.3 Discovery date: 2026-02-20 Solution date: 2026-03-27 Disclosure date: 2026-03-27 Researcher credits: cookiejack15@yeswehack CVE: CVE-2026-27860 CVSS: 3.7 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N) Details: v2.4/v3.1 regression: auth-ldap is not escaping usernames. If auth_username_chars is empty, it is possible to inject arbitrary LDAP filter to Dovecot's LDAP authentication. Risk: This leads to potentially bypassing restrictions and allows probing of LDAP structure. No publicly available exploits are known. Solution: Do not clear out auth_username_chars, or install fixed version. --- Internal reference: DOV-8781 Type: CWE-89 (Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Last affected revision: OX Dovecot CE core 2.4.0 First fixed revision: OX Dovecot CE core 2.4.3 Discovery date: 2026-02-23 Solution date: 2026-03-27 Disclosure date: 2026-03-27 Researcher credits: whisperer@yeswehack CVE: CVE-2026-24031 CVSS: 7.7 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L) Details: v2.4/v3.1 regression: SQL injection allows bypassing authentication. Dovecot SQL based authentication can be bypassed when auth_username_chars is cleared by admin. Risk: This vulnerability allows bypassing authentication for any user and user enumeration. No publicly available exploits are known. Solution: Do not clear auth_username_chars. If this is not possible, install latest fixed version. --- Internal reference: DOV-8787 Type: CWE-400 (Uncontrolled Resource Consumption) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Last affected revision: OX Dovecot CE core 2.4.0 First fixed revision: OX Dovecot CE core 2.4.3 Discovery date: 2026-02-24 Solution date: 2026-03-27 Disclosure date: 2026-03-27 Researcher credits: djvirus@yeswehack CVE: CVE-2026-27859 CVSS: 5.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) Details: v3.0.2+ regression: Message headers MIME parameter parsing can cause excessive CPU usage. A mail message containing excessive amount of RFC 2231 MIME parameters causes LMTP to use too much CPU. Risk: A suitably formatted mail message causes mail delivery process to consume large amounts of CPU time. No publicly available exploits are known. Solution: Use MTA capabilities to limit RFC 2231 MIME parameters in mail messages, or upgrade to fixed version where the processing is limited. --- Internal reference: DOV-8816 Type: CWE-400 (Uncontrolled Resource Consumption) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Last affected revision: OX Dovecot Pro core 2.3.0 First fixed revision: OX Dovecot CE core 2.4.3 Discovery date: 2026-02-27 Solution date: 2026-03-27 Disclosure date: 2026-03-27 Researcher credits: whisperer@yeswehack CVE: CVE-2026-27857 CVSS: 4.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L) Details: imap-login: Excessive memory usage DoS. Sending "NOOP (((...)))" command with 4000 parenthesis open+close results in ~1MB extra memory usage. Longer commands will result in client disconnection. This 1 MB can be left allocated for longer time periods by not sending the command ending LF. So attacker could connect possibly from even a single IP and create 1000 connections to allocate 1 GB of memory, which would likely result in reaching VSZ limit and killing the process and its other proxied connections. Risk: Attacker could connect possibly from even a single IP and create 1000 connections to allocate 1 GB of memory, which would likely result in reaching VSZ limit and killing the process and its other proxied connections. No publicly available exploits are known. Solution: Install fixed version, there is no other remediation. --- Internal reference: DOV-8818 Type: CWE-400 (Uncontrolled Resource Consumption) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Last affected revision: OX Dovecot Pro core 2.3.0, OX Dovecot CE core 2.4.0 First fixed revision: OX Dovecot CE core 2.4.3 Discovery date: 2026-02-28 Solution date: 2026-03-27 Disclosure date: 2026-03-27 Researcher credits: ilyar@yeswehack CVE: CVE-2026-27858 CVSS: 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) Details: managesieve-login out-of-memory DoS. Attacker can send a specifically crafted message before authentication that causes managesieve to allocate large amount of memory. Risk: Attacker can force managesieve-login to be unavailable by repeatedly crashing the process. No publicly available exploits are known. Solution: Protect access to managesieve protocol, or install fixed version. --- Internal reference: DOV-8830 Type: CWE-287 (Improper Authentication) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Last affected revision: OX Dovecot Pro core 2.3.0 First fixed revision: OX Dovecot CE core 2.4.3 Discovery date: 2026-03-04 Solution date: 2026-03-27 Disclosure date: 2026-03-27 Researcher credits: bksparajuli@yeswehack CVE: CVE-2026-27856 CVSS: 7.4 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) Details: doveadm: Credentials verified without timing safety. Doveadm credentials are verified using direct comparison which is susceptible to timing oracle attack. An attacker can use this to determine the configured credentials. Risk: Figuring out the credential will lead into full access to the affected component. No publicly available exploits are known. Solution: Limit access to the doveadm http service port, install fixed version. --- Internal reference: DOV-8859 Type: CWE-294 (Authentication Bypass by Capture-replay) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Last affected revision: OX Dovecot Pro core 2.3.0 First fixed revision: OX Dovecot CE core 2.4.3 Discovery date: 2026-03-09 Solution date: 2026-03-27 Disclosure date: 2026-03-27 Researcher credits: hamizanazman@yeswehack CVE: CVE-2026-27855 CVSS: 6.8 (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N) Details: auth: OTP driver vulnerable to replay attack. Dovecot OTP authentication is vulnerable to replay attack under specific conditions. If auth cache is enabled, and username is altered in passdb, then OTP credentials can be cached so that same OTP reply is valid. Risk: An attacker able to observe an OTP exchange is able to log in as the user. No publicly available exploits are known. Solution: If authentication happens over unsecure connection, switch to SCRAM protocol. Alternatively ensure the communcations are secured, and if possible switch to OAUTH2 or SCRAM.

1 0

Imap Sieve errors in 2.4.2
by Alberto 26 Mar '26

26 Mar '26

Hi, I have a Dovecot docker image with last version (2.4.2). I'm getting some errors, last time a few minutes ago, when dragging some emails into a folder I had just created. ... Mar 26 10:48:20 imap(alberto(a)bersol.info)<451><wHkgJepNsLRYDtBg>: Info: Mailbox INBOX.carpetanueva: Mailbox created Mar 26 10:48:24 imap(alberto(a)bersol.info)<397><x8N6YuhNMs9YDtBg>: Panic: file imap-sieve-storage.c: line 216 (imap_sieve_add_mailbox_event): assertion failed : (ismt->src_box == NULL || ismt->src_box == src_box) Mar 26 10:48:24 imap(alberto(a)bersol.info)<397><x8N6YuhNMs9YDtBg>: Error: Raw backtrace: #1 [unw_get_proc_name() failed: -10] -> #2 [unw_get_proc_name() failed: -10] -> #3 i_panic[0x7fbaed2ee8ab] -> #4 [unw_get_proc_name() failed: -1] Mar 26 10:48:24 imap(alberto(a)bersol.info)<397><x8N6YuhNMs9YDtBg>: Fatal: master: service(imap): child 397 killed with signal 6 (core dumped) This breaks Dovecot and I have to restart the container, but it doesn't fix it either. When I access again, I've receive this errors again, until I disable sieve in the imap.conf: conf.d/20-imap.conf ------------------- ... protocol imap { # Space separated list of plugins to load (default is global mail_plugins). mail_plugins { # imap_sieve = yes imap_quota = yes last_login = yes } And I have to keep "imap_sieve" disabled. Regards, Alberto

2 1

Issues with doveadm sync
by cryintothebluesky＠gmail.com 21 Mar '26

21 Mar '26

Hello, I have two replica IMAP servers both running dovecot-2.4.2: imap1.example.com imap2.example.com I'm observing the following issues when replicating mailboxes with doveadm sync: 1. Permission errors with public and shared mailboxes For this test I delete all mailboxes on imap2.example.com and then use full sync from imap1.example.com to replicate mailboxes: # doveadm sync -f -s "" -N -l 10 -u ${user:?} ${server:?} The first time I run this command, the following error messages are logged: doveadm(XXX(a)example.com)<1363><eZzOJic5vWlTBQAAMBZ7fQ>: Error: brain S: Can't create mailbox Shared/support(a)example.com: Permission denied doveadm(XXX(a)example.com)<1334><ZV88Byg5vWk2BQAAMBZ7fQ>: Error: brain S: Can't create mailbox Public/Test: Permission denied If I wait 10 seconds and run the same sync command again, all mailboxes are replicated correctly. This only happens with public and shared mailboxes. I'm not sure of the exact cause, but it looks as if there is a race condition, where on the target server replicated ACLs are not applied immediately and this results in permission errors. Can anyone confirm the root cause? 2. Mailboxes are not always synchronised correctly For this test I'm using stateful sync. The man page states it performs a two-way sync, hence both server should end up with the same state. 1) I log into imap2.example.com and move some messages from Inbox to Drafts and Junk folders. 2) On imap1.example.com I run: doveadm sync -s "${state}" -N -l 10 -u ${user:?} ${server:?} 3) I log into imap1.example.com and sometimes observe the recently moved messages missing from Drafts and/or Junk folders. 4) The only way to resolve this issue is to either run full sync from imap1.example.com or to run another stateful sync but from imap2.example.com. Can anyone confirm if this is a bug or if stateful sync is required to be run on both IMAP servers against each other?

1 0

Error: ldap: auth_passdb_post settings
by Ruud Baart 21 Mar '26

21 Mar '26

Dovecot 2.4.1 works fine on my Debian Trixie server. I use LDAP as backend for the users. I don't have problems. Authentication works fine. However logging show every time the following line: auth-worker(<user name@domain,::1)<109040><3v5ddOlJvrgAAAAAAAAAAAAAAAAAAAAB>: request [7]: Error: ldap: auth_passdb_post settings: Failed to parse configuration: Failed to expand passdb_fields/password setting variables: ldap: No such attribute 'userpassword' The LDAP authentication works correct. So I don't understand this message. My correct working LDAP configuration in auth-ldap.conf.ext: passdb ldap { passdb_use_worker = yes passdb_ldap_filter = (&(objectClass=PromptMailUser)(accountStatus=TRUE)(mailDeliveryaddress=%{user})) ldap_bind = yes fields { user = %{ldap:mailDeliveryaddress} password = %{ldap:userPassword} } } userdb ldap { userdb_use_worker = yes userdb_ldap_filter = (&(objectClass=PromptMailUser)(accountStatus=TRUE)(mailDeliveryaddress=%{user})) fields { home = %{ldap:mailBase} mail = %{ldap:mailMessageStore} mail_path = %{ldap:mailMessageStore} quota_storage_size = %{ldap:dovecotQuota} } }

6 21

shared mailbox error
by Marc 19 Mar '26

19 Mar '26

I am getting this error. This file does not exist. Error: t_readlink(/xxxxxx/dbox-alt-root) failed: readlink() failed: Permission denied

2 4

dovecot-2.4.2: doveconf seg fault
by Eray Aslan 16 Mar '26

16 Mar '26

Running dovecot -c /dev/null -n results in: # 2.4.2 (0962ed2104): /dev/null # Pigeonhole version 2.4.2 (767418c3) Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7c0f3a6 in str_to_uint () at ../lib/strnum.c:76 for a user. And the issue seems to be const unsigned char ** vs const char * mismatch: int str_to_uintmax(const char *str, uintmax_t *num_r) { const char *endp = NULL; uintmax_t n; int ret = str_parse_uintmax(str, &n, &endp); if ((ret != 0) || (*endp != '\0')) /* <--- reading via 'const char *' return -1; *num_r = n; return 0; } vs int str_parse_data_uintmax(const unsigned char *data, size_t size, uintmax_t *num_r, const unsigned char **endp_r) { const unsigned char *p = data, *pend = data + size; uintmax_t n = 0; if (p >= pend || *p < '0' || *p > '9') return -1; do { if (n >= ((uintmax_t)-1 / 10)) { if (n > (uintmax_t)-1 / 10) return -1; if ((uintmax_t)(*p - '0') > ((uintmax_t)-1 % 10)) return -1; } n = n * 10 + (*p - '0'); p++; } while (p < pend && *p >= '0' && *p <= '9'); if (endp_r != NULL) *endp_r = p; /* <--- writing via 'const unsigned char *' *num_r = n; return 0; } We don't know enough to choose which one would be preferable so that the interfaces match. It needs an informed decision as it shows up in a bunch of other places as well. More details at: https://bugs.gentoo.org/971191 Thank you -- Eray

1 0

Issues with 2.4.1 & remote postgresql server
by Terry Braun 14 Mar '26

14 Mar '26

Hello, I'm stumped with using a remote postgresql database for authentication. I went through the process once, failed, debugged, failed again. I could successfully use psql to access the remote database from my host machine, so I do not believe the remote access is an issue. I implemented an instance using sqlite3 database and it worked just fine. ``` from auth-sql.conf.ext ``` sql_driver = pgsql pgsql 72.44.55.66 { parameters { sslmode = require user = user password = 123 dbname = db } } I'm using lmtp over sockets to deliver mail to dovecot, in order to isolate any interaction issues. With a postgresql db I get "Mailbox isn't a valid mbox file", but with changes only to auth-sql.conf.ext it fails. I can run the queries from psql and they work. I'm pretty much out of ideas of things to try. - I could not find anything to validate the syntax of the psql data. All the examples had "psql localhots {" - Because of the above, I am wondering if there may be an issue in the postgres driver somehow? - I did look at the documentation for https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-PARAMKEYWO… but I'm unsure what is needed. Thanks for any ideas, help, hints. If someone has an example that works with 2.4.1-4 (7d8c0e5759) on debian 13 that would be great Terry

2 1

How to declare port 143
by Steve Litt 10 Mar '26

10 Mar '26

Hi all, I have Dovecot 2.4.2 working (plain text only) on my Qemu virtual machine, with Claws-Mail able to work with all its files. However, I want to declare the Dovecot server as running on Port 143, and when I do, I dovecot -F throws the error message shown later in this message. If I comment out the explicit port declaration, it works fine, and I want to know why. To the best of my knowledge, my declaration of port 143 exactly matches your 2.4.2 documentation: The following is my attempt to tell Dovecot to serve *explicitly* at port 143: =============================================== # My Dovecot server will operate on Localhost listen = 127.0.0.1 service imap { inet_listener imap-login { port = 143 } # inet_listener imaps { # port = 993 # ssl = yes # } } =============================================== The following is the result: =============================================== [root@dovecotvoid ~]# dovecot -F doveconf: Fatal: Error in configuration file /etc/dovecot/dovecot.conf: duplicate listener: 143:127.0.0.1 [root@dovecotvoid ~]# =============================================== If I comment out the port = 143, it works. Why is it griping about a duplicate listener? At the bottom of this email is the entire dovecot.conf and the result of dovecot -n, and there are no sub-configuration files in conf.d : =============================================== # Start new configs with the latest Dovecot version numbers here: dovecot_config_version = 2.4.2 # Must be current version dovecot_storage_version = 2.4.2 # Must be current version or earlier # 2.3 is minimum # I only want imap protocols { imap = yes lmtp = no pop3 = no } # My Dovecot server will operate on Localhost listen = 127.0.0.1 service imap { inet_listener imap-login { port = 143 } # inet_listener imaps { # port = 993 # ssl = yes # } } # mail_home is only for virtual users # A virtual user is a user with no system account # I have no virtual users, so I've commented out mail_home. #mail_home = /srv/mail/%{user} # mail_driver is the storage format mail_driver = maildir # mail_path is location of top of storage data # WARNING: For troubleshooting be prepared to switch # to literal location of ~ mail_path = ~/mail/Maildir # In my case # mail_home is the home directory of the user identified as ~ # WARNING: system users have no ~ without it. mail_home = /home/slitt # You need a log you can locate # There might not be a log_path=/var/log/dovecot.log #mail_uid = slitt #mail_gid = slitt mail_uid = vmail mail_gid = vmail # By default first_valid_uid is 500. #If your vmail user's UID is smaller, # you need to modify this: #first_valid_uid = uid-number-of-vmail-user namespace inbox { inbox = yes separator = / } # Authenticate as system users: passdb pam { driver = pam #driver = passwd } userdb passwd { driver = passwd } #ssl_server_cert_file = /etc/dovecot/ssl-cert.pem #ssl_server_key_file = /etc/dovecot/ssl-key.pem =============================================== The following is the output of dovecot -n: =============================================== # 2.4.2 (0962ed2104): /etc/dovecot/dovecot.conf # OS: Linux 6.12.71_1 x86_64 # Hostname: dovecotvoid dovecot_config_version = 2.4.2 dovecot_storage_version = 2.4.2 listen = 127.0.0.1 log_path = /var/log/dovecot.log mail_driver = maildir mail_gid = vmail mail_home = /home/slitt mail_path = ~/mail/Maildir mail_uid = vmail protocols { imap = yes lmtp = no pop3 = no } service imap { inet_listener imap-login { port = 143 } } namespace inbox { inbox = yes separator = / } passdb pam { driver = pam } userdb passwd { driver = passwd } ===============================================

5 5

Republish of 2.4.2
by Aki Tuomi 10 Mar '26

10 Mar '26

Hi all! We have republished 2.4.2 packages to fix some packaging issues with Pigeonhole. Please note that for now dovecot-sieve and dovecot-managesieved will get installed together due to dependency issues. Kind regards, Aki Tuomi

1 0

solr-config-9.xml Fails to Load with Solr 9.10.1
by Steven Smith 10 Mar '26

10 Mar '26

I’m trying to use the latest dovecot solr module solr-config-9.xml at with Solr 9.10.1: https://github.com/dovecot/core/blob/956fd0f9a101673be72a7df7d643dd20cf4c40… This dovecot module has been updated to work with version 9.8 and removes the deprecated <lib> directives. However, I observe that it does not load under solr 9.10.1 with the Java exception below. Does anyone have any pointers on how to modify this module for the latest solr versions? var/solr/logs/solr-8983-console.log: > 2026-03-10 01:34:45.983 INFO (main) [] o.a.s.c.CorePropertiesLocator Found 1 core definitions underneath /opt/local/var/solr > 2026-03-10 01:34:45.984 INFO (main) [] o.a.s.c.CorePropertiesLocator Cores are: [dovecot] > 2026-03-10 01:34:46.012 INFO (coreLoadExecutor-13-thread-1) [ x:dovecot] o.a.s.c.SolrConfig Using Lucene MatchVersion: 9.8.0 > 2026-03-10 01:34:46.045 INFO (coreLoadExecutor-13-thread-1) [ x:dovecot] o.a.s.s.ManagedIndexSchemaFactory The schema is configured as managed, but managed schema resource managed-schema.xml not found - loading non-managed schema schema.xml instead > 2026-03-10 01:34:46.064 INFO (coreLoadExecutor-13-thread-1) [ x:dovecot] o.a.s.s.IndexSchema Schema name=dovecot > 2026-03-10 01:34:46.100 ERROR (coreLoadExecutor-13-thread-1) [ x:dovecot] o.a.s.c.CoreContainer SolrCore failed to load on startup =>org.apache.solr.common.SolrException: Unable to create core [dovecot] > at org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1803) I'm trying to use the latest dovecot solr module solr-config-9.xml at with Solr 9.10.1: [1]https://github.com/dovecot/core/blob/956fd0f9a101673be72a7df7d643dd20cf4c… This dovecot module has been updated to work with version 9.8 and removes the deprecated <lib> directives. However, I observe that it does not load under solr 9.10.1 with the Java exception below. Does anyone have any pointers on how to modify this module for the latest solr versions? var/solr/logs/solr-8983-console.log: 2026-03-10 01:34:45.983 INFO (main) [] o.a.s.c.CorePropertiesLocator Found 1 core definitions underneath /opt/local/var/solr 2026-03-10 01:34:45.984 INFO (main) [] o.a.s.c.CorePropertiesLocator Cores are: [dovecot] 2026-03-10 01:34:46.012 INFO (coreLoadExecutor-13-thread-1) [ x:dovecot] o.a.s.c.SolrConfig Using Lucene MatchVersion: 9.8.0 2026-03-10 01:34:46.045 INFO (coreLoadExecutor-13-thread-1) [ x:dovecot] o.a.s.s.ManagedIndexSchemaFactory The schema is configured as managed, but managed schema resource managed-schema.xml not found - loading non-managed schema schema.xml instead 2026-03-10 01:34:46.064 INFO (coreLoadExecutor-13-thread-1) [ x:dovecot] o.a.s.s.IndexSchema Schema name=dovecot 2026-03-10 01:34:46.100 ERROR (coreLoadExecutor-13-thread-1) [ x:dovecot] o.a.s.c.CoreContainer SolrCore failed to load on startup =>org.apache.solr.common.SolrException: Unable to create core [dovecot] at org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1803) References Visible links 1. https://github.com/dovecot/core/blob/956fd0f9a101673be72a7df7d643dd20cf4c40…

1 1

Preventing Plain Auth
by Steve Litt 10 Mar '26

10 Mar '26

Hi all, https://doc.dovecot.org/2.4.2/core/summaries/settings.html , the auth_allow_cleartext section, says "If no, disables the LOGIN command and all other cleartext authentication unless SSL/TLS is used (LOGINDISABLED capability) or the connection is secured (see ssl). See SSL configuration for more detailed explanation of how this setting interacts with the ssl setting. This setting replaces the disable_plaintext_auth setting." I put auth_allow_cleartext = no in my 2.4.2 dovecot.conf, but my Claws-Mail client can still access it, even though there are no key files. I tried putting this setting in several different places: Didn't prevent plain access. I tried switching from 127.0.0.1 to 10.0.2.15, same problem. The following is the output of my dovecot -n command: ========================================= # 2.4.2 (0962ed2104): /etc/dovecot/dovecot.conf # OS: Linux 6.12.74_1 x86_64 # Hostname: dovecotvoid dovecot_config_version = 2.4.2 dovecot_storage_version = 2.4.2 listen = 10.0.2.15 log_path = /var/log/dovecot.log mail_driver = maildir mail_gid = vmail mail_home = /home/slitt mail_path = ~/mail/Maildir mail_uid = vmail protocols { imap = yes lmtp = no pop3 = no } service imap { inet_listener imap-login { auth_allow_cleartext = no } } namespace inbox { inbox = yes separator = / } passdb pam { driver = pam } userdb passwd { driver = passwd } ========================================= How do I disable plain text authentication? Thanks, SteveT Steve Litt http://444domains.com

4 13

[BUG?] Dovecot 2.4.2 from Dovecot repo (RHEL 9) does not implement Sieve (properly/fully)
by Patrick S 09 Mar '26

09 Mar '26

Hi all Below is report of what I suspect is a bug arising in Dovecot 2.4.x regarding Sieve functionality after Pigeonhole functionality was folded into Dovecot/Dovecot-sieve. ISSUE: ====== I am building a new mail server on Rocky Linux 9.7 with Postfix 3.10 and Dovecot 2.4.2. The base installation & setup of Dovecot was OK with core functionality (Postfix interoperability and mail into virtual mail domain mailboxes no problem). Once I had the base setup done I started with Sieve functionality: 1) Incoming mail marked as SPAM by Rspamd auto moved into /Junk 2) Mail manually moved in/out of /Junk handed to Rspamd for training as SPAM/HAM This consistantly failed - the first issue I found was Dovecot failing to restart and `dovecot -n` reporting fatal errors related to sieve — section not found etc. etc. From my reading previously I knew I needed to install `dovecot-sieve` and it was installed before I started working on Sieve functionality. I also saw `dovecot-pigeonhole` but I seemed to read that (version >= 2.4) the functionality for that had been included in `dovecot-sieve` **and** there was no Pigeonhole included in the Dovecot 2.4.2 repo — also if I tried to install it I got errors of course because of the version mismatch, and it was not in the dovecot-2.4-latest repo. ``` # dnf info dovecot-pigeonhole Last metadata expiration check: 1:21:15 ago on Fri 06 Mar 2026 08:05:08. Available Packages Name : dovecot-pigeonhole Epoch : 1 Version : 2.3.16 Release : 15.el9 Architecture : x86_64 Size : 371 k Source : dovecot-2.3.16-15.el9.src.rpm Repository : appstream Summary : Sieve and managesieve plug-in for dovecot URL : https://www.dovecot.org/ License : MIT and LGPLv2 Description : This package provides sieve and managesieve plug-in for dovecot LDA. ``` I also saw `dovecot-managesieved` but as I was **not** going to implement a client sieve functionality I did not install that. Anyway I could not even get to first base with Sieve, Dovecot simply did not know about it. I went on IRC and chatted with Aki Tuomi who confirmed that "yeah, looks like there is some packaging mistake." because the directory `/usr/lib64/dovecot/settings` was empty. As a workaround he suggested "you need to install dovecot-managesieved as workaround". I did that and as a result the following files appeared: ``` -rwxr-xr-x 1 root root 15560 Jan 8 12:13 libmanagesieve_login_settings.so -rwxr-xr-x 1 root root 15840 Jan 8 12:13 libmanagesieve_settings.so -rwxr-xr-x 1 root root 19656 Jan 8 12:13 libpigeonhole_settings.so ``` The `dovecot -n` errors went away, it recognised the sieve directives, and I continued with the Sieve setup. All — `dovecot.conf`, sieve files source and compiled — installed OK. But the sieve functionality simply refused to work. I got advice and we found the following which essentially points to sieve (even with `dovecot-managesieved` installed) not working. After installing everything — dovecot.conf, sieve files (compiled successfully) and a pipe to a shell script to call `rspamc` nothing seemed to happen. * `journalctl -f -u dovecot | grep -E "sieve|pipe"` -> nothing showed * `rspamc stat` -> 'Messages scanned' & 'Messages learned' no increase When we checked we found the following: 1) `lib90_sieve_settings.so` (which should be in `/etc/lib64/dovecot/settings`) is missing from the system. `find / -name "lib90_sieve_settings.so"` -> not found I believe the file is critical for the running of (Dovecot using) Sieve? 2) The Dovecot build options missing any sieve functionality: ``` #dovecot --build-options Build options: ioloop=epoll notify=inotify openssl io_block_size=8192 SQL driver plugins: mysql postgresql sqlite Passdb: ldap pam passwd passwd-file sql Userdb: ldap(plugin) passwd prefetch passwd-file sql ``` I believe (I was told) that minus the above (even though `dovecot-managesieved` was installed as well as `dovecot-sieve`) Sieve simply will not function. Is this a bug/packaging error? Regards Patrick ENVIRONMENT: ============ Software -------- * Rocky Linux 9.7 (RHEL) * Postfix 3.10 Built from source * Postscreen running in Postfix * Dovecot 2.4 installed from Dovecot repo * Valkey 9.0.3 (Redis replacement) * Rspamd 3.14.3 Setup ----- * Rspamd <-> Valkey communicate via Unix socket * Postfix & Dovecot <-> Rspamd via inet port/milter: smtpd_milters = inet:localhost:11332 non_smtpd_milters = inet:localhost:11332 * 'First line defence' = DNSBL via postscreen * Rspamd SPF checking, DKIM signing and DMARC configured All of the above installed, working and tested. DOVECOT PACKAGES INSTALLED: =========================== ``` Name : dovecot Version : 2.4.2 Architecture : x86_64 Source : dovecot-2.4.2-2.src.rpm From repo : dovecot-2.4-latest Name : dovecot-sieve Version : 2.4.2 Architecture : x86_64 Source : dovecot-sieve-2.4.2-2.src.rpm From repo : dovecot-2.4-latest Name : dovecot-managesieved (see note about this in the email) Version : 2.4.2 Architecture : x86_64 Source : dovecot-sieve-2.4.2-2.src.rpm From repo : dovecot-2.4-latest Name : dovecot-submissiond Version : 2.4.2 Architecture : x86_64 Source : dovecot-2.4.2-2.src.rpm From repo : dovecot-2.4-latest Name : dovecot-imapd Version : 2.4.2 Architecture : x86_64 Source : dovecot-2.4.2-2.src.rpm From repo : dovecot-2.4-latest Name : dovecot-lmtpd Version : 2.4.2 Architecture : x86_64 Source : dovecot-2.4.2-2.src.rpm From repo : dovecot-2.4-latest Name : dovecot-lua Version : 2.4.2 Architecture : x86_64 Source : dovecot-2.4.2-2.src.rpm From repo : dovecot-2.4-latest ``` OUTPUT OF `dovecot -n`: ======================= ``` # dovecot -n # 2.4.2-2 (0962ed2104): /etc/dovecot/dovecot.conf # Pigeonhole version 2.4.2-2 (767418c3) # OS: Linux 5.14.0-611.34.1.el9_7.x86_64 x86_64 Rocky Linux release 9.7 (Blue Onyx) # Hostname: srv01.example.com dovecot_config_version = 2.4.2 auth_default_domain = example.com auth_mechanisms = plain auth_username_format = %{user | lower } dovecot_storage_version = 2.4.2 mail_access_groups = vmail mail_control_path = ~/control mail_driver = maildir mail_gid = 5000 mail_home = /var/vmail/%{user | domain }/%{user | username } mail_index_path = ~/indexes mail_path = %{home}/Maildir mail_privileged_group = vmail mail_uid = 5000 mailbox_list_utf8 = yes protocols = imap lmtp sieve_global_extensions { vnd.dovecot.pipe = yes } sieve_pipe_bin_dir = /etc/dovecot/sieve/bin sieve_plugins { sieve_imapsieve = yes sieve_extprograms = yes } sieve_trace_dir = /var/log/dovecot/sieve-trace sieve_trace_level = actions ssl = required syslog_facility = local5 protocol lmtp { mail_plugins { sieve = yes } } ssl_server { cert_file = /etc/ssl/server/server_example_com.crt key_file = /etc/ssl/server/server_example_com.key } passdb passwd-file { auth_username_format = %{user | username} default_password_scheme = SHA512-CRYPT passwd_file_path = /etc/dovecot/passwd } userdb passwd-file { auth_username_format = %{user | username} passwd_file_path = /etc/dovecot/passwd fields { gid:default = 5000 uid:default = 5000 } } service lmtp { unix_listener /var/spool/postfix/private/dovecot-lmtp { group = postfix mode = 0600 user = postfix } } service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } } service imap-login { inet_listener imap { port = 0 } inet_listener imaps { port = 993 ssl = yes } } service auth-worker { user = $SET:default_internal_user } service anvil { unix_listener anvil { group = $SET:default_internal_group mode = 0660 } } service doveadm { unix_listener doveadm-server { mode = 0600 user = $SET:default_internal_user } } sieve_script rspamd_to_junk { driver = file path = /etc/dovecot/sieve/rspamd-to-junk.sieve type = before } namespace inbox { mail_plugins { imap_sieve = yes } inbox = yes mailbox Junk { auto = create autoexpunge = 90d special_use = "\\Junk" sieve_script report-spam { cause = copy path = /etc/dovecot/sieve/report-spam.sieve type = before } } imapsieve_from Junk { sieve_script report-ham { cause = copy path = /etc/dovecot/sieve/report-ham.sieve type = before } } mailbox Drafts { auto = subscribe special_use = "\\Drafts" } mailbox Sent { auto = subscribe special_use = "\\Sent" } mailbox Trash { auto = subscribe special_use = "\\Trash" } } ```

4 7

Curve25519/Ed25519 ?
by Steve Litt 09 Mar '26

09 Mar '26

On my new Dovecot 2.4.2 IMAP server, which when completed will be accessible only via SSL, I plan to use Curve25519/Ed25519 self-signed-cert/private-key. Is there any reason this would be a mistake? Thanks, SteveT Steve Litt http://444domains.com

2 2

Dovecot 2.4 doveadm_worker_count corrupts tab-formatted output
by Philip Iezzi 08 Mar '26

08 Mar '26

Hi there On a Dovecot 2.4.2 (Debian Bookworm) server with over 1300 users, I am using the following config to retrieve quota usage information with doveadm: --------------------------------------- quota "User quota" { } mail_plugins = quota acl mail_log notify userdb sql { iterate_query = SELECT username AS user, CONCAT(quota, 'M') AS quota_storage_size FROM mailaccounts WHERE active = 1 query = \ SELECT '/var/vmail/%{user | domain}/%{user | username}' AS home, 'vmail' AS uid, 'vmail' AS gid, CONCAT(quota, 'M') AS quota_storage_size \ FROM mailaccounts \ WHERE username = '%{user}' AND (active = 1 OR transport_suspended = 0) } --------------------------------------- Initially, I had to run `doveadm quota recalc -A` to recalc quotas and populate the `count` quota driver which is enabled by default for "User quota". But still, it took roughly 20ms per single user or 15-20s for all users: $ time doveadm -f tab quota get -u demo(a)example.com real 0m0.020s $ time doveadm -f tab quota get -A real 0m16.800s Now, to greatly speed this up, I have introduced parallel processing: doveadm_worker_count = 4 Like this, `doveadm -f tab quota get -A` runs approx 10x faster, done in 1.5 - 2.5s But there is one major drawback which I assume to be a bug: # sane output without `doveadm_worker_count = 4` => always 6 fields demo(a)example.com User quota STORAGE 29 204800 0 demo(a)example.com User quota MESSAGE 1 - 0 # broken output with `doveadm_worker_count = 4` => sometimes 7 fields demo(a)example.com User quota STORAGE 29 2048 00 0 demo(a)example.com User quota MESSAGE 1 - 0 Somehow, the tab formatter does not play nicely together with parallel processing. On some output, the value gets split apart by an extra tab, e.g. '2024<TAB>00' in above example. Can you explain this corrupted data? Some kind of "output interleaving" seems to happen when running parallel workers. If I switch to json output (`doveadm -f json quota get -A`), this does not seem to happen and I always get valid JSON output, even with `doveadm_worker_count = 4`. Cheers, Philip

2 8

Getting quota limits from DB
by Alberto 04 Mar '26

04 Mar '26

Hi group: I have a Docker Dovecot 2.4.2 installation with MySQL user management, with this record: SELECT * FROM users; +---------------------------------------------------------------------------- | username | domain | password | home | uid | gid | active | quota | quotamsgs | crampassword +---------------------------------------------------------------------------- | alberto | bersol.info | {MD5-CRYPT}$1$Jm... | /var/mail/alberto | 1000 | 1000 | Y | 3221225472 | 149999 | {CRAM-MD5}fd246... | +---------------------------------------------------------------------------- But I have a problem with user quota definitions... If I run "doveadm" command, I get the user quota occupation, I have "quota_clone" plugin working, but I don't get user quota limit, I don't know why: ----- # docker exec -it midovecot doveadm quota get -A Username Quota name Type Value Limit % alberto(a)bersol.info User quota STORAGE 1925805 3145728 61 alberto(a)bersol.info User quota MESSAGE 37608 100000 37 ----- That limit isn't the correct limit set in DB, but the one is put in the config, and it must to be override in my userdb:Extra Fields. ----- # # docker exec -it midovecot doveadm config # 2.4.2 (0962ed2104): /etc/dovecot/dovecot.conf ... userdb sql { iterate_query = SELECT CONCAT(username,'@',domain) AS user FROM users query = SELECT home,CONCAT(username,'@',domain) AS username,crampassword AS password,uid AS userdb_uid,gid AS userdb_gid,CONCAT(quota,'B') AS userdb_quota_storage_size,concat('*:messages=',quotamsgs) AS userdb_quota_storage_size FROM users WHERE username = '%{ user | username | lower }' AND domain = '%{ user | domain | lower }' } ... quota_storage_size = 3G quota_message_count = 100000 ... ----- Do you have any idea of the problem? Best Regards, Alberto

2 3

Dovecot marking outgonig emails as unread
by stef204 03 Mar '26

03 Mar '26

Starting a few days ago, I have one email account where ALL outgoing emails are automatically marked as UNREAD. The message is sent, then copied to the "Sent" folder, and has status "unread". Then, a couple of minutes later, something happens where this message gets marked as UNREAD, without ANY interaction of client side. This occurs not matter the email client used, I have tried it with multiple email clients, both local and via web interface, the behavior does not change. This is via Dovevot on Cpanel. if I look at the [1]changelog, it is difficult to identify which changes could have triggered this as there seem to be changes impacting Dovecot almost with every update. I do not control the server myself, this is on a shared hosting plan; tech support has been willing to troubleshoot but is unable to locate the problem. This problem does NOT occur on other email accounts on the same domain, so it looks to me like some corruption or problem syncing flags perhaps? I am at a loss at the moment to fix this behavior. Any suggestions or ideas welcome. Thanks. References Visible links 1. https://docs.cpanel.net/changelogs/132-change-log/

3 5

[Pigeonhole] extracttext on "message/rfc822" attachment ignores included headers
by quentinduchemin＠tuta.io 03 Mar '26

03 Mar '26

Hi everyone! I'm not sure this is a design decision, a bug, something not implemented or malformed input on my side. My use case is the following: users that forward their mails outside the domain I manage have the option to report spam as attachment so the spam classifier can learn anyway. I prefer attachment over forward because MUAs have their own way to do it and it's difficult to reliably reconstruct some headers/email structure that can be important for the spam classifier. Each input message is processed through a Sieve extensions of RFC 5703 to extract the attachment. I ask user to produce a file with .eml extension through any export-like feature of their MUA. Below is an example EML file produced by Tuta (Thunderbird does a similar thing with a different encoding for the body). I'll use a bunch of = characters as a separator in the rest of this. =============================================== [...bunch of header...] X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-0000000000 00 X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYSPR04MB7035 Content-Type: multipart/related; boundary="------------79Bu5A16qPEYcVIZL@tutanota" --------------79Bu5A16qPEYcVIZL@tutanota Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXB0b3MsIEFwdG9zX0VtYmVkZGVkRm9udCwgQXB0b3 NfTVNGb250U2VydmljZSwgQ2FsaWJyaSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 [...base64 encoding of the body...] =============================================== While attached and sent, the received messaged looks like this: =============================================== [...headers of the actual email...] X-Infomaniak-Routing: alpha This is a multi-part message in MIME format. --------------5jyKrhQ08xXUif7LHhgg648N Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit --------------5jyKrhQ08xXUif7LHhgg648N Content-Type: message/rfc822; name="a.eml" Content-Disposition: attachment; filename="a.eml" Content-Transfer-Encoding: 7bit [...headers of the spam....] Subject: Re: //Re: AI + Ranking /// Thread-Topic: //Re: AI + Ranking /// [....] Content-Type: multipart/related; boundary="------------79Bu5A16qPEYcVIZL@tutanota" --------------79Bu5A16qPEYcVIZL@tutanota Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXB0b3MsIEFwdG9zX0VtYmVkZGVkRm9udCwgQXB0b3 NfTVNGb250U2VydmljZSwgQ2FsaWJyaSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 [...base64 encoding of the spam....] --------------79Bu5A16qPEYcVIZL@tutanota-- --------------5jyKrhQ08xXUif7LHhgg648N-- =============================================== I face two issues: 1. Only the base64 decoded string can be retrived through foreverypart/extracttext; 2. It has a lot of newlines. - 2. is not a big deal. The original spam has a lot of HTML junk, and each line with HTML without an inner text node is stripped, but the newline is kept. I don't know if this is intended. - 1. is more of a big deal. To try to confirm that, I made an over-simplified version of the Sieve script (I skip configuration but plugins are loaded etc, please ask if useful). =============================================== [...require...] foreverypart { extracttext "eml"; debug_log "PART ============================== ${eml}"; } =============================================== mail_debug is activated. In the logs, I can read: =============================================== Info: sieve: DEBUG: PART ============================== Info: sieve: DEBUG: PART ============================== Info: sieve: DEBUG: PART ============================== Info: sieve: DEBUG: PART ============================== Info: sieve: DEBUG: PART ============================== Info: sieve: Info: sieve: Info: sieve: Info: sieve: Info: sieve: Info: sieve: Info: sieve: Hello, Info: sieve: Info: sieve: Hope you're doing well. Info: sieve: Info: sieve: Info: sieve: Info: sieve: Info: sieve: Would you like attract more traffic with our AEO + GEO + SEO services. AI-driven search is here—don’t miss out. =============================================== So multiple parts are analyzed but only the last gives something. The RFC says that "If the transfer encoding or character set is unrecognized by the implementation or recognized but invalid, an empty string will result.". But it's over my knowledge. I activated trace for Sieve with "matching" level, and the file looks like (this is another test but was the same result): =============================================== Sieve trace log for message delivery: Username: REDACTED Session ID: ozNMOEPNl2nlAAAAO14Lzw Sender: REDACTED Final recipient: REDACTED Default mailbox: INBOX ## Started executing script 'move-spam' 33: foreverypart loop begin 33: loop ends at line 36 35: extracttext command 36: assign 'eml' [0] = "" 36: debug_log "PART ============================== " 36: foreverypart loop end 36: switched to next message part 36: looping back to line 35 35: extracttext command 36: assign 'eml' [0] = "" 36: debug_log "PART ============================== " 36: foreverypart loop end 36: switched to next message part 36: looping back to line 35 35: extracttext command 36: assign 'eml' [0] = "" 36: debug_log "PART ============================== " 36: foreverypart loop end 36: switched to next message part 36: looping back to line 35 35: extracttext command 36: assign 'eml' [0] = "" 36: debug_log "PART ============================== " 36: foreverypart loop end 36: switched to next message part 36: looping back to line 35 35: extracttext command 36: assign 'eml' [0] = "Hi, Just checking in to see if you had a chance to review my earlier message. [...body spam....] 36: debug_log "PART ============================== ????????????Hi, ?? ??Just checking in t..." 36: foreverypart loop end 36: no more message parts 36: exiting loops at line 36 ## Finished executing script 'move-spam' =============================================== Hypothesis: A. Could it be because the mail headers are indistinguishable from the part headers? B. Or is it related to Pigeonhole not implementing yet the enclose extension, which do this the other way? I hope this message is not too hard to read with all the code/logs. Please tell me if there is a better way of doing it. And thanks in advance for any help, because I don't really know what to do and trying to take a (superficial) look at the Pigeonhole code didn't helped.

1 2

Panic: file imap-sieve-storage.c: line 216 (imap_sieve_add_mailbox_event): assertion failed: (ismt->src_box == NULL || ismt->src_box == src_box)
by Christian Kivalo 28 Feb '26

28 Feb '26

Reposting my reply from a few days ago to a thread with the same panic message. I found this in my logs when some mails that got deleted on the phone were still visible in roundcube. I currently have three users that trigger the panic. One user with an iPad accounts for nearly all of the panics. The problem shows when the account is accessed from android (thunderbird) or ipad. The same accounts show no problems when beeing used with roundcube or thunderbird on windows. I enabled core dumps on 2026-01-14 and have ~8500 core dumps of the imap binary until now. What causes this error and how can I fix it? In the logs all I see is the users login, then the panic. # doveconf -n # 2.4.2-2+debian13 (0962ed2104): /etc/dovecot/dovecot.conf # Pigeonhole version 2.4.2-2+debian13 (767418c3) # OS: Linux 6.12.0-custom.kvm x86_64 Debian 13.3 ext4 2026-01-13T21:44:32.317609+01:00 uschi dovecot: imap-login: Logged in: user=<user(a)example.com>, method=PLAIN, rip=<IP1>, lip=<IP2>, mpid=4194077, TLS, session=<cpkID0tId7dUc9rl> 2026-01-13T21:44:38.455379+01:00 uschi dovecot: imap(user(a)example.com)<4194077><cpkID0tId7dUc9rl>: Panic: file imap-sieve-storage.c: line 216 (imap_sieve_add_mailbox_event): assertion failed: (ismt->src_box == NULL || ismt->src_box == src_box) 2026-01-13T21:44:38.458755+01:00 uschi dovecot: imap(user(a)example.com)<4194077><cpkID0tId7dUc9rl>: Error: Raw backtrace: #1 [unw_get_proc_name() failed: -10] -> #2 [unw_get_proc_name() failed: -10] -> #3 i_panic[0x7f6b6c46c2f6] -> #4 [unw_get_proc_name() failed: -10] -> #5 [unw_get_proc_name() failed: -10] -> #6 [unw_get_proc_name() failed: -10] -> #7 mailbox_save_alloc[0x7f6b6ca103c0] -> #8 [unw_get_proc_name() failed: -10] -> #9 command_exec[0x55654e677400] -> #10 [unw_get_proc_name() failed: -10] -> #11 [unw_get_proc_name() failed: -10] -> #12 [unw_get_proc_name() failed: -10] -> #13 client_handle_input[0x55654e67ddc0] -> #14 client_continue_pending_input[0x55654e67e0b0] -> #15 io_loop_call_io[0x7f6b6c565490] -> #16 io_loop_handler_run_internal[0x7f6b6c567230] -> #17 io_loop_handler_run[0x7f6b6c5673c0] -> #18 io_loop_run[0x7f6b6c5675a0] -> #19 master_service_run[0x7f6b6c4b27f0] -> #20 main[0x55654e6688a0] -> #21 [unw_get_proc_name() failed: -10] -> #22 __libc_start_main[0x7f6b6c234ce0] -> #23 _start[0x55654e668eb0] 2026-01-13T21:44:38.459536+01:00 uschi dovecot: imap(user(a)example.com)<4194077><cpkID0tId7dUc9rl>: Fatal: master: service(imap): child 4194077 killed with signal 6 (core dumps disabled - https://dovecot.org/bugreport.html#coredumps) # coredumpctl dump PID: 1071230 (imap) UID: 5000 (vmail) GID: 5000 (vmail) Signal: 6 (ABRT) Timestamp: Fri 2026-01-16 19:17:15 CET (2s ago) Command Line: $'dovecot/imap [user(a)example.com <IP redacted> UID MOVE]' Executable: /usr/lib/dovecot/imap Control Group: /system.slice/dovecot.service Unit: dovecot.service Slice: system.slice Boot ID: 3668d179bda340229a780d5d43e426c3 Machine ID: 05698baa30ae984c9bd014566e16da18 Hostname: uschi Storage: /var/lib/systemd/coredump/core.imap.5000.3668d179bda340229a780d5d43e426c3.1071230.1768587435000000.zst (present) Size on Disk: 1.1M Message: Process 1071230 (imap) of user 5000 dumped core. Module libgcc_s.so.1 from deb gcc-14-14.2.0-19.amd64 Module libstdc++.so.6 from deb gcc-14-14.2.0-19.amd64 Module libzstd.so.1 from deb libzstd-1.5.7+dfsg-1.amd64 Stack trace of thread 1071230: #0 0x00007fbd1ca9f95c n/a (libc.so.6 + 0x9495c) #1 0x00007fbd1ca4acc2 raise (libc.so.6 + 0x3fcc2) #2 0x00007fbd1ca334ac abort (libc.so.6 + 0x284ac) #3 0x00007fbd1cc6caa0 n/a (libdovecot.so.0 + 0x6caa0) #4 0x00007fbd1cd49e67 n/a (libdovecot.so.0 + 0x149e67) #5 0x00007fbd1cc6c3d0 i_panic (libdovecot.so.0 + 0x6c3d0) #6 0x00007fbd1c42f942 n/a (lib95_imap_sieve_plugin.so + 0x4942) #7 0x00007fbd1c431223 n/a (lib95_imap_sieve_plugin.so + 0x6223) #8 0x00007fbd1d258f10 n/a (libdovecot-storage.so.0 + 0x11bf10) #9 0x00007fbd1d1a843b mailbox_save_alloc (libdovecot-storage.so.0 + 0x6b43b) #10 0x00005590b7ed4a69 n/a (n/a + 0x0) ELF object binary architecture: AMD x86-64 -- Christian Kivalo

5 12

LDAP AD Quota override not working
by wt.forsaken＠gmail.com 26 Feb '26

26 Feb '26

Hi there, I'm testing the new version of Dovecot 2.4 in Debian 13 before upgrading to my customers and I'm having difficult on trying to override the user's quota. The LDAP base is from Samba4 AD and having been trying the following configuration: auth-ldap.conf.ext: ldap_uris = ldap://localhost ldap_auth_dn = cn=admin,dc=localdomain ldap_auth_dn_password = password ldap_base = ou=users, dc=localdomain passdb ldap { filter = (&(objectClass=person)(sAMAccountName=%{user})) bind = yes fields { userdb_quota_storage_size = %{ldap:telephoneNumber}B } } userdb prefetch { driver = prefetch } userdb ldap { fields { quota_storage_size = %{ldap:telephoneNumber}B } } 90-quota.conf mail_plugins { quota = yes } quota "User quota" { } quota_storage_size = 40M Since there is no quotaBytes in Samba AD, I'm testing to map the telephoneNumber parameters to override the quota, also I'm just testing a 40M to see how it works. Roundcube webmail can see the quota being overriden in its inferior bar, but when I send an email to the user which is above the quota, the journal log inform "failed to store into mailbox 'INBOX': Quota exceeded (mailbox for user is full)". I don't know how to override the quota, since in passdb section I used the "userdb_" prefix but it is not being passed to userdb when I input the "doveadm user ..." command. I don't know if I have been clear in my request, but I'd appreciate any help.

3 3

Dovecot 2.4 LMTP socket for Postfix / Dovecot base_dir not created upon restart
by Philip Iezzi 24 Feb '26

24 Feb '26

Hi there, After over a week of Dovecot 2.3 -> 2.4 upgrade testing in various mailserver clones, I am now ready for the big picture. Thanks Aki for the Config Upgrader https://dovecot.org/upgrader/ which helped a lot! Tomorrow, I am planning to upgrade a larger mailserver in these 3 steps: 1) Debian Bullseye / Dovecot 2.3.21 => 2.4.1 2) Debian Bullseye => Bookworm / Dovecot 2.4.1 => 2.4.2 3) Debian Bookworm => Trixie Postfix needs to talk to Dovecot over LMTP, using the following in main.cf: virtual_transport = lmtp:unix:/run/dovecot/lmtp Now, while testing this in a full server clone, I stepped over my planned LMTP server setup: =============================================== service lmtp { unix_listener /run/dovecot/lmtp { mode = 0666 user = postfix group = postfix } } protocols = imap pop3 sieve lmtp =============================================== The socket needs to be owned by postfix:postfix for some (security) reasons, otherwise Postfix complains. That's why I cannot go with the default, as documented here: https://doc.dovecot.org/2.4.2/core/config/delivery/lmtp.html#lmtp-server > The UNIX listener on $base_dir/lmtp is enabled by default when protocols setting contains lmtp. But, when using an absolute path on unix_listener, upgrade step 2) Bullseye=>Bookworm breaks with: Processing triggers for dovecot-core (2:2.4.2-2+debian12) ... Job for dovecot.service failed because the control process exited with error code. (...) dovecot[34446]: master: Error: service(lmtp): Socket already exists: /var/run/dovecot/lmtp dovecot[34446]: master: Fatal: Failed to start listeners I then moved to `unix_listener lmtp`: service lmtp { unix_listener lmtp { mode = 0666 user = postfix group = postfix } } Bookworm upgrade (restarted from scratch with a fresh server clone) went through fine. But even after several dovecot.service restarts, the socket ended up in /run/lmtp without creating the /run/dovecot directory, and after a full system reboot, it was suddenly back where I have expected it: /run/dovecot/lmtp I never changed base_dir, which defaults to /var/run/dovecot/ So, here's my question: Is that really the recommended setup (using `inet_listener lmtp` instead of an absolute path) and how can I trust Dovecot to always create the socket in $base_dir/lmtp as documented? Are you guys aware of this issue or was it just me, a temporary hiccup on my just upgraded server? I just found this in mail.log: dovecot: master: Error: bind(/var/run/dovecot/lmtp) failed: No such file or directory dovecot: master: Error: service(lmtp): net_listen_unix(/var/run/dovecot/lmtp) failed: No such file or directory dovecot: master: Fatal: Failed to start listeners Again, this problem seems to have occurred both with `unix_listener /run/dovecot/lmtp` and `unix_listener lmtp` and only resolved after a full system reboot. Thanks, Philip

2 2

Migrating a mailbox from v2.2 to v2.4, production server to pre-production server.
by Mike 23 Feb '26

23 Feb '26

I'm migrating a mailbox from dovecot v2.2 to v2.4. Not that it matters, I'm also changing from mbox to Maildir. As an initial test I used this command: sudo doveadm sync -1D -u theuser -m amailbox remote:theuser@destination.com I received this error: Error: doveadm: Unexpected or incomplete option: -U After changing the dsync_remote_cmd to: dsync_remote_cmd = ssh -l%{login} %{host} doveadm dsync-server -u%u I was able to transfer the mailbox without issue. Before changing it, the setting on the source server was: dsync_remote_cmd = ssh -l%{login} %{host} doveadm dsync-server -u%u -U I'm interested to discover what the -U was intended for since I couldn't find specific documentation to its use. I'll accept that it was a legacy thing and removing it won't cause any unintended consequences...but I do still have that curiosity about what it was for. Additionally, the subscription status doesn't seem to flow to the new server. When checking the source server with: doveconf -d | grep subscriptions doveconf -n | grep subscriptions No value is returned...So I'm wondering if I need to specifically set subscriptions = yes in the source server to make this happen properly. Maybe this is an artifact of using sync -1? Thanks for any insight you may provide. Mike

1 0

Localhost Dovecot server without ssl?
by Steve Litt 23 Feb '26

23 Feb '26

Hi all, I'd like your opinions to add to my own opinion. Bottom line question: If I trust everybody with physical access to my Daily Driver Desktop (DDD) computer, my Dovecot IMAP runs on my DDD, I access my Dovecot IMAP *exclusively* from my DDD, and I trust everybody with physical access to my DDD (that would be my wife), then if I serve out IMAP on localhost (127.0.0.1), am I being unduly risky using plain text auth (port 143)? Details: I use a Dovecot IMAP server, on my DDD, specifically to hold all my email messages. Therefore, I can use any IMAP aware email client, interchangeably, to view every email I've received since April 2001. People whose emails are held by their email clients are "locked in" to their email client unless they convert their email data. I can switch between Evolution and Claws-Mail, because one of the two is always doing something stupid. Bottom line: I use Dovecot IMAP exclusively to hold my emails and folders. Graphical description below: ISP ---> My --------> procmail --> Dovecot IMAP fetchmail Maildir | | V email <--- Dovecot client IMAP server For the time being, I don't need to access my Dovecot IMAP from any computer except my DDD, and therefore, I can serve Dovecot IMAP on 127.0.0.1. So here's my question. Assuming (and I know this is a big assumption) I'm not worried about somebody gaining physical possession of my DDD, is there any reason not to use plain text to access this server? Thanks, SteveT Steve Litt http://444domains.com

2 1

Copies/duplicates of Dovecot indices
by Joseph Tam 23 Feb '26

23 Feb '26

In my setup, I put mail indices outside the user's mailbox locations (user mailboxs are NFS, indices stored local attached storage). I notice that sometimes, there are 2 sets of indices representing the same mailbox: one at top level, one underneath .imap/. (They usually appear in the latter.) For example, if I have the configuration (Dovcot version 3.2.21) mail_location = mbox:~/mail:INBOX=/nfs/mail/%n:INDEX=/cache/%n I see for a particular user [1] drwx------ 5 user group 512 Feb 22 21:56 /cache/user/box [2] drwxr-xr-x 5 user group 512 Feb 22 21:46 /cache/user/.imap/box cooresponding to their mailbox in ~user/mail/box. Each of these have the dovecot.* index files. If I delete [1], it comes back. The timestamps are close to each other so both sets are being used, possibly by different clients. Another quirky discovery is 2 /.imap/ folders beneath each other e.g. /cache/user/.imap/folder1/folder2/.imap/box/dovecot.index What determines which index pathname gets created or used? Joseph Tam <jtam.home(a)gmail.com>

1 0

2.3 replication issue throwing errors
by Paul Kudla 22 Feb '26

22 Feb '26

shows same error on both servers Server 1 : # sync faye(a)scom.ca doveadm(faye(a)scom.ca)<90952><BJq9J2dHmGlIYwEA0dxyZQ>: Warning: Mailbox changes caused a desync. You may want to run dsync again: Remote lost mailbox GUID f982a82747469869ea0f0100cf58dcff (maybe it was just deleted?) Server 2: # sync faye(a)scom.ca doveadm(faye(a)scom.ca)<90952><BJq9J2dHmGlIYwEA0dxyZQ>: Warning: Mailbox changes caused a desync. You may want to run dsync again: Remote lost mailbox GUID f982a82747469869ea0f0100cf58dcff (maybe it was just deleted?) i am aware there is a mismatch on one of the servers but there does not seem to be a clear cut way to find the offending file to delete it or force a backwards sync ? How would i identify what GUID f982a82747469869ea0f0100cf58dcff means? same on both servers. doveadm force-resync -u faye(a)scom.ca '*' have tried reindex etc etc etc issue persists logs ?? mail18 02-20 06:45:24 {dovecot} [67632] (3014654310) doveadm(faye(a)scom.ca)<71073><hOl0ClRJmGmhFQEAz1jc/w>: Debug: open(/proc/self/stat) failed: No such file or directory mail18 02-20 06:45:24 {dovecot} [67632] (3014654311) doveadm(faye(a)scom.ca)<71073><hOl0ClRJmGmhFQEAz1jc/w>: Debug: open(/proc/self/io) failed: No such file or directory mail18 02-20 06:45:24 {dovecot} [67632] (3014654312) doveadm(faye(a)scom.ca)<71073><hOl0ClRJmGmhFQEAz1jc/w>: Debug: Namespace inbox: type=private, prefix=, sep=/, inbox=yes, hidden=no, list=yes, subscriptions=yes location=maildir:~/ any help would be appreciated -- Thanks - Paul Kudla (Manager SCOM.CA Internet Services Inc.) Have A Happy Friday AND Happy Sucessful 2026 ! Scom.ca Internet Services <http://www.scom.ca> 104-1009 Byron Street South Whitby, Ontario - Canada L1N 4S3 Toronto 416.642.7266 Main 1.866.411.7266 Fax 1.888.892.7266 Email paul(a)scom.ca

2 2

How do you use doveadm fetch -S
by Steve Litt 20 Feb '26

20 Feb '26

Hi all, I have a working plain text 127.0.0.1:143 Dovecot 2.4.2 on my Qemu VM guest. The following command displays the Receive date, From and Subject for every email in my golugTech mailbox, exactly like the docs say it should: =================================================== doveadm fetch -u slitt "date.received hdr.from hdr.subject" mailbox golugTech =================================================== But when I add the -S in order to specify the 127.0.0.1 listener at port 143, it throws the following error: =================================================== [slitt@mydesk ~]$ cat junk.jnk [root@dovecotvoid dovecot]# doveadm fetch -S 127.0.0.1:143 -u slitt "date.received hdr.from hdr.subject" mailbox golugTech doveadm(slitt): Error: conn 127.0.0.1:143 (127.0.0.1:143): doveadm server sent invalid handshake: * OK Waiting for authentication process to respond.. doveadm(slitt): Error: cmd fetch: 127.0.0.1:143: Command fetch failed for slitt: Connection closed [root@dovecotvoid dovecot]# [slitt@mydesk~]$ =================================================== The docs say -S is to specify the socket_path, and it should be expressed as hostname:port. For hostname, besides 127.0.0.1, I tried localhost and dovecotvoid, the latter of which should not work because dovecotvoid is not 127.0.0.1, it's 10.0.2.15. The docs say "This allows an administrator to execute doveadm(1) mail commands through the given socket." So I guess finding the server isn't the purpose of socket_path. My plain text 143 Dovecot 2.4.2 IMAP works just fine without the -S. Is there ever a case where doveadm fetch would need to know the specific address and port of the dovecot IMAP server, and if so, how would I specify it? Thanks, SteveT Steve Litt http://444domains.com

2 1

What replaced mail_home in 2.4.2?
by Steve Litt 20 Feb '26

20 Feb '26

Hi all, In my Dovecot 2.4.2 virtual machine guest I've used mail_home to indicate the value of ~ and presumably of ${home}. However, the only documentation I can find on mail_home is on https://doc.dovecot.org/main/core/summaries/settings.html#mail_home , which is NOT a 2.4.2 document. I find no reference to mail_home on any 2.4.2 documentation. Has something replace mail_home, and if so what's it called and can I put it outside of any {} blocks? Thanks, SteveT Steve Litt http://444domains.com

2 2

mail_utf8_extensions and IMAP Folder Naming
by max.wriedt＠rehost.eu 20 Feb '26

20 Feb '26

i just upgraded my 2.3 installation to 2.4. I like to be bleeding edge and i want to use SMTPUTF8. I came across problems with mailboxes that have german umlauts. when enabling "mail_utf8_extensions=yes" e.g. Microsoft Outlook gives me mUTF-7 encoded folder names. Also the folder names when list via openssl s_client are encoded in mUTF-7. Am i missing something or can i disable utf8 for IMAP (UTF8=ACCEPT) only, but keep for LMTP Transport/SMTPUTF8 from postfix to dovecot? I am using mdbox format as storage, if that matters. My namespace config (shortened): namespace inbox { inbox = yes type = private #mailbox_list_utf8 = yes # also tried this -> when folder didn't exist before it would create a new one with utf8, no matter mail_utf8_extensions is on or off mailbox Drafts { auto = no special_use = \Drafts } mailbox Entw&APw-rfe { special_use = \Drafts } mailbox Entw%26APw-rfe { special_use = \Drafts } mailbox Entw\&APw-rfe { special_use = \Drafts } mailbox Entwürfe { auto = create special_use = \Drafts } mailbox Trash { auto = no special_use = \Trash quota_storage_percentage = 110 } mailbox "Gel&APY-schte Elemente" { special_use = \Trash quota_storage_percentage = 110 } mailbox "Gelöschte Elemente" { auto = subscribe special_use = \Trash quota_storage_percentage = 110 } mailbox Sent { auto = no special_use = \Sent } mailbox Archiv { auto = subscribe special_use = \Archive } mailbox Spam { special_use = \Junk auto = no } }

3 4

2.4.2 breaks user iterations for LDAP
by cpfeiffer＠rev-crew.info 20 Feb '26

20 Feb '26

Hello everyone, Due to the fix for CVE-2025-30189, routines like userdb_ldap_preinit() call auth_cache_parse_key_and_fields() unconditionally, with the eventually called auth_cache_parse_key_exclude() erroring if a cache key could not be constructed. It’s also noteworthy that this call happens regardless of whether use_cache is set or not, and as of such failing to construct a cache key would cause an error even if use_cache = no was set for that database. This is however an issue for user iteration with LDAP, as documented here LDAP | Dovecot CE <https://doc.dovecot.org/2.4.2/core/config/auth/databases/ldap.html#user-ite…> . Such a userdb only has iterate_filter fields that would inherently not be containing any user variables. The call to auth_cache_parse_key_and_fields() uses a combination of ldap_base and userdb_ldap_filter anyway (so whatever is in iterate_filter isn’t considered), and for an iteration userdb as described in the documentation, the latter would be empty. Alas, I ended up getting the rather confusing error * auth: Fatal: auth-cache: dc=rev-crew,dc=info: Cache key must contain at least one variable With dc=rev-crew,dc=info being my ldap_base setting for the iteration userdb. I’m not critically dependent on the user iteration, so I’ve commented the userdb out for now, but this would need fixing. Regards, Christian Pfeiffer Hello everyone, Due to the fix for CVE-2025-30189, routines like userdb_ldap_preinit() call auth_cache_parse_key_and_fields() unconditionally, with the eventually called auth_cache_parse_key_exclude() erroring if a cache key could not be constructed. It's also noteworthy that this call happens regardless of whether use_cache is set or not, and as of such failing to construct a cache key would cause an error even if use_cache = no was set for that database. This is however an issue for user iteration with LDAP, as documented here [1]LDAP | Dovecot CE. Such a userdb only has iterate_filter fields that would inherently not be containing any user variables. The call to auth_cache_parse_key_and_fields() uses a combination of ldap_base and userdb_ldap_filter anyway (so whatever is in iterate_filter isn't considered), and for an iteration userdb as described in the documentation, the latter would be empty. Alas, I ended up getting the rather confusing error o auth: Fatal: auth-cache: dc=rev-crew,dc=info: Cache key must contain at least one variable With dc=rev-crew,dc=info being my ldap_base setting for the iteration userdb. I'm not critically dependent on the user iteration, so I've commented the userdb out for now, but this would need fixing. Regards, Christian Pfeiffer References Visible links 1. https://doc.dovecot.org/2.4.2/core/config/auth/databases/ldap.html#user-ite…

4 5

Search for missing To: header?
by Joseph Tam 20 Feb '26

20 Feb '26

Is there a proper way to torture doveadm search query to look for messages with a missing "To:" header? I played around with it and this seems to work: doveadm fetch -A text mailbox {box} NOT TO '' (Looking through a large spam corups: spam often exclude recipients in the headers as it gives the game away their personalized fraud was blasted to hundreds of addresses.) Joseph Tam <jtam.home(a)gmail.com>

1 0

More Dovecot 2.4 woes: LDAP cache bug and virtual autosubscribe
by sev monster 19 Feb '26

19 Feb '26

8 months ago I messaged this list communicating some of the issues I had with 2.4. Before I could even start testing 2.4 properly, 2 bugs had to be fixed—one that caused crashes on startup (https://gitlab.alpinelinux.org/alpine/aports/-/issues/17050) and one that caused passdb to use the same caching key for all connections and as such always have the same user log in. There was another bug, one that prevented me from using LDAP binds for passdb, but it had a workaround that mostly worked without side-eeffects. All of those have since been fixed, hurray! So in my infinite naïveté, I decided to give 2.4 another shake. And it, again, does not work. Surprise! I did manage to massage the configuration to allow me to at least run 2.4 without crashing and with users able to access (most of) their mailboxes, but there are still blockers to full functionality. I face the following issues: 1. Christian Pfeiffer back in November found a bug where auth caching with LDAP did not work, and due to how it's implemented, even turning caching off would still raise an error. I experienced the same issue for both userdb iteration and passdb bind logins. I had to comment out the userdb and use a static one instead (all my users, currently, use the same UID and easily composable path, so this wasn't a big deal) and start using a service account for LDAP binds. 2. Virtual mailbox autosubscribe does not work anymore. It throws an error about trying to create the virtual mailbox. This worked in 2.3. My virtual mailbox config: namespace virtual { type = private prefix = Search Folders. mail_driver = virtual mail_path = /etc/dovecot/virtual mail_index_path = ~/dovecot-virtual.cache mail_control_path = ~/dovecot-virtual.cache mail_volatile_path = ~/dovecot-virtual.cache hidden = yes list = children subscriptions = no mailbox All { auto = subscribe special_use = \All comment = All messages, excluding Junk and Trash } mailbox Unread { auto = subscribe special_use = \Important comment = All unread messages, excluding Junk and Trash } mailbox Flagged { auto = subscribe special_use = \Flagged comment = All flagged messages } } If there is something wrong with this config that might be responsible for my issue, please let me know. Otherwise, I believe this is a regression. I understand autosubscribe is documented to (and in other situations with non-virtual boxes) create mailboxes if missing, so if this is actually a fix to make the feature work as documented, we need a new option that allows for autosubscription without attempting to create the mailbox. Otherwise, my users will not know they even have these mailboxes—no one anymore knows or cares about mailbox (re: folder) subscription and won't know where to look to get them to show up in their client. With autosubscribe enabled, I can see the mailboxes in my mail client without explicitly subscribing, but attempting to open them will throw a server error. Removing the setting will make the mailbox disappear without going into settings and explicitly subscribing. Any ETA on the first bug being fixed, and any help with the second issue (bug or not) would be greatly appreciated. Best regards. P.S.: I wanted to spread this information that wasn't mentioned at all in the documentation. The shadow passdb was removed in the move to 2.4; why exactly is neither here nor there, though I will remark that I still don't know why it was done. I had believed at the time this necessitated enabling PAM for Dovecot, which it is not by default in my distro's package (Alpine), so if I wanted to continue allowing local users to log in, I would have to build Dovecot it myself and install PAM, neither of which I particularly wanted to do. I did play with passwd-file in the past, but there were issues with it that prevented me from using it—I don't remember what they were exactly, but I believe they have since been fixed, since in my testing now it does seem to work properly in the use-cases I tested. Anyway, while going over my config and getting ready to re-install PAM, I had a thought. /etc/shadow uses the same format for the first two fields as /etc/password, and Dovecot still (supposedly) allows for passwords to be used when reading /etc/password, so wouldn't it be possible to point the driver at the shadow file? Turns out, yes, it works! I am now able to authenticate local users from /etc/shadow again. Thanks to this, I no longer need to build with PAM support and don't need to install PAM on a PAM-less system. I hope this isn't considered a bug or something and support for this use-case is removed, because I really don't want to bother once again with adding PAM when I don't have to. :)

2 2

Fedora 43 and Dovecot version 2.4.2
by Bill Steinberg 19 Feb '26

19 Feb '26

Hello, I am running Fedora 43 on a server which is running a dovecot server, version 2.4.1-8. I am not running a cluster, there is only one dovecot server running on the Fedora 43 instance. Redhat has just updated the dovecot version on Fedora 43 to version 2.4.2-5. I would like to upgrade dovecot to version 2.4.2. I assume that the dovecot_config_version should be changed to 2.4.2. Should the dovecot_storage_version be changed to 2.4.2 as well? Are there any steps that should be taken to upgrade the dovecot storage to version 2.4.2? FYI the mail_driver on the dovecot server is mbox: mail_driver = mbox. Best regards, -Bill Hello, I am running Fedora 43 on a server which is running a dovecot server, version 2.4.1-8. I am not running a cluster, there is only one dovecot server running on the Fedora 43 instance. Redhat has just updated the dovecot version on Fedora 43 to version 2.4.2-5. I would like to upgrade dovecot to version 2.4.2. I assume that the dovecot_config_version should be changed to 2.4.2. Should the dovecot_storage_version be changed to 2.4.2 as well? Are there any steps that should be taken to upgrade the dovecot storage to version 2.4.2? FYI the mail_driver on the dovecot server is mbox: mail_driver = mbox. Best regards, -Bill

2 1

deliver fails because of a permission issue with SSL private key file
by Markus Schönhaber 19 Feb '26

19 Feb '26

Hi, I'm trying to make Postfix hand incoming mail to Dovecot by using Dovecot's deliver. But this fails with a permission error: > Feb 17 15:50:12 debian13-cont postfix/pipe[13133]: 171C17206: to=<recipient(a)dest.examle.org>, relay=dovecot, delay=0.17, delays=0.1/0/0/0.07, dsn=5.3.0, status=bounced (Command died with status 89: "/usr/lib/dovecot/deliver". Command output: doveconf: Fatal: Error in configuration file /etc/dovecot/certs.conf line 3: key_file: open(/etc/ssl/private/ssl-cert-snakeoil.key) failed: Permission denied ) How can I solve this (short of making the private key file world readable, of course)? Regards mks I have this in Postfix' master.cf: > dovecot unix - n n - - pipe > flags=DROhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -e -f ${sender} -a ${recipient} -d ${user}@${domain} # LANG=C id vmail uid=501(vmail) gid=501(vmail) groups=501(vmail),104(ssl-cert) # LANG=C ls -l /etc/ssl/private/ total 4 -rw-r----- 1 root ssl-cert 1704 Feb 4 17:15 ssl-cert-snakeoil.key # doveconf -n # 2.4.2-2+debian13 (0962ed2104): /etc/dovecot/dovecot.conf # Pigeonhole version 2.4.2-2+debian13 (767418c3) # OS: Linux 6.19.0-2-MANJARO x86_64 Debian 13.3 btrfs # Hostname: debian13-cont dovecot_config_version = 2.4.2 dovecot_storage_version = 2.4.2 log_debug = category=sql mail_driver = sdbox mail_gid = vmail mail_home = /var/spool/vmail/home/%{user | domain}/%{user | username} mail_path = /var/spool/vmail/mail/%{user | domain}/%{user | username} mail_plugins { quota = yes } mail_uid = vmail protocols = imap lmtp sieve sql_driver = mysql mysql localhost { dbname = postfixadmin password = # hidden, use -P to show it user = postfixadmin } passdb sql { query = SELECT 'vmail' AS userdb_uid, 'vmail' AS userdb_gid, CONCAT('/var/spool/vmail/home/', maildir) AS userdb_home, CONCAT(quota, 'B') AS userdb_quota_storage_size, username AS user, password FROM mailbox WHERE username = '%{user}' AND active = '1'; } userdb prefetch { } userdb sql { iterate_query = SELECT username AS user FROM mailbox WHERE active = '1'; query = SELECT 'vmail' AS uid, 'vmail' AS gid, CONCAT('/var/spool/vmail/home/', maildir) AS home, CONCAT(quota, 'B') AS quota_storage_size, username AS user, password FROM mailbox WHERE username = '%{user}' AND active = '1'; } namespace inbox { inbox = yes separator = / mailbox Drafts { special_use = "\\Drafts" } mailbox Entwürfe { special_use = "\\Drafts" } mailbox Junk { special_use = "\\Junk" } mailbox Trash { special_use = "\\Trash" } mailbox "Gelöschte Objekte" { special_use = "\\Trash" } mailbox Sent { special_use = "\\Sent" } mailbox "Gesendete Objekte" { special_use = "\\Sent" } } service auth { inet_listener tcp_auth { port = 12345 } unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0666 user = postfix } } service auth-worker { } ssl_server { cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem key_file = /etc/ssl/private/ssl-cert-snakeoil.key } protocol imap { mail_plugins { imap_quota = yes } } quota "User quota" { } dict_server { dict mysql { driver = sql sql_driver = mysql dict_map priv/quota/messages { sql_table = quota username_field = username dict_map_value_field messages { } } dict_map priv/quota/storage { sql_table = quota username_field = username dict_map_value_field bytes { } } } } quota_clone { dict proxy { name = mysql } }

6 14

dovecot 2.4 changes
by Curtis J Blank 18 Feb '26

18 Feb '26

I just did a Tumbleweed upgrade. then I had to fix dovecot. No warning that dovecot was going to break what so ever. Below is all the things I had to fix. And then I could not read my email in Thunderbird because you changed: mail_location = mbox:~/mail:INBOX=/var/spool/mail/%u to mail_driver = mbox mail_path = ~/mail mail_inbox_path = /var/spool/mail/%{user} and the "%u" to "%{user}" was the showstopper. What a crock of BS! I spent 3 hours determining the problem and then fixing dovecot because you decided to make major changes for no good reason. It worked just fine the way it was. You could have automated the changes by providing a utility that would make the changes the first time it started up after the upgrade. I had to try to start dovecot and when it failed to start look in the log and see the error and fix it. Over and over and over and over and over and over and over and... Like I said what a bunch of BS! Yes this is a rant. And maybe openSuSE's is too blame also. Jan 24 03:33:35 server dovecot[2223449]: doveconf: Fatal: Error in configuration file /etc/dovecot/dovecot.conf line 25: The first setting must be dovecot_config_version Jan 24 03:36:45 server dovecot[4626]: doveconf: Fatal: Error in configuration file /etc/dovecot/dovecot.conf line 25: The first setting must be dovecot_config_version Jan 24 03:46:10 server dovecot[21464]: doveconf: Fatal: Error in configuration file /etc/dovecot/dovecot.conf line 2: Invalid dovecot_config_version: Currently supported versions are: 2.4.0 2.4.1 2.4.2 Jan 24 03:48:45 server dovecot[22135]: doveconf: Fatal: Error in configuration file /etc/dovecot/dovecot.conf line 92: dict { } is missing section name Jan 24 03:51:47 server dovecot[28824]: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/auth-system.conf.ext line 10: passdb { } is missing section name Jan 24 03:53:22 server dovecot[29258]: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/auth-system.conf.ext line 10: passdb { } is missing section name Jan 24 03:55:26 server dovecot[29906]: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/auth-system.conf.ext line 49: userdb { } is missing section name Jan 24 03:56:57 server dovecot[30179]: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-director.conf line 40: inet_listener { } is missing section name Jan 24 03:58:37 server dovecot[30652]: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-logging.conf line 64: Unknown section name: plugin Jan 24 04:01:32 server dovecot[37805]: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-mail.conf line 31: mail_location: Unknown setting: mail_location Jan 24 04:05:30 server dovecot[38898]: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-mail.conf line 32: mail_location: Unknown setting: mail_location Jan 24 04:06:35 server dovecot[39158]: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-ssl.conf line 23: ssl_cert: Unknown setting: ssl_cert Jan 24 04:09:07 server dovecot[39707]: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-ssl.conf line 25: ssl_server_cert_file: open(/etc/dovecot/conf.d/-----BEGIN CERTIFICATE----- Jan 24 04:09:07 server dovecot[39707]: doveconf: Fatal: -----END CERTIFICATE----- Jan 24 04:09:07 server dovecot[39707]: doveconf: Fatal: ) failed: File name too long Jan 24 04:14:52 server dovecot[47156]: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-ssl.conf line 27: ssl_server_cert_file: open(/etc/dovecot/conf.d/-----BEGIN CERTIFICATE----- Jan 24 04:14:52 server dovecot[47156]: doveconf: Fatal: -----END CERTIFICATE----- Jan 24 04:14:52 server dovecot[47156]: doveconf: Fatal: ) failed: File name too long Jan 24 04:17:35 server dovecot[54187]: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-ssl.conf line 72: ssl_dh: Unknown setting: ssl_dh Jan 24 04:19:04 server dovecot[54532]: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-ssl.conf line 93: ssl_prefer_server_ciphers: Unknown setting: ssl_prefer_server_ciphers Jan 24 04:21:07 server dovecot[60961]: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/90-acl.conf line 11: Unknown section name: plugin Jan 24 04:22:40 server dovecot[61409]: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/90-acl.conf line 17: Unknown section name: plugin Jan 24 04:23:35 server dovecot[61624]: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/90-plugin.conf line 9: Unknown section name: plugin Jan 24 04:24:40 server dovecot[61932]: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/90-quota.conf line 17: Unknown section name: plugin Jan 24 04:25:38 server dovecot[62301]: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/90-quota.conf line 41: Unknown section name: plugin Jan 24 04:26:12 server dovecot[62335]: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/90-quota.conf line 69: Unknown section name: plugin Jan 24 04:26:42 server dovecot[62550]: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/90-quota.conf line 78: Unknown section name: plugin Jan 24 04:27:05 server dovecot[62582]: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/90-sieve-extprograms.conf line 9: Unknown section name: plugin Jan 24 04:28:11 server dovecot[62819]: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/90-sieve.conf line 24: Unknown section name: plugin Jan 24 04:29:02 server dovecot[63099]: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/90-sieve.conf line 39: sieve: Unknown setting: sieve Jan 24 04:36:01 server dovecot[71295]: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/90-sieve.conf line 39: sieve: Unknown setting: sieve Jan 24 04:39:04 server dovecot[72067]: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/90-sieve.conf line 40: sieve: Unknown setting: sieve (sieve_script_sieve or sieve_script_personal_sieve not found either.) Jan 24 04:47:39 server dovecot[86665]: doveconf: Fatal: Error in configuration file /etc/dovecot/dovecot.conf: ssl_options: unknown flag: 'no_compression' Jan 24 04:50:51 server dovecot[93375]: doveconf: Fatal: dovecot_storage_version setting must be set Jan 24 05:01:51 server dovecot[105836]: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-mail.conf line 31: mail_location: Unknown setting: mail_location Jan 24 05:06:18 cjbnew dovecot: imap(bob)<107288><SOtYQyBJTOXAqBTz>: Error: Mailbox INBOX: open(/var/spool/mail/%u) failed: Permission denied (euid=500(bob) egid=100(users) missing +w perm: /var/spool/mail, dir owned by 0:0 mode=0755) Jan 24 05:06:18 cjbnew dovecot: imap(bob)<107288><SOtYQyBJTOXAqBTz>: Error: Mailbox INBOX: Failed to autocreate mailbox: open(/var/spool/mail/%u) failed: Permission denied (euid=500(bob) egid=100(users) missing +w perm: /var/spool/mail, dir owned by 0:0 mode=0755) Jan 24 05:06:18 cjbnew dovecot: imap(bob)<107289><9+pYQyBJTeXAqBTz>: Error: Mailbox INBOX: open(/var/spool/mail/%u) failed: Permission denied (euid=500(bob) egid=100(users) missing +w perm: /var/spool/mail, dir owned by 0:0 mode=0755) Jan 24 05:06:18 cjbnew dovecot: imap(bob)<10Jan 24 05:06:18 cjbnew dovecot: imap(bob)<107288><SOtYQyBJTOXAqBTz>: Error: Mailbox INBOX: open(/var/spool/mail/%u) failed: Permission denied (euid=500(bob) egid=100(users) missing +w perm: /var/spool/mail, dir owned by 0:0 mode=0755) Jan 24 05:06:18 cjbnew dovecot: imap(bob)<107288><SOtYQyBJTOXAqBTz>: Error: Mailbox INBOX: Failed to autocreate mailbox: open(/var/spool/mail/%u) failed: Permission denied (euid=500(bob) egid=100(users) missing +w perm: /var/spool/mail, dir owned by 0:0 mode=0755) Jan 24 05:06:18 cjbnew dovecot: imap(bob)<107289><9+pYQyBJTeXAqBTz>: Error: Mailbox INBOX: open(/var/spool/mail/%u) failed: Permission denied (euid=500(bob) egid=100(users) missing +w perm: /var/spool/mail, dir owned by 0:0 mode=0755) Jan 24 05:06:18 cjbnew dovecot: imap(bob)<107289><9+pYQyBJTeXAqBTz>: Error: Mailbox INBOX: Failed to autocreate mailbox: open(/var/spool/mail/%u) failed: Permission denied (euid=500(bob) egid=100(users) missing +w perm: /var/spool/mail, dir owned by 0:0 mode=07557289><9+pYQyBJTeXAqBTz>: Error: Mailbox INBOX: Failed to autocreate mailbox: open(/var/spool/mail/%u) failed: Permission denied (euid=500(bob) egid=100(users) missing +w perm: /var/spool/mail, dir owned by 0:0 mode=0755) Jan 24 05:08:38 cjbnew dovecot: imap(bob)<107806><1/QbSyBJUOXAqBTz>: Error: Mailbox INBOX: open(/var/spool/mail/%u) failed: Permission denied (euid=500(bob) egid=100(users) missing +w perm: /var/spool/mail, dir owned by 0:0 mode=0755) Jan 24 05:08:38 cjbnew dovecot: imap(bob)<107806><1/QbSyBJUOXAqBTz>: Error: Mailbox INBOX: Failed to autocreate mailbox: open(/var/spool/mail/%u) failed: Permission denied (euid=500(bob) egid=100(users) missing +w perm: /var/spool/mail, dir owned by 0:0 mode=0755) Jan 24 05:11:10 cjbnew dovecot: imap(bob)<107806><1/QbSyBJUOXAqBTz>: Error: Mailbox INBOX: open(/var/spool/mail/%u) failed: Permission denied (euid=500(bob) egid=100(users) missing +w perm: /var/spool/mail, dir owned by 0:0 mode=0755) Jan 24 05:11:10 cjbnew dovecot: imap(bob)<107806><1/QbSyBJUOXAqBTz>: Error: Mailbox INBOX: Failed to autocreate mailbox: open(/var/spool/mail/%u) failed: Permission denied (euid=500(bob) egid=100(users) missing +w perm: /var/spool/mail, dir owned by 0:0 mode=0755) Jan 24 05:15:09 cjbnew dovecot: imap(bob)<107806><1/QbSyBJUOXAqBTz>: Error: Mailbox INBOX: open(/var/spool/mail/%u) failed: Permission denied (euid=500(bob) egid=100(users) missing +w perm: /var/spool/mail, dir owned by 0:473 mode=0755) Jan 24 05:15:09 cjbnew dovecot: imap(bob)<107806><1/QbSyBJUOXAqBTz>: Error: Mailbox INBOX: Failed to autocreate mailbox: open(/var/spool/mail/%u) failed: Permission denied (euid=500(bob) egid=100(users) missing +w perm: /var/spool/mail, dir owned by 0:473 mode=0755) Jan 24 05:18:35 cjbnew dovecot: imap(bob)<107806><1/QbSyBJUOXAqBTz>: Error: Mailbox INBOX: open(/var/spool/mail/%u) failed: Permission denied (euid=500(bob) egid=100(users) missing +w perm: /var/spool/mail, we're not in group 473(mail), dir owned by 0:473 mode=0775) Jan 24 05:18:35 cjbnew dovecot: imap(bob)<107806><1/QbSyBJUOXAqBTz>: Error: Mailbox INBOX: Failed to autocreate mailbox: open(/var/spool/mail/%u) failed: Permission denied (euid=500(bob) egid=100(users) missing +w perm: /var/spool/mail, we're not in group 473(mail), dir owned by 0:473 mode=0775) Jan 24 05:19:09 cjbnew dovecot: imap(bob)<122933></apLcSBJaKrAqBTq>: Disconnected: Connection closed (SELECT finished 0.138 secs ago) in=102 out=787 deleted=0 expunged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=0 body_bytes=0 Jan 24 05:19:58 cjbnew dovecot: imap(bob)<107806><1/QbSyBJUOXAqBTz>: Error: Mailbox INBOX: open(/var/spool/mail/%u) failed: Permission denied (euid=500(bob) egid=100(users) missing +w perm: /var/spool/mail, we're not in group 473(mail), dir owned by 0:473 mode=0775) Jan 24 05:19:58 cjbnew dovecot: imap(bob)<107806><1/QbSyBJUOXAqBTz>: Error: Mailbox INBOX: Failed to autocreate mailbox: open(/var/spool/mail/%u) failed: Permission denied (euid=500(bob) egid=100(users) missing +w perm: /var/spool/mail, we're not in group 473(mail), dir owned by 0:473 mode=0775) Jan 24 05:20:20 cjbnew dovecot: imap(bob)<107806><1/QbSyBJUOXAqBTz>: Error: Mailbox INBOX: open(/var/spool/mail/%u) failed: Permission denied (euid=500(bob) egid=100(users) missing +w perm: /var/spool/mail, we're not in group 473(mail), dir owned by 0:473 mode=0775) Jan 24 05:20:20 cjbnew dovecot: imap(bob)<107806><1/QbSyBJUOXAqBTz>: Error: Mailbox INBOX: Failed to autocreate mailbox: open(/var/spool/mail/%u) failed: Permission denied (euid=500(bob) egid=100(users) missing +w perm: /var/spool/mail, we're not in group 473(mail), dir owned by 0:473 mode=0775) Jan 24 05:21:17 cjbnew dovecot: imap(bob)<107806><1/QbSyBJUOXAqBTz>: Error: Mailbox INBOX: open(/var/spool/mail/%u) failed: Permission denied (euid=500(bob) egid=100(users) missing +w perm: /var/spool/mail, we're not in group 473(mail), dir owned by 0:473 mode=0775) Jan 24 05:21:17 cjbnew dovecot: imap(bob)<107806><1/QbSyBJUOXAqBTz>: Error: Mailbox INBOX: Failed to autocreate mailbox: open(/var/spool/mail/%u) failed: Permission denied (euid=500(bob) egid=100(users) missing +w perm: /var/spool/mail, we're not in group 473(mail), dir owned by 0:473 mode=0775)

12 19

"Synchronization corrupted index header" with mdbox: thousands of deleted e-mails reappeared in INBOX
by Ákos Szőts 17 Feb '26

17 Feb '26

Hi everyone, Suddenly, the following messages appeared in my Dovecot error log: master: Warning: Killed with signal 15 (by pid=0 uid=0 code=kill) Error: Mailbox Trash: Synchronization corrupted index header [...]/Trash/dbox-Mails/dovecot.index: uidvalidity=0, but next_uid=73 Warning: Mailbox Trash: fscking index file [...]/Trash/dbox-Mails/dovecot.index Warning: mdbox([...]/mail/storage): rebuilding indexes: Mailbox Trash index was fsck'd Warning: mdbox([...]/mail/storage): fscking index file [...]/index/inbox/storage/dovecot.map.index Error: Mailbox INBOX: [...]/INBOX/dbox-Mails/dovecot.index reset, view is now inconsistent The first message is because I restarted the container. Since then, Thunderbird shows thousands of previously deleted e-mails again in INBOX where all my messages are marked as unread. - Do you know what can cause it and how can I avoid to happen again? - Is the used mdbox storage engine that fragile? Is the fault tolerance of other engines better? I have a backup from some days ago. Is it possible to somehow revert back to it and sync the new e-mails on top of those? Version: 2.4.2. Thank you, Ákos

2 1

Most relevant documents for 2.4.x config file syntax
by Steve Litt 16 Feb '26

16 Feb '26

Hi all, Some time has gone by, so I'm hoping there's some good documentation for somebody needing syntax help on building a 2.4.x Dovecot. I've seen https://doc.dovecot.org/2.4.0/installation/upgrade/2.3-to-2.4.html , but it's not useful to me because I don't know *where* all those various pieces go. Which things go in what curly braces? It doesn't say. https://doc.dovecot.org/2.4.2/core/config/quick.html looks like an excellent starting place. Do you agree? What other *simple* documentation do you recommend? Because I am not and never was a Dovecot expert, I'll need something that does a considerable amount of teaching: A sort of Dovecot 4.2 For Dummies type thing. Thanks, SteveT Steve Litt http://444domains.com

3 4

Configuration upgrade tool
by Aki Tuomi 15 Feb '26

15 Feb '26

Hi! To make migrating from Dovecot 2.3 to 2.4 a bit easier, we are now providing a tool that helps upgrade your existing configuration. The tool allows you to upload either a full dovecot.conf or selected ancillary configuration files from a 2.3 setup, and will attempt to convert them accordingly. You can find the tool here: https://dovecot.org/upgrader/ We do not store any of the configurations processed by the tool, nor do we track who uses it. It's offered as-is, without any warranty or guarantee. If you run into any issues, unexpected results, or have feedback about the tool, please let us know — it’s very much appreciated. Please note that the tool can make mistakes, so we strongly recommend carefully reviewing and testing the output before using it in production. There are currently no plans to release this tool as open source. Regards, Aki Tuomi Open-Xchange oy

11 18