- dovecot - dovecot.org

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

24 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

4 5

dict: ldap deref
by Tomas Habarta 23 Sep '26

23 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 1

fts-flatcurve: optimize can never complete once a shard holds an unreadable document
by Ihor Rusyn 23 Sep '26

23 Sep '26

Hello, ## Summary `fts_flatcurve_xapian_optimize_rebuild()` aborts on the first document whose termlist is missing, which makes shard compaction impossible for the affected folder from that point on. The failure is silent — the operation reports success — so shards accumulate without bound. We have seen folders reach several thousand shards, with an index orders of magnitude larger than the messages it covers. Present in 2.4.4, 2.4.5 and current main (checked at 732917749a). ## Symptom doveadm fts optimize -u <user> Error: fts-flatcurve: Optimize failed: DocNotFoundError: No termlist for document 257091 # exit code 0, shard count unchanged In production this is logged by indexer-worker and repeats every 20-30 minutes, once per delivery, each run leaving another shard behind. Affected folders also keep an `optimize` directory containing an empty Xapian database. ## Mechanism 1. Long-lived, high-churn folders end up with shards holding disjoint UID ranges. `db->compact()` with `DBCOMPACT_NO_RENUMBER` throws `InvalidOperationError`, which the code expects and handles. 2. It falls back to `fts_flatcurve_xapian_optimize_rebuild()`, which walks the MSet and copies each document into a fresh database. 3. `iter.get_document()` sits **outside** the try block. When a document in the MSet has no termlist it throws `DocNotFoundError`, which the local handler never sees. 4. The exception propagates to `fts_flatcurve_xapian_optimize_box_do()`, is caught by `catch (Xapian::Error &e)`, sets `failed = TRUE` — and that path does `return 0`. The caller therefore sees success. Old shards are never deleted, the merge never happens, and every subsequent message adds another shard. The folder can never recover on its own. ## Reproduction Reproducible from scratch in about five minutes on a scratch mailbox, with generated messages only. Three conditions have to coincide; raising uidnext alone does not reproduce it. U=test(a)example.com # 1. push uidnext past 2^31 doveadm mailbox update -u $U --min-next-uid 2277107224 INBOX # 2. + 3. churn: grow, index into many shards, expunge half. # the expunged messages leave their documents behind in older shards. for round in $(seq 1 10); do n=$(doveadm -f flow mailbox status -u $U messages INBOX | tail -1 | sed 's/.*messages=//') [ "$n" -gt 400 ] && n=400 doveadm copy -u $U INBOX mailbox INBOX 1:$n doveadm -o fts_flatcurve_rotate_count=25 index -u $U INBOX doveadm expunge -u $U mailbox INBOX 1:$((n/2)) done doveadm fts optimize -u $U Rounds 1-9 compact cleanly to 2 shards. The tenth breaks: 1,838 live messages, 84 shards, uidnext 2277110749 — and optimize then fails as above and never merges again. ## Suggested fix Move `get_document()` inside the try, and skip an unreadable document instead of aborting the rebuild. A document whose termlist is gone belongs to a message that no longer exists, so there is nothing to carry into the optimized database; the rebuild exists precisely to salvage databases the native compact refused. Patch attached (`fts-flatcurve-optimize-rebuild.diff`). Other `Xapian::Error` types keep aborting the rebuild, so genuine corruption is still not silently swallowed. Separately, the `return 0` on `failed` in `fts_flatcurve_xapian_optimize_box_do()` looks questionable regardless of this fix: a failed optimize is reported to the caller as success, which is why this went unnoticed for so long. ## Notes Affected folders are long-lived and high-churn: most of the UIDs they have issued belong to messages that were deleted years ago. Folders that compact normally stay at 9-11 shards, so the ones in this state stand out immediately by shard count alone — which is also the cheapest way to find them: find <index root> -type d -path '*/fts-flatcurve/*' -prune -printf '%h\n' \ | sort | uniq -c | sort -rn -- Best regards, Ihor Rusyn Hello, ## Summary `fts_flatcurve_xapian_optimize_rebuild()` aborts on the first document whose termlist is missing, which makes shard compaction impossible for the affected folder from that point on. The failure is silent -- the operation reports success -- so shards accumulate without bound. We have seen folders reach several thousand shards, with an index orders of magnitude larger than the messages it covers. Present in 2.4.4, 2.4.5 and current main (checked at 732917749a). ## Symptom doveadm fts optimize -u <user> Error: fts-flatcurve: Optimize failed: DocNotFoundError: No termlist for document 257091 # exit code 0, shard count unchanged In production this is logged by indexer-worker and repeats every 20-30 minutes, once per delivery, each run leaving another shard behind. Affected folders also keep an `optimize` directory containing an empty Xapian database. ## Mechanism 1. Long-lived, high-churn folders end up with shards holding disjoint UID ranges. `db->compact()` with `DBCOMPACT_NO_RENUMBER` throws `InvalidOperationError`, which the code expects and handles. 2. It falls back to `fts_flatcurve_xapian_optimize_rebuild()`, which walks the MSet and copies each document into a fresh database. 3. `iter.get_document()` sits **outside** the try block. When a document in the MSet has no termlist it throws `DocNotFoundError`, which the local handler never sees. 4. The exception propagates to `fts_flatcurve_xapian_optimize_box_do()`, is caught by `catch (Xapian::Error &e)`, sets `failed = TRUE` -- and that path does `return 0`. The caller therefore sees success. Old shards are never deleted, the merge never happens, and every subsequent message adds another shard. The folder can never recover on its own. ## Reproduction Reproducible from scratch in about five minutes on a scratch mailbox, with generated messages only. Three conditions have to coincide; raising uidnext alone does not reproduce it. U=[1]test(a)example.com # 1. push uidnext past 2^31 doveadm mailbox update -u $U --min-next-uid 2277107224 INBOX # 2. + 3. churn: grow, index into many shards, expunge half. # the expunged messages leave their documents behind in older shards. for round in $(seq 1 10); do n=$(doveadm -f flow mailbox status -u $U messages INBOX | tail -1 | sed 's/.*messages=//') [ "$n" -gt 400 ] && n=400 doveadm copy -u $U INBOX mailbox INBOX 1:$n doveadm -o fts_flatcurve_rotate_count=25 index -u $U INBOX doveadm expunge -u $U mailbox INBOX 1:$((n/2)) done doveadm fts optimize -u $U Rounds 1-9 compact cleanly to 2 shards. The tenth breaks: 1,838 live messages, 84 shards, uidnext 2277110749 -- and optimize then fails as above and never merges again. ## Suggested fix Move `get_document()` inside the try, and skip an unreadable document instead of aborting the rebuild. A document whose termlist is gone belongs to a message that no longer exists, so there is nothing to carry into the optimized database; the rebuild exists precisely to salvage databases the native compact refused. Patch attached (`fts-flatcurve-optimize-rebuild.diff`). Other `Xapian::Error` types keep aborting the rebuild, so genuine corruption is still not silently swallowed. Separately, the `return 0` on `failed` in `fts_flatcurve_xapian_optimize_box_do()` looks questionable regardless of this fix: a failed optimize is reported to the caller as success, which is why this went unnoticed for so long. ## Notes Affected folders are long-lived and high-churn: most of the UIDs they have issued belong to messages that were deleted years ago. Folders that compact normally stay at 9-11 shards, so the ones in this state stand out immediately by shard count alone -- which is also the cheapest way to find them: find <index root> -type d -path '*/fts-flatcurve/*' -prune -printf '%h\n' \ | sort | uniq -c | sort -rn -- Best regards, Ihor Rusyn References Visible links 1. mailto:test@example.com

1 2

Upgraded to Dovecot 2.4 when I upgraded to Ubuntu 26.04. Now I can't get my existing emails.
by Ken Wright 23 Sep '26

23 Sep '26

I was afraid this would happen. I held off on upgrading to Dovecot 2.4 because of all the configuration changes, but I finally bit the bullet. I ran the conversion tool and it was okay as far as it went, but I'm still having problems. For the past three days I've been tweaking Dovecot's conf files, and I think I've finally got them to a working state, but my email client (Evolution) only shows me an empty inbox. No Drafts, no Junk, no Sent, and no Trash. Just an empty inbox. I'm sorry if I'm being redundant, but I'm quite frustrated. Here's the current output of doveconf -n: # 2.4.2 (0962ed2104): /etc/dovecot/dovecot.conf # Pigeonhole version 2.4.2 (767418c3) # OS: Linux 7.0.0-31-generic x86_64 Ubuntu 26.04.1 LTS # Hostname: localhost dovecot_config_version = 2.4.2 dovecot_storage_version = 2.4.2 fts_autoindex = yes fts_autoindex_max_recent_msgs = 999 fts_search_add_missing = yes listen = * mail_control_path = ~/ mail_driver = maildir mail_inbox_path = ~/ mail_index_path = ~/ mail_path = ~/ mail_privileged_group = mail mailbox_list_layout = maildir++ protocols { imap = yes lmtp = yes sieve = yes } sql_driver = mysql ssl = required mysql /var/run/mysqld/mysqld.sock { dbname = postfixadmin password = # hidden, use -P to show it user = postfix } passdb sql { default_password_scheme = ARGON2I driver = sql query = SELECT username AS user, password FROM mailbox WHERE username = '%{user | lower}' AND active = '1' mysql 127.0.0.1 { dbname = postfixadmin password = # hidden, use -P to show it user = postfix } } userdb sql { driver = sql iterate_query = SELECT username AS user FROM mailbox WHERE active = '1' query = SELECT CONCAT('/var/vmail/', maildir) AS home, 2000 AS uid, 2000 AS gid FROM mailbox WHERE username = '%{user | lower}' AND active = '1' mysql 127.0.0.1 { dbname = postfixadmin password = # hidden, use -P to show it user = postfix } } namespace inbox { inbox = yes prefix = separator = . type = private } service imap-login { inet_listener imap { port = 143 } inet_listener imaps { port = 993 ssl = yes } } service submission-login { inet_listener submission { } inet_listener submissions { } } service lmtp { unix_listener lmtp { mode = 0666 } unix_listener /var/spool/postfix/private/dovecot-lmtp { group = postfix mode = 0660 user = postfix } } service imap { vsz_limit = 1024M } service submission { } service auth { client_limit = 2048 unix_listener postfix-crypto-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 } } protocol lda { mail_plugins = $mail_plugins sieve } protocol lmtp { mail_plugins = sieve } service managesieve-login { inet_listener sieve { port = 4190 } inet_listener sieve_deprecated { port = 2000 } } service managesieve { } ssl_server { cert_file = /etc/letsencrypt/live/subdomain.mydomain.tld/fullchain.pem key_file = /etc/letsencrypt/live/subdomain.mydomain.tld/privkey.pem } Help! Ken

1 0

dovecot 2.4.5 imap process loop on folder deletion
by cesco 22 Sep '26

22 Sep '26

Hi imap process sometimes goes in infinite loop when deleting folders giving error: imap(user(a)mydomain.org)<996><EU1JPBZc3NisFAAC>: Couldn't create mailbox list lock /var/vmail_indexes/mydomain.org/user(a)mydomain.org/mailboxes.lock: file_create_locked(/var/vmail_indexes/mydomain.org/user@mydomain.org/mailbo… failed: fcntl(/var/vmail_indexes/mydomain.org/user@mydomain.org/mailboxes.lock, write-lock, F_SETLKW) locking failed: Timed out after 60 seconds (WRITE lock held by pid 316) dovecot is running inside a container based on debian 13 attached sysreport and gdb many thanks

2 1

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

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