- dovecot - dovecot.org

Bug report URL on website is broken
by H.-Dirk Schmitt 22 Oct '26

22 Oct '26

Hello! on the website https://doc.dovecot.org/main/troubleshooting/debug.html the link https://dovecot.org/bugreport-mail is leading to 404 page not found. Best Regards, H.-Dirk Schmitt Hello! on the website [1]https://doc.dovecot.org/main/troubleshooting/debug.html the link [2]https://dovecot.org/bugreport-mail is leading to 404 page not found. Best Regards, H.-Dirk Schmitt References Visible links 1. https://doc.dovecot.org/main/troubleshooting/debug.html 2. https://dovecot.org/bugreport-mail

2 1

Chaning from ldap pam to pam authentication
by fc26wuqa＠studserv.uni-leipzig.de 22 Oct '26

22 Oct '26

Hello, so far I used pam_ldap.so for authentication. nsss then imports all ldap users. My Ldap Server went down today, so I want to migrate to a system that uses users in /etc/passwd. I created a user something.something and I can log in with pam. But when I try to login via dovecot I get the error message: pam: unknown user. I think its probably because its trying to authenticate something@something@example.com which does not exist. How do i fix that? Thank you. Best, Lucienne

3 4

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

22 Oct '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 } }

7 15

Sievec is randomly (but often) failing in dovecot 2.4.5
by H.-Dirk Schmitt 22 Oct '26

22 Oct '26

``` Hello! I recently upgrade from dovecot 2.3 → 2.4 (2.4.5). Over 10 year I have a script running synchronising sieve scripts from a subversion backend to the dovecot installation. If I run the script in terminal it works. But as cron job (every hour) it is now complaining about a **sievec** error. ## error message ### sievec: Panic: file hash.c: line 256 (hash_table_insert_node): assertion failed: (opcode == HASH_TABLE_OP_UPDATE) sievec: Error: Raw backtrace: #1 [unw_get_proc_name() failed: -10] -> #2 default_fatal_handler[0x7fae27d50e70] -> #3 i_panic[0x7fae27c6e860] -> #4 [unw_get_proc_name() failed: -10] -> #5 ext_include_binary_script_include[0x7fae283acfa0] -> #6 ext_include_generate_include[0x7fae283ad0a0] -> #7 [unw_get_proc_name() failed: -10] -> #8 sieve_generate_block[0x7fae2837f7d0] -> #9 sieve_generator_run[0x7fae28381150] -> #10 sieve_compile_script[0x7fae2839e730] -> #11 sieve_compile[0x7fae2839e900] -> #12 sieve_tool_script_compile[0x55e263c89b60] -> #13 main[0x55e263c886c0] -> #14 [unw_get_proc_name() failed: -10] -> #15 __libc_start_main[0x7fae27a35ce0] -> #16 _start[0x55e263c889e0] 🛈 The full error message is at the end. ## context ### The error occurs in the following bash code: ``` bash # Compile the sieve files. for sieveFile in "${mailHome}"/sieve/*.sieve do if [[ -e ${sieveFile} ]] then if /usr/bin/sievec -D "${sieveFile}" &>"${catchOut}" then […] fi fi done ``` ## Observations ## 1. The error is not stable. The script run every hour but the errors are only ~2/3 of the runs. 2. The problem occurres only for one user with his personal `Default.sieve` file. (Bad luck that is myself.) 3. It can be reproduced locally. The following snippet is failing after 1…9 rounds – mostly 1 or 2 rounds. `ctr=1 ; while sievec -D Default.sieve ; do c42_sepLine "$((++ctr)) " ; done; echo ${ctr}?` 4. It doesn't seem to be related to any of the included files. I commented them out one for one. 5. If **only 1 include** is left the error is vanished. It doesn't depend on the include. ## Default.sieve ## ``` sieve require ["include"]; include :personal "_TrollReject"; include :personal "_alert"; include :personal "_tasks"; include :global "spam"; include :global "jobState"; include :global "ReceiptMessages"; include :personal "_c42-list"; include :personal "_mailinglist"; include :personal "_newsletter"; include :personal "_statusmail"; include :personal "_bugtracking"; include :personal "_werbung"; include :personal "_auction"; ``` 🛈 _… are personal, other are global scripts. ## Full output ## sievec: Debug: sieve: Pigeonhole version 2.4.5 (742bb892) initializing sievec: Debug: sieve: storage _file: file: Using Sieve script path: /srv/mail-c42/dirk/sieve/Default.sieve sievec: Debug: sieve: storage _file: file: script 'Default': Opened from '_file' sievec: Debug: sieve: storage _file: file: script 'Default': Opened script for reading sievec: Debug: sieve: storage personal: file: Storage path '/c42home/dirk/sieve' not found sievec: Debug: sieve: storage: file: Performing auto-detection sievec: Debug: sieve: storage: file: Use home (/c42home/dirk) sievec: Debug: sieve: storage: file: Checking storage path /c42home/dirk/sieve sievec: Debug: sieve: storage: file: Storage path '/c42home/dirk/sieve' not found sievec: Debug: sieve: storage: file: Checking storage path ~/.dovecot.sieve sievec: Debug: sieve: storage: file: Storage path '/c42home/dirk/.dovecot.sieve' not found sievec: Debug: sieve: storage: Autodetection failed sievec: Debug: sieve: storage: No matching Sieve storage configured (type=personal and cause=any) sievec: Debug: sieve: storage default: file: Using Sieve script path: /etc/c42CfgRepos/roles/mail_schiller/data/dovecot/default.sieve sievec: Debug: sieve: storage default (default): file: script '_TrollReject': Opened from 'default' sievec: Debug: sieve: storage default (default): file: script '_alert': Opened from 'default' sievec: Debug: sieve: storage default (default): file: script '_tasks': Opened from 'default' sievec: Debug: sieve: storage global: file: Using script storage path: /etc/c42CfgRepos/roles/mail_schiller/data/dovecot/sieve_global_dir sievec: Debug: sieve: storage global: file: script 'spam': Opened from 'global' sievec: Debug: sieve: storage global: file: Using script storage path: /etc/c42CfgRepos/roles/mail_schiller/data/dovecot/sieve_global_dir sievec: Debug: sieve: storage global: file: script 'jobState': Opened from 'global' sievec: Debug: sieve: storage global: file: Using script storage path: /etc/c42CfgRepos/roles/mail_schiller/data/dovecot/sieve_global_dir sievec: Debug: sieve: storage global: file: script 'ReceiptMessages': Opened from 'global' sievec: Debug: sieve: storage default (default): file: script '_c42-list': Opened from 'default' sievec: Debug: sieve: storage default (default): file: script '_mailinglist': Opened from 'default' sievec: Debug: sieve: storage default (default): file: script '_newsletter': Opened from 'default' sievec: Debug: sieve: storage default (default): file: script '_statusmail': Opened from 'default' sievec: Debug: sieve: storage default (default): file: script '_bugtracking': Opened from 'default' sievec: Debug: sieve: storage default (default): file: script '_werbung': Opened from 'default' sievec: Debug: sieve: storage default (default): file: script '_auction': Opened from 'default' sievec: Debug: sieve: storage default (default): file: script '_TrollReject': Opened script for reading sievec: Debug: sieve: storage global: file: Using script storage path: /etc/c42CfgRepos/roles/mail_schiller/data/dovecot/sieve_global_dir sievec: Debug: sieve: storage global: file: script 'spam': Opened from 'global' sievec: Debug: sieve: storage global: file: Using script storage path: /etc/c42CfgRepos/roles/mail_schiller/data/dovecot/sieve_global_dir sievec: Debug: sieve: storage global: file: script 'jobState': Opened from 'global' sievec: Debug: sieve: storage global: file: script 'spam': Opened script for reading sievec: Debug: sieve: storage global: file: script 'jobState': Opened script for reading sievec: Panic: file hash.c: line 256 (hash_table_insert_node): assertion failed: (opcode == HASH_TABLE_OP_UPDATE) sievec: Error: Raw backtrace: #1 [unw_get_proc_name() failed: -10] -> #2 default_fatal_handler[0x7f248d750e70] -> #3 i_panic[0x7f248d66e860] -> #4 [unw_get_proc_name() failed: -10] -> #5 ext_include_binary_script_include[0x7f248dc80fa0] -> #6 ext_include_generate_include[0x7f248dc810a0] -> #7 [unw_get_proc_name() failed: -10] -> #8 sieve_generate_block[0x7f248dc537d0] -> #9 sieve_generator_run[0x7f248dc55150] -> #10 sieve_compile_script[0x7f248dc72730] -> #11 sieve_compile[0x7f248dc72900] -> #12 sieve_tool_script_compile[0x55800baecb60] -> #13 main[0x55800baeb6c0] -> #14 [unw_get_proc_name() failed: -10] -> #15 __libc_start_main[0x7f248d435ce0] -> #16 _start[0x55800baeb9e0] ## ps ## Luckily dovecot is processing the compiled files, but the repeating error messages are annoying and the update of sieve files is not guaranteed. Best Regards, H.-Dirk Schmitt ``` Hello! I recently upgrade from dovecot 2.3 -> 2.4 (2.4.5). Over 10 year I have a script running synchronising sieve scripts from a subversion backend to the dovecot installation. If I run the script in terminal it works. But as cron job (every hour) it is now complaining about a **sievec** error. ## error message ### sievec: Panic: file hash.c: line 256 (hash_table_insert_node): assertion failed: (opcode == HASH_TABLE_OP_UPDATE) sievec: Error: Raw backtrace: #1 [unw_get_proc_name() failed: -10] -> #2 default_fatal_handler[0x7fae27d50e70] -> #3 i_panic[0x7fae27c6e860] -> #4 [unw_get_proc_name() failed: -10] -> #5 ext_include_binary_script_include[0x7fae283acfa0] -> #6 ext_include_generate_include[0x7fae283ad0a0] -> #7 [unw_get_proc_name() failed: -10] -> #8 sieve_generate_block[0x7fae2837f7d0] -> #9 sieve_generator_run[0x7fae28381150] -> #10 sieve_compile_script[0x7fae2839e730] -> #11 sieve_compile[0x7fae2839e900] -> #12 sieve_tool_script_compile[0x55e263c89b60] -> #13 main[0x55e263c886c0] -> #14 [unw_get_proc_name() failed: -10] -> #15 __libc_start_main[0x7fae27a35ce0] -> #16 _start[0x55e263c889e0] **** The full error message is at the end. ## context ### The error occurs in the following bash code: ``` bash # Compile the sieve files. for sieveFile in "${mailHome}"/sieve/*.sieve do if [[ -e ${sieveFile} ]] then if /usr/bin/sievec -D "${sieveFile}" &>"${catchOut}" then [...] fi fi done Observations 1. The error is not stable. The script run every hour but the errors are only ~2/3 of the runs. 2. The problem occurres only for one user with his personal Default.sieve file. (Bad luck that is myself.) 3. It can be reproduced locally. The following snippet is failing after 1...9 rounds - mostly 1 or 2 rounds. ctr=1 ; while sievec -D Default.sieve ; do c42_sepLine "$((++ctr)) " ; done; echo ${ctr}? 4. It doesn't seem to be related to any of the included files. I commented them out one for one. 5. If only 1 include is left the error is vanished. It doesn't depend on the include. Default.sieve require ["include"]; include :personal "_TrollReject"; include :personal "_alert"; include :personal "_tasks"; include :global "spam"; include :global "jobState"; include :global "ReceiptMessages"; include :personal "_c42-list"; include :personal "_mailinglist"; include :personal "_newsletter"; include :personal "_statusmail"; include :personal "_bugtracking"; include :personal "_werbung"; include :personal "_auction"; **** _... are personal, other are global scripts. Full output sievec: Debug: sieve: Pigeonhole version 2.4.5 (742bb892) initializing sievec: Debug: sieve: storage _file: file: Using Sieve script path: /srv/mail-c42/dirk/sieve/Default.sieve sievec: Debug: sieve: storage _file: file: script 'Default': Opened from '_file' sievec: Debug: sieve: storage _file: file: script 'Default': Opened script for reading sievec: Debug: sieve: storage personal: file: Storage path '/c42home/dirk/sieve' not found sievec: Debug: sieve: storage: file: Performing auto-detection sievec: Debug: sieve: storage: file: Use home (/c42home/dirk) sievec: Debug: sieve: storage: file: Checking storage path /c42home/dirk/sieve sievec: Debug: sieve: storage: file: Storage path '/c42home/dirk/sieve' not found sievec: Debug: sieve: storage: file: Checking storage path ~/.dovecot.sieve sievec: Debug: sieve: storage: file: Storage path '/c42home/dirk/.dovecot.sieve' not found sievec: Debug: sieve: storage: Autodetection failed sievec: Debug: sieve: storage: No matching Sieve storage configured (type=personal and cause=any) sievec: Debug: sieve: storage default: file: Using Sieve script path: /etc/c42CfgRepos/roles/mail_schiller/data/dovecot/default.sieve sievec: Debug: sieve: storage default (default): file: script '_TrollReject': Opened from 'default' sievec: Debug: sieve: storage default (default): file: script '_alert': Opened from 'default' sievec: Debug: sieve: storage default (default): file: script '_tasks': Opened from 'default' sievec: Debug: sieve: storage global: file: Using script storage path: /etc/c42CfgRepos/roles/mail_schiller/data/dovecot/sieve_global_dir sievec: Debug: sieve: storage global: file: script 'spam': Opened from 'global' sievec: Debug: sieve: storage global: file: Using script storage path: /etc/c42CfgRepos/roles/mail_schiller/data/dovecot/sieve_global_dir sievec: Debug: sieve: storage global: file: script 'jobState': Opened from 'global' sievec: Debug: sieve: storage global: file: Using script storage path: /etc/c42CfgRepos/roles/mail_schiller/data/dovecot/sieve_global_dir sievec: Debug: sieve: storage global: file: script 'ReceiptMessages': Opened from 'global' sievec: Debug: sieve: storage default (default): file: script '_c42-list': Opened from 'default' sievec: Debug: sieve: storage default (default): file: script '_mailinglist': Opened from 'default' sievec: Debug: sieve: storage default (default): file: script '_newsletter': Opened from 'default' sievec: Debug: sieve: storage default (default): file: script '_statusmail': Opened from 'default' sievec: Debug: sieve: storage default (default): file: script '_bugtracking': Opened from 'default' sievec: Debug: sieve: storage default (default): file: script '_werbung': Opened from 'default' sievec: Debug: sieve: storage default (default): file: script '_auction': Opened from 'default' sievec: Debug: sieve: storage default (default): file: script '_TrollReject': Opened script for reading sievec: Debug: sieve: storage global: file: Using script storage path: /etc/c42CfgRepos/roles/mail_schiller/data/dovecot/sieve_global_dir sievec: Debug: sieve: storage global: file: script 'spam': Opened from 'global' sievec: Debug: sieve: storage global: file: Using script storage path: /etc/c42CfgRepos/roles/mail_schiller/data/dovecot/sieve_global_dir sievec: Debug: sieve: storage global: file: script 'jobState': Opened from 'global' sievec: Debug: sieve: storage global: file: script 'spam': Opened script for reading sievec: Debug: sieve: storage global: file: script 'jobState': Opened script for reading sievec: Panic: file hash.c: line 256 (hash_table_insert_node): assertion failed: (opcode == HASH_TABLE_OP_UPDATE) sievec: Error: Raw backtrace: #1 [unw_get_proc_name() failed: -10] -> #2 default_fatal_handler[0x7f248d750e70] -> #3 i_panic[0x7f248d66e860] -> #4 [unw_get_proc_name() failed: -10] -> #5 ext_include_binary_script_include[0x7f248dc80fa0] -> #6 ext_include_generate_include[0x7f248dc810a0] -> #7 [unw_get_proc_name() failed: -10] -> #8 sieve_generate_block[0x7f248dc537d0] -> #9 sieve_generator_run[0x7f248dc55150] -> #10 sieve_compile_script[0x7f248dc72730] -> #11 sieve_compile[0x7f248dc72900] -> #12 sieve_tool_script_compile[0x55800baecb60] -> #13 main[0x55800baeb6c0] -> #14 [unw_get_proc_name() failed: -10] -> #15 __libc_start_main[0x7f248d435ce0] -> #16 _start[0x55800baeb9e0] ps Luckily dovecot is processing the compiled files, but the repeating error messages are annoying and the update of sieve files is not guaranteed. Best Regards, H.-Dirk Schmitt

1 0

LMTP: advertise DSN so MTAs send ORCPT (it is already honoured)
by Dhaval Patel 21 Oct '26

21 Oct '26

Hello, When moving from dovecot-lda (deliver -a ${original_recipient}) to LMTP, the original envelope recipient is lost, even though Dovecot's LMTP already supports it. Setup - Dovecot 2.4.1-4 (Debian 13, 1:2.4.1+dfsg1-6+deb13u7), Pigeonhole sieve. - Postfix delivering with virtual_transport = lmtp:unix:private/dovecot-lmtp. - Aliases such as postmaster(a)example.com are expanded by Postfix to a real mailbox (user(a)example.com) before delivery. What happens 1. Dovecot's LHLO reply advertises 8BITMIME, CHUNKING, ENHANCEDSTATUSCODES, PIPELINING, STARTTLS, but not DSN. 2. Postfix only sends the ORCPT parameter (RFC 3461) to servers that advertise DSN, so it sends RCPT TO:<user(a)example.com> with no ORCPT. 3. Sieve's envelope "to" therefore sees only the final address. A rule that worked under dovecot-lda with -a stops matching: if envelope :localpart :is "to" "postmaster" { ... } But ORCPT is honoured when sent. Talking to the LMTP socket by hand: LHLO test MAIL FROM:<user(a)example.com> RCPT TO:<user(a)example.com> ORCPT=rfc822;postmaster(a)example.com DATA ... The message is accepted, and the sieve rule above matches, so the original recipient reaches sieve. The same message without ORCPT does not match. Request. Could LMTP advertise DSN in its LHLO reply, either always or behind a setting? Since ORCPT is already parsed and used, this looks like a small change, and MTAs would then pass the original recipient. That would make LMTP equivalent to deliver -a for sieve envelope tests, and presumably for lmtp_hdr_delivery_address = original. If there's an existing way to get this that I've missed, I'd be glad to hear it. Thanks, Dhaval Patel

3 4

submission-relay: sends EHLO after a successful AUTH
by Simonas Kazlauskas 21 Oct '26

21 Oct '26

Hello, I have been migrating away from mailbox and notmuchto dovecot to archive my mail and it works great for this purpose so far! I figured out if I'm proxying IMAP, why not SMTP as well? Unfortunately that part did not work as well, at least not Migadu that I use as my mail service. I would always get back a > 530 5.7.0 authentication required. from the server when issuing `MAIL FROM` even though the logs were showing an apparent success in authenticating. From what I can tell the issue turns out to be the fact that submission relay sends a fresh EHLO after it has already successfully authenticated, resetting the state of the connection and dropping the authentication it just worked to set up. I verified the theory issuing commands directly to Migadu via `openssl s_client`: EHLO, AUTH PLAIN, EHLO, MAIL FROM -> 530 EHLO, AUTH PLAIN, MAIL FROM -> 250 Is it me holding dovecot wrong or a genuine bug? A sanitized log of one tx is appended below. Thank you, S. --- master: Dovecot v2.4.5 (0cbb641e3e) starting up for imap, submission ... submission(me(a)example.com)<3453761><tfS6...>: Debug: smtp-server: conn 192.168.70.182:50608 [1]: Server accepted connection (fd=9) submission(me(a)example.com)<3453761><tfS6...>: Debug: smtp-server: conn 192.168.70.182:50608 [1]: Connection created submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 [1]: Connection created submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 [1]: Disconnected submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 [1]: Looking up IP address submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 [1]: Performing asynchronous DNS lookup submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 [1]: conn unix:/run/dovecot2/dns-client: dns(smtp.migadu.com): Lookup started submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 [1]: conn unix:/run/dovecot2/dns-client: Connecting submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 [1]: conn unix:/run/dovecot2/dns-client (pid=3388288,uid=0): Client connected (fd=15) submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 [1]: conn unix:/run/dovecot2/dns-client (pid=3388288,uid=0): Sending version handshake submission(me(a)example.com)<3453761><tfS6...>: Debug: smtp-server: conn 192.168.70.182:50608 [1]: Connection started submission(me(a)example.com)<3453761><tfS6...>: Debug: smtp-server: conn 192.168.70.182:50608 [1]: Sent: 235 2.7.0 Logged in. submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 [1]: conn unix:/run/dovecot2/dns-client (pid=3388288,uid=0): dns(smtp.migadu.com): Lookup successful after 4 msecs submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 [1]: DNS lookup successful; got 6 IPs submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 [1]: Connecting to 51.210.223.36:465 submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: Connecting submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: Waiting for connect (fd=8) to finish for max 0 msecs submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: conn unix:/run/dovecot2/dns-client (pid=3388288,uid=0): Disconnected: Connection closed (fd=15) submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: conn unix:/run/dovecot2/dns-client (pid=3388288,uid=0): Disconnect: deinit submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: Client connected (fd=8) submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: Starting SSL handshake submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: smtp.migadu.com: SSL: where=0x10, ret=1: before SSL initialization submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: smtp.migadu.com: SSL: where=0x1001, ret=1: before SSL initialization submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: smtp.migadu.com: SSL: where=0x1001, ret=1: SSLv3/TLS write client hello submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: smtp.migadu.com: SSL: where=0x1002, ret=-1: SSLv3/TLS write client hello submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: smtp.migadu.com: SSL: where=0x1002, ret=-1: SSLv3/TLS write client hello submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: smtp.migadu.com: SSL: where=0x1002, ret=-1: SSLv3/TLS write client hello submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: smtp.migadu.com: SSL: where=0x1001, ret=1: SSLv3/TLS write client hello submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: smtp.migadu.com: SSL: where=0x1001, ret=1: SSLv3/TLS read server hello submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: smtp.migadu.com: SSL: where=0x1001, ret=1: TLSv1.3 read encrypted extensions submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: smtp.migadu.com: Received valid SSL certificate: /C=US/O=Internet Security Research Group/CN=ISRG Root X2 submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: smtp.migadu.com: Received valid SSL certificate: /C=US/O=ISRG/CN=Root YE submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: smtp.migadu.com: Received valid SSL certificate: /C=US/O=Let's Encrypt/CN=YE1 submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: smtp.migadu.com: Received valid SSL certificate: /CN=smtp.migadu.com submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: smtp.migadu.com: SSL: where=0x1001, ret=1: SSLv3/TLS read server certificate submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: smtp.migadu.com: SSL: where=0x1001, ret=1: TLSv1.3 read server certificate verify submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: smtp.migadu.com: SSL: where=0x1001, ret=1: SSLv3/TLS read finished submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: smtp.migadu.com: SSL: where=0x1001, ret=1: SSLv3/TLS write change cipher spec submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: smtp.migadu.com: SSL: where=0x1001, ret=1: SSLv3/TLS write finished submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: smtp.migadu.com: SSL: where=0x20, ret=1: SSL negotiation finished successfully submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: smtp.migadu.com: SSL: where=0x1002, ret=1: SSL negotiation finished successfully submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: SSL handshake successful submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: Received greeting from server: 220 smtp.migadu.com ESMTP Service Ready submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: Sending EHLO handshake submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: command EHLO: Submitted with priority submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: command EHLO: Sent: EHLO mail.example.com submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: command EHLO: Got reply (1/1): 250 smtp.migadu.com Hello mail.example.com PIPELINING 8BITMIME ENHANCEDSTATUSCODES CHUNKING AUTH PLAIN LOGIN AUTH=PLAIN LOGIN SIZE 52428800 (1 commands pending, 0 commands queued) submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: Received handshake reply submission(me(a)example.com)<3453761><tfS6...>: Warning: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: Received invalid EHLO response line: Unexpected character in EHLO keyword submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: Received server capabilities submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: Authenticating as me(a)example.com submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: command AUTH: Submitted with priority submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: command EHLO: Destroy (0 commands pending, 1 commands queued) submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: command AUTH: Sent: AUTH PLAIN <snip> submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: command AUTH: Got reply (1/1): 235 2.0.0 Authentication succeeded (1 commands pending, 0 commands queued) submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: Authenticated successfully submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: Sending EHLO handshake submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: command EHLO: Submitted with priority submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: command AUTH: Destroy (0 commands pending, 1 commands queued) submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: command EHLO: Sent: EHLO mail.example.com submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: command EHLO: Got reply (1/1): 250 smtp.migadu.com Hello mail.example.com PIPELINING 8BITMIME ENHANCEDSTATUSCODES CHUNKING AUTH PLAIN LOGIN AUTH=PLAIN LOGIN SIZE 52428800 (1 commands pending, 0 commands queued) submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: Received handshake reply submission(me(a)example.com)<3453761><tfS6...>: Warning: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: Received invalid EHLO response line: Unexpected character in EHLO keyword submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: Received server capabilities submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: Connection ready submission(me(a)example.com)<3453761><tfS6...>: Debug: smtp-server: conn 192.168.70.182:50608 [1]: Timeout start submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: command EHLO: Destroy (0 commands pending, 0 commands queued) submission(me(a)example.com)<3453761><tfS6...>: Debug: smtp-server: conn 192.168.70.182:50608 [1]: Received new command: MAIL FROM:<sender(a)example.com> submission(me(a)example.com)<3453761><tfS6...>: Debug: smtp-server: conn 192.168.70.182:50608 [1]: command MAIL: New command submission(me(a)example.com)<3453761><tfS6...>: Debug: smtp-server: conn 192.168.70.182:50608 [1]: command MAIL: Execute command submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: transaction: Created submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: transaction: Start submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: Add transaction submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: command [plug]: Submitted submission(me(a)example.com)<3453761><tfS6...>: Debug: smtp-server: conn 192.168.70.182:50608 [1]: command MAIL: Next to reply submission(me(a)example.com)<3453761><tfS6...>: Debug: smtp-server: conn 192.168.70.182:50608 [1]: Timeout stop submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: Start next transaction submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: transaction: Connection is ready for transaction submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: transaction: Sending MAIL command submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: command MAIL: Submitted submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: command [plug]: Aborted submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: command [plug]: Removed from send queue submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: command [plug]: Destroy (0 commands pending, 1 commands queued) submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: command MAIL: Sent: MAIL FROM:<sender(a)example.com> AUTH=relay(a)example.com submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: Start timeout submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: Reset timeout submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: command MAIL: Got reply (1/1): 530 5.7.0 authentication required (1 commands pending, 0 commands queued) submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: No commands pending; stop timeout submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: transaction: Got MAIL reply: 530 5.7.0 authentication required submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: transaction: Abort submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: Abort transaction submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: transaction: Aborted submission(me(a)example.com)<3453761><tfS6...>: Error: relay: Server requires authentication: 530 5.7.0 authentication required submission(me(a)example.com)<3453761><tfS6...>: Debug: smtp-server: conn 192.168.70.182:50608 [1]: Sent: 421 4.3.5 mail.example.com Internal error occurred. Refer to server log for more information. submission(me(a)example.com)<3453761><tfS6...>: Debug: smtp-server: conn 192.168.70.182:50608 [1]: Disconnected: Internal error occurred. Refer to server log for more information. (unfinished MAIL command) (state=MAIL FROM) submission(me(a)example.com)<3453761><tfS6...>: Debug: smtp-server: conn 192.168.70.182:50608 [1]: Connection state reset submission(me(a)example.com)<3453761><tfS6...>: Debug: smtp-server: conn 192.168.70.182:50608 [1]: command MAIL: Abort submission(me(a)example.com)<3453761><tfS6...>: Debug: smtp-server: conn 192.168.70.182:50608 [1]: command MAIL: Destroy submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: Disconnected submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: smtp.migadu.com: SSL alert: close notify submission(me(a)example.com)<3453761><tfS6...>: Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: Disconnected: Connection closed (fd=8) submission(me(a)example.com)<3453761><tfS6...>: Disconnected: Internal error occurred. Refer to server log for more information. (unfinished MAIL command) (state=MAIL FROM) in=36 out=124 submission(me(a)example.com)<3453761><tfS6...>: Debug: smtp-server: conn 192.168.70.182:50608 [1]: Disconnected: Connection closed (fd=9) submission(me(a)example.com)<3453761><tfS6...>: Debug: smtp-server: conn 192.168.70.182:50608 [1]: Connection destroy submission(3453761): Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: transaction: Destroy submission(3453761): Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: transaction: Abort submission(3453761): Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: Abort transaction submission(3453761): Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: command MAIL: Destroy (0 commands pending, 0 commands queued) submission(3453761): Debug: relay: smtp-client: conn smtp.migadu.com:465 (51.210.223.36:465) [1]: Destroy

1 0

Subfolders "trimmed" somehow
by Stefan G. Weichinger 21 Oct '26

21 Oct '26

At a customer we run dovecot-2.4.1 on Debian 13.7 There's a fat public folder for email archive, subscribed by all users. Via ACLs we only allow some admin users delete-rights there, at least that's how I understand: group @acl_ruleset acl_ruleset1 { acl user=intranet(a)my.tld { rights = lrwstipekxa } acl user=adm1(a)my.tld { rights = lrwstipekxa } acl user=adm2(a)my.tld { rights = lrwstipekxa } acl authenticated { rights = lrwstip } } group @acl_ruleset acl_default { acl group=people { rights = lri } acl anyone { rights = lrwstip } } namespace oeffentlich { mail_path = /home/vmail/oeffentlich mail_index_private_path = %{home}/.public mailbox Oeffentlich { @acl_ruleset = acl_ruleset1 } mailbox Oeffentlich/* { @acl_ruleset = acl_ruleset1 } @acl_ruleset = acl_ruleset1 } The ISSUE: they notice that in various subfolders there are mails deleted, as if folders were trimmed to "maximal 100 emails". And we don't know who or what does that. Without proper rights even clients like Thunderbird (which brings such a cleanup feature) couldn't do that. How could I monitor these deletions without too much logging overload? I look at https://doc.dovecot.org/main/core/plugins/mail_log.html Thanks for any pointers!

1 0

Dovecot 2.4 sieve
by Doug Hardie 20 Oct '26

20 Oct '26

I have dovecot 2.4 up and running and tried to add sieve. There were a lot of strange permission errors which I fixed. However all received mail is delivered to INBOX. I have a test message that should match line 12 of the sieve. if address :contains ["from","to","cc","bcc"] "skool.com" However, sieve-test show some unusual output. It does not give the values it is testing: 12: address test 12: starting ':contains' match with 'i;ascii-casemap' comparator: 12: extracting 'from' headers from message 12: extracting 'to' headers from message 12: extracting 'cc' headers from message 12: extracting 'bcc' headers from message 12: finishing match with result: not matched 12: jump if result is false 12: jumping to line 18 I seem to recall on 2.3 it provided both values for the test. I suspect something has changed in the formatting of the sieve file, but I have not been able to find anything on that. The sieve has been recompiled. I am also seeing many email delivered to my inbox with the contents: Date: Sun, 18 Oct 2026 22:00:00 -0700 (PDT) dsync(doug): Error: mkdir(/mailbkup/home_mail/doug/Maildir) failed: Permission denied (euid=2222(vmail) egid=2222(vmail) missing +w perm: /mailbkup/home_mail, dir owned by 0:0 mode=0755) dsync(doug): Error: mkdir(/mailbkup/home_mail/doug/Maildir) failed: Permission denied (euid=2222(vmail) egid=2222(vmail) missing +w perm: /mailbkup/home_mail, dir owned by 0:0 mode=0755) dsync(doug): Error: mkdir(/mailbkup/home_mail/doug/Maildir) failed: Permission denied (euid=2222(vmail) egid=2222(vmail) missing +w perm: /mailbkup/home_mail, dir owned by 0:0 mode=0755) dsync(doug): Error: brain S: Can't create mailbox Archive: Internal error occurred. Refer to server log for more information. [2026-10-18 22:00:00] dsync(jeanne): Error: mkdir(/mailbkup/home_mail/jeanne/Maildir) failed: Permission denied (euid=2222(vmail) egid=2222(vmail) missing +w perm: /mailbkup/home_mail, dir owned by 0:0 mode=0755) dsync(jeanne): Error: mkdir(/mailbkup/home_mail/jeanne/Maildir) failed: Permission denied (euid=2222(vmail) egid=2222(vmail) missing +w perm: /mailbkup/home_mail, dir owned by 0:0 mode=0755) dsync(jeanne): Error: mkdir(/mailbkup/home_mail/jeanne/Maildir) failed: Permission denied (euid=2222(vmail) egid=2222(vmail) missing +w perm: /mailbkup/home_mail, dir owned by 0:0 mode=0755) dsync(jeanne): Error: brain S: Can't create mailbox Bridge: Internal error occurred. Refer to server log for more information. [2026-10-18 22:00:00] dsync(beneke): Error: mkdir(/mailbkup/home_mail/beneke/Maildir) failed: Permission denied (euid=2222(vmail) egid=2222(vmail) missing +w perm: /mailbkup/home_mail, dir owned by 0:0 mode=0755) dsync(beneke): Error: mkdir(/mailbkup/home_mail/beneke/Maildir) failed: Permission denied (euid=2222(vmail) egid=2222(vmail) missing +w perm: /mailbkup/home_mail, dir owned by 0:0 mode=0755) dsync(beneke): Error: mkdir(/mailbkup/home_mail/beneke/Maildir) failed: Permission denied (euid=2222(vmail) egid=2222(vmail) missing +w perm: /mailbkup/home_mail, dir owned by 0:0 mode=0755) dsync(beneke): Error: brain S: Can't create mailbox Deleted Messages: Internal error occurred. Refer to server log for more information. [2026-10-18 22:00:01] I find that a bit confusing since mail is delivered successfully to my inbox. -- Doug

2 3

Mail on Mac in Sent Items foleder could be corrpted
by The Doctor 19 Oct '26

19 Oct '26

Anyone heard if this before? -- 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!

1 0

2.4 performance reduction on SORT
by Gioele Pannetto 19 Oct '26

19 Oct '26

Hi, I’m preparing the migration from an old Rocky 8 with Dovecot 2.3 to Rocky 9 with Dovecot 2.4.5. I’m using Apache Solr as the FTS driver for the messages and Maildir as storage. Everything works great on 2.3, but since I started experimenting on 2.4 I noticed a big performance reduction on FTS queries in IMAP, specifically on the virtual all mailbox. I’ve noticed that in Dovecot 2.4 the SORT command is taking 100x more than v2.3 to complete. Running the same command (SORT (REVERSE DATE) US-ASCII BODY "Hi") on a medium sized mailbox (about 8GB) on Dovecot 2.3 it completes in seconds and on Dovecot 2.4 it takes about 3-5 minutes. On both cases the query returns about 80k messages. To exclude Solr as a culprit, using a network sniff tool, I checked that when Dovecot queries Solr for the FTS, it responds within seconds (as the SEARCH command does) so most of the execution time is spent on actually sorting the messages. Is this a regression? Am I missing some cache optimization? For context, here is my Dovecot 2.3 config: # 2.3.21.1 (d492236fa0): /etc/dovecot/dovecot.conf # Pigeonhole version 0.5.21.1 (49005e73) # OS: Linux 4.18.0-553.137.1.el8_10.x86_64 x86_64 Rocky Linux release 8.10 (Green Obsidian) mail_attribute_dict = file:%h/Maildir/dovecot-attributes mail_fsync = always mail_location = maildir:~/Maildir:VOLATILEDIR=/dev/shm/dovecot/%2.256Nu/%u mail_plugins = quota quota_clone acl zlib fts fts_solr virtual notify mail_log maildir_very_dirty_syncs = yes mmap_disable = yes namespace Virtual { hidden = yes list = no location = virtual:/etc/dovecot/virtual:INDEX=~/Maildir/virtual prefix = Virtual/ separator = / subscriptions = no } namespace inbox { inbox = yes location = mailbox Archive { auto = subscribe special_use = \Archive } mailbox Drafts { auto = subscribe special_use = \Drafts } mailbox Sent { auto = subscribe special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } mailbox Spam { auto = subscribe special_use = \Junk } mailbox Trash { auto = subscribe special_use = \Trash } mailbox virtual/All { comment = All my messages special_use = \All } prefix = separator = / } plugin { acl = vfile acl_shared_dict = proxy::acl fts = solr fts_autoindex = no fts_autoindex_exclude = Drafts fts_autoindex_exclude2 = Spam fts_autoindex_exclude3 = Trash fts_autoindex_exclude4 = Sent fts_autoindex_max_recent_msgs = 500 fts_decoder = decode2text fts_header_excludes = Received Authentication-Results DKIM-* ARC-* X-* Feedback-* List-* fts_header_includes = From To Cc Bcc Subject Message-ID X-Identifier fts_index_timeout = 8s fts_solr = url=.../solr/dovecot/ zlib_save = gz zlib_save_level = 6 } service decode2text { executable = script /usr/libexec/dovecot/decode2text.sh unix_listener decode2text { mode = 0666 } user = dovecot } service imap { executable = imap imap-postlogin process_limit = 8000 vsz_limit = 2 G } Dovecot 2.4 config: # 2.4.5-2 (0cbb641e3e): /etc/dovecot/dovecot.conf # Pigeonhole version 2.4.5-2 (742bb892) # OS: Linux 5.14.0-687.36.1.el9_8.x86_64 x86_64 Rocky Linux release 9.8 (Blue Onyx) # 4 default setting changes since version 2.4.4 dovecot_config_version = 2.4.4 acl_dict_index = yes acl_driver = vfile dovecot_storage_version = 2.4.4 fts_header_excludes { Received = yes Authentication-Results = yes DKIM-* = yes ARC-* = yes X-* = yes Feedback-* = yes List-* = yes } fts_header_includes { From = yes To = yes Cc = yes Bcc = yes Subject = yes Message-ID = yes X-Identifier = yes } fts_search_timeout = 8s mail_compress_write_method = gz mail_driver = maildir mail_fsync = always mail_gid = 89 mail_path = ~/Maildir mail_plugins = acl mail_compress virtual fts fts_solr notify quota quota_clone mail_uid = 89 mail_volatile_path = /dev/shm/dovecot/%{user | md5 | substr(0, 8) % 256 | hex(2)}/%{user} mmap_disable = yes verbose_proctitle = yes mail_attribute { dict file { path = %{home}/Maildir/dovecot-attributes } } maildir { very_dirty_syncs = yes } namespace inbox { inbox = yes separator = / mailbox Drafts { auto = subscribe special_use = "\\Drafts" } mailbox Spam { auto = subscribe autoexpunge = 31 days special_use = "\\Junk" } mailbox Junk { auto = no } mailbox Trash { auto = subscribe autoexpunge = 31 days special_use = "\\Trash" quota_storage_extra = 100M } mailbox Sent { auto = subscribe special_use = "\\Sent" } mailbox Archive { auto = subscribe special_use = "\\Archive" } mailbox "Sent Messages" { special_use = "\\Sent" } } namespace Virtual { mail_cache_path = ~/Maildir/virtual mail_driver = virtual mail_index_path = ~/Maildir/virtual mail_path = /var/lib/dovecot/virtual hidden = yes list = no prefix = Virtual/ separator = / subscriptions = no mailbox All { comment = All my messages special_use = "\\All" } } protocol imap { mail_plugins { imap_acl = yes last_login = yes imap_quota = yes virtual = yes } } fts solr { soft_commit = yes } mailbox Drafts { fts_autoindex = no } mailbox Spam { fts_autoindex = no } mailbox Trash { fts_autoindex = no } mailbox Sent { fts_autoindex = no } language en { default = yes } language it { } Thanks -- Gioele Pannetto

1 0

acl_groups and ldap_multi
by Claus-Justus Heine 19 Oct '26

19 Oct '26

Hi there, I found this interesting %{ldap_multi:...} construct. So something like this should yield a usable acl-group config from LDAP: userdb { ... fields { acl_groups = %{ldap_multi:employeeType|list|default('people')} } } provided that employeeType in this example is (mis-)used to store group membership. If I think about the usual LDAP group, however, it is rather that an LDAP group-membership is recorded as, e.g., a memberOf attribute with a dn as value like memberOf=cn=groupname,ou=Groups,dc=example,dc=de. Are there further filter-constructs which could extract the first component of such a dn? If I understood correctly the ldap_multi "extractor" would yield cn=GROUP1,ou=Groups,...TABcn=GROUP2,ou=Groups,... and "list" converts tabs to a comma. But this would not yield the desired result here which would be the list GROUP1,GROUP2. I am aware of post-login hooks to accomplish acl-group collection. I was just curious if other possibilities are already builtin after I stumbled over ldap_multi. Thanks for any comments 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

1 0

Spurious error messages with multiple LDAP passdb's
by Claus-Justus Heine 19 Oct '26

19 Oct '26

Not so important, but it fills the logs. So first: it works :) I have such a setup: passdb ldap { ldap_base = ou=People,dc=example,dc=de bind = yes bind_userdn = uid=%{user|username|lower},ou=People,dc=example,dc=de filter = ... fields { user = %{ldap:uid} ... } } passdb ldap-roles { driver = ldap ldap_base = ou=Roles,dc=example,dc=de passdb_ldap_bind = yes filter = ... fields { user = %{ldap:uid} ... } } plus entries for the user-db. Now, what happens is that a user in my case lives either below People or Roles. Then Dovecot searches for the user which does not exist in one of the tow sections and then complains that the attributes (e.g. here uid) do not exist: 2026-10-19T08:47:22.846312+02:00 mail dovecot: auth(john@example.de,78.51.253.51,sasl:plain)<Pf/Y4itelu9OM/0z>: Error : ldap: auth_passdb_post settings: Failed to parse configuration: Failed to expand passdb_fields/user setting variables: lda p: No such attribute 'uid' This doesn't hurt to much as Dovecot tries all given passdb entries until it succeeds or fails. Is this perhaps a misconfiguration on my side? Of course, I could rewrite the stuff to use dc=example,dc=de as search base and adjust the filters such that the stuff still yields the correct users. That is: I could live with a single passdb. But it seemed somehow "natural" to generate two distinct passdb entries for real human beings and "roles". Best 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

macOS 15.7: IMAP TLS disconnect after login (SCM_RIGHTS fd lifetime)
by Ignacio Pozo 19 Oct '26

19 Oct '26

Hello Dovecot developers, I would like to report a reproducible IMAP disconnection after successful authentication when Dovecot runs on macOS. Our investigation points to the lifetime of a socketpair descriptor passed from the login process to the post-login process using SCM_RIGHTS. Environment: - macOS 15.7, build 24G222; Darwin 24.6.0; arm64. - Failure observed with Dovecot 2.4.3 and unpatched 2.4.4. - Currently running Dovecot 2.4.4 with the attached local workaround. - OpenSSL 3.6.2 in the 2.4.4 build. - The 2.4.4 build uses the poll I/O loop and kqueue filesystem notifications. - SQL/MySQL passdb and userdb, virtual users, sdbox storage. - Mail storage is on a locally attached APFS volume, not NFS. Observed behavior: 1. passdb/userdb resolves the expected user and home directory. 2. Plain IMAP on localhost can list folders and read messages. 3. With STARTTLS or implicit TLS, authentication succeeds, but the connection closes before subsequent IMAP commands can complete. 4. The failure was investigated using Apple Mail and Python IMAP probes against both STARTTLS on port 143 and IMAPS on port 993. Source review: On 2026-10-05 I inspected release 2.4.5 and main at commit d59e22f26bb975173755026baa48af88db1b44ef. In src/login-common/sasl-proxy.c, master_send_request() still calls login_client_request() and immediately closes the temporary descriptor when close_fd is true. The corresponding file was named sasl-server.c in 2.4.4. src/lib-login/login-client.c passes the descriptor through fd_send() without retaining a duplicate until the backend replies. client_get_plaintext_fd() in client-common.c creates the socketpair used for TLS proxying. I did not find an equivalent descriptor-lifetime workaround in this code path. I have reviewed the newer source, but have not built or runtime-tested 2.4.5 or main; the Dovecot reproduction and workaround validation were done with 2.4.4. Independent reproduction: The attached Python script reproduces the behavior without Dovecot, authentication, TLS, or mailbox access. It uses two separate processes, a UNIX control socket, a socketpair, and SCM_RIGHTS. A synchronization barrier controls when the receiver calls recvmsg(). On this Mac: - Closing the sender's copy of the passed socketpair endpoint before the receiver calls recvmsg() makes the received endpoint return b'' (EOF); the other endpoint then encounters BrokenPipeError. - Keeping that descriptor open until the receiver acknowledges receipt allows a complete PING/PONG exchange. Run it with: python3 reproduce-macos-scm-rights.py Local workaround: The attached patch against 2.4.4 stores the temporary descriptor in the client, closes it in login_callback() after the backend response, and also closes it during client cleanup for aborted sessions. With this change, IMAP LIST, SELECT, QRESYNC, and full message FETCH succeed over both STARTTLS and IMAPS. An authenticated SMTP -> LMTP -> storage -> IMAP TLS test also succeeds, and existing mailbox access continues to work. I am reporting the observed macOS behavior and a working local workaround, rather than claiming to have established the underlying kernel cause or an upstream-ready fix. Is this already a known issue? Would retaining the descriptor until the backend response be an appropriate portability fix? If not, which approach would you recommend? I would also appreciate guidance on a suitable regression test and whether you would like a pull request adapted to main. Attachments: - dovecot-macos-tls-handoff.patch - reproduce-macos-scm-rights.py - dovecot-n-anonymized.txt (current patched 2.4.4 configuration; credentials and identifying details redacted) Thank you. Hello Dovecot developers, I would like to report a reproducible IMAP disconnection after successful authentication when Dovecot runs on macOS. Our investigation points to the lifetime of a socketpair descriptor passed from the login process to the post-login process using SCM_RIGHTS. Environment: - macOS 15.7, build 24G222; Darwin 24.6.0; arm64. - Failure observed with Dovecot 2.4.3 and unpatched 2.4.4. - Currently running Dovecot 2.4.4 with the attached local workaround. - OpenSSL 3.6.2 in the 2.4.4 build. - The 2.4.4 build uses the poll I/O loop and kqueue filesystem notifications. - SQL/MySQL passdb and userdb, virtual users, sdbox storage. - Mail storage is on a locally attached APFS volume, not NFS. Observed behavior: 1. passdb/userdb resolves the expected user and home directory. 2. Plain IMAP on localhost can list folders and read messages. 3. With STARTTLS or implicit TLS, authentication succeeds, but the connection closes before subsequent IMAP commands can complete. 4. The failure was investigated using Apple Mail and Python IMAP probes against both STARTTLS on port 143 and IMAPS on port 993. Source review: On 2026-10-05 I inspected release 2.4.5 and main at commit d59e22f26bb975173755026baa48af88db1b44ef. In src/login-common/sasl-proxy.c, master_send_request() still calls login_client_request() and immediately closes the temporary descriptor when close_fd is true. The corresponding file was named sasl-server.c in 2.4.4. src/lib-login/login-client.c passes the descriptor through fd_send() without retaining a duplicate until the backend replies. client_get_plaintext_fd() in client-common.c creates the socketpair used for TLS proxying. I did not find an equivalent descriptor-lifetime workaround in this code path. I have reviewed the newer source, but have not built or runtime-tested 2.4.5 or main; the Dovecot reproduction and workaround validation were done with 2.4.4. Independent reproduction: The attached Python script reproduces the behavior without Dovecot, authentication, TLS, or mailbox access. It uses two separate processes, a UNIX control socket, a socketpair, and SCM_RIGHTS. A synchronization barrier controls when the receiver calls recvmsg(). On this Mac: - Closing the sender's copy of the passed socketpair endpoint before the receiver calls recvmsg() makes the received endpoint return b'' (EOF); the other endpoint then encounters BrokenPipeError. - Keeping that descriptor open until the receiver acknowledges receipt allows a complete PING/PONG exchange. Run it with: python3 reproduce-macos-scm-rights.py Local workaround: The attached patch against 2.4.4 stores the temporary descriptor in the client, closes it in login_callback() after the backend response, and also closes it during client cleanup for aborted sessions. With this change, IMAP LIST, SELECT, QRESYNC, and full message FETCH succeed over both STARTTLS and IMAPS. An authenticated SMTP -> LMTP -> storage -> IMAP TLS test also succeeds, and existing mailbox access continues to work. I am reporting the observed macOS behavior and a working local workaround, rather than claiming to have established the underlying kernel cause or an upstream-ready fix. Is this already a known issue? Would retaining the descriptor until the backend response be an appropriate portability fix? If not, which approach would you recommend? I would also appreciate guidance on a suitable regression test and whether you would like a pull request adapted to main. Attachments: - dovecot-macos-tls-handoff.patch - reproduce-macos-scm-rights.py - dovecot-n-anonymized.txt (current patched 2.4.4 configuration; credentials and identifying details redacted) Thank you.

3 2

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

19 Oct '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 6

Dovecot 2.4 and E-Mail Address as Login Setting
by Daniel Reinhardt 19 Oct '26

19 Oct '26

All, I am running Dovecot 2.4 on a single server, and I am wondering where I can set it to use the full email address as the login name. I am running Ubuntu 26.04 and its fully updated. I own the server, and the domain. Let me know what information you need to assist me. Very Respectfully, Daniel Reinhardt Sent with [Proton Mail](https://proton.me/mail/home) secure email. All, I am running Dovecot 2.4 on a single server, and I am wondering where I can set it to use the full email address as the login name. I am running Ubuntu 26.04 and its fully updated. I own the server, and the domain. Let me know what information you need to assist me. Very Respectfully, Daniel Reinhardt Sent with [1]Proton Mail secure email. References Visible links 1. https://proton.me/mail/home

6 14

Support for CentOS Stream
by xspielinbox＠protonmail.com 18 Oct '26

18 Oct '26

Dear Dovecot Team, https://dovecot.org/download does not list install instructions or packages for CentOS Stream. I would highly appreaciate it, if you could provide packages for CentOS Stream as well. This would allow for easy use of CentOS Stream allowing people to use a platform with a stability similar to Red Hat Enterprise Linux (RHEL) while being a bit more up to date and without the cost. It also allows for easy testing of changes before they are shipped in RHEL. Thanks and kind regards

2 2

Auth panic after SIGHUP: sasl_server_instance_unref() assertion failed on Dovecot 2.4.5
by Liubov Pashkova 16 Oct '26

16 Oct '26

Hello Dovecot Team, I would like to report an authentication-process crash in Dovecot 2.4.5. Environment * Dovecot version: 2.4.5 * Package: 2:2.4.5+dfsg1-2onehop1 (please confirm against the installed package) - our internal custom build * Operating system: Ubuntu 24.04 LTS (Noble) * Service: Dovecot submission authentication * Authentication backend: custom Lua authentication and target lookup over HTTP * Core dump: unavailable for this incident Observed error On October 15, 2026, the following sequence appeared in the logs. First, Dovecot reloaded its configuration: Oct 15 00:29:12 Warning: master: SIGHUP received - reloading configuration During authentication activity, the Lua backend then failed to resolve a target following an HTTP 404 response: Error: lua: db-lua: Failed to resolve target Shortly afterwards, the authentication process aborted with this assertion: Panic: file sasl-server.c: line 67 (sasl_server_instance_unref): assertion failed: (sinst->requests == 0) The master subsequently reported: Error: master: service(auth): service(auth): child 4046828 killed with signal 6 (core not dumped - https://dovecot.org/bugreport.html#coredumps) The backtrace included the following functions: sasl_server_instance_unref auth_sasl_instance_deinit auths_init auths_free auths_free main The log: ---------- Oct 15 00:29:41 dovecot[4050341]: auth-worker(<masked>,<masked>)<4050417><SpTTH9ZdIf7GhzdJ>: request [9]: Error: lua: db-lua: Failed to resolve target Oct 15 00:29:42 dovecot[4046755]: submission-login: Login aborted: Server shutting down (unfinished AUTH command) (auth failed, 27 attempts in 83 secs) (auth_failed): user=<masked>, method=LOGIN, rip=<masked>, rp=65057, lip=<masked>, Oct 15 00:29:42 dovecot[4046755]: auth: [lua-auth] [init] script stopped Oct 15 00:29:42 dovecot[4046755]: auth: [lua-auth] [init] script stopped Oct 15 00:29:42 dovecot[4050341]: auth-worker: [lua-auth] [init] script stopped Oct 15 00:29:42 dovecot[4046755]: auth: [lua-auth] [init] script stopped Oct 15 00:29:42 dovecot[4050341]: auth-worker: [lua-auth] [init] script stopped Oct 15 00:29:42 dovecot[4046755]: auth: [lua-auth] [init] script stopped Oct 15 00:29:42 dovecot[4050341]: auth-worker: [lua-auth] [init] script stopped Oct 15 00:29:42 dovecot[4050341]: auth-worker: [lua-auth] [init] script stopped Oct 15 00:29:42 dovecot[4046755]: auth: Panic: file sasl-server.c: line 67 (sasl_server_instance_unref): assertion failed: (sinst->requests == 0) Oct 15 00:29:42 dovecot[4046755]: auth: Error: Raw backtrace: #0 buffer_append[0x70a03bd47c67] -> #1 backtrace_append[0x70a03bd4804b] -> #2 backtrace_get[0x70a03bd48098] -> #3 i_set_failure_send_prefix[0x70a03bd52fb2] -> #4 i_syslog_error_handler[0x70a03bd540d5] -> #5 i_syslog_fatal_handler[0x70a03bd54152] -> #6 i_panic[0x70a03bd53058] -> #7 sasl_server_instance_unref[0x70a03bd14b76] -> #8 auth_sasl_instance_deinit[0x62869f9d22fa] -> #9 auths_init[0x62869f9c562e] -> #10 auths_free[0x62869f9c5691] -> #11 auths_free[0x62869f9c570e] -> #12 main[0x62869f9c5b54] -> #13 __libc_init_first[0x70a03b82a150] -> #14 __libc_start_main[0x70a03b82a200] -> #15 _start[0x62869f9c0370] Oct 15 00:29:42 dovecot[3842726]: master: Error: service(auth): service(auth): child 4046828 killed with signal 6 (core not dumped - https://dovecot.org/bugreport.html#coredumps - set /proc/sys/fs/suid_dumpable to 2) ---------- (IPs, emails and hostnames are masked or removed) The error was triggered when some abusers tried to abuse submission-login at our public endpoint. Context and questions The assertion occurred approximately 30 seconds after the configuration reload, while authentication attempts were being processed. The logs also show repeated Lua target-lookup failures. I have not established whether the crash requires a configuration reload, outstanding authentication requests, Lua lookup errors, or a combination of these conditions. Could you help determine: 1. Whether this assertion is a known issue in Dovecot 2.4.x. 2. Whether there are relevant fixes in a later release. 3. What additional diagnostics would be useful to identify the cause? I will provide the sanitized configuration, package details, and relevant logs. I can investigate reproduction conditions if needed. Thank you. Regards Liubov Pashkova Systems Engineer, Group.One Kind regards, Liubov Pashkova Systems Engineer [group.one] group.one Carlsgatan 3 | 211 20 Malmö | Sweden group.one<https://www.group.one> | LinkedIn<https://www.linkedin.com/company/group-dot-one/> Hello Dovecot Team, I would like to report an authentication-process crash in Dovecot 2.4.5. Environment o Dovecot version: 2.4.5 o Package: 2:2.4.5+dfsg1-2onehop1 (please confirm against the installed package) - our internal custom build o Operating system: Ubuntu 24.04 LTS (Noble) o Service: Dovecot submission authentication o Authentication backend: custom Lua authentication and target lookup over HTTP o Core dump: unavailable for this incident Observed error On October 15, 2026, the following sequence appeared in the logs. First, Dovecot reloaded its configuration: Oct 15 00:29:12 Warning: master: SIGHUP received - reloading configuration During authentication activity, the Lua backend then failed to resolve a target following an HTTP 404 response: Error: lua: db-lua: Failed to resolve target Shortly afterwards, the authentication process aborted with this assertion: Panic: file sasl-server.c: line 67 (sasl_server_instance_unref): assertion failed: (sinst->requests == 0) The master subsequently reported: Error: master: service(auth): service(auth): child 4046828 killed with signal 6 (core not dumped - https://dovecot.org/bugreport.html#coredumps) The backtrace included the following functions: sasl_server_instance_unref auth_sasl_instance_deinit auths_init auths_free auths_free main The log: ---------- Oct 15 00:29:41 dovecot[4050341]: auth-worker(<masked>,<masked>)<4050417><SpTTH9ZdIf7GhzdJ>: request [9]: Error: lua: db-lua: Failed to resolve target Oct 15 00:29:42 dovecot[4046755]: submission-login: Login aborted: Server shutting down (unfinished AUTH command) (auth failed, 27 attempts in 83 secs) (auth_failed): user=<masked>, method=LOGIN, rip=<masked>, rp=65057, lip=<masked>, Oct 15 00:29:42 dovecot[4046755]: auth: [lua-auth] [init] script stopped Oct 15 00:29:42 dovecot[4046755]: auth: [lua-auth] [init] script stopped Oct 15 00:29:42 dovecot[4050341]: auth-worker: [lua-auth] [init] script stopped Oct 15 00:29:42 dovecot[4046755]: auth: [lua-auth] [init] script stopped Oct 15 00:29:42 dovecot[4050341]: auth-worker: [lua-auth] [init] script stopped Oct 15 00:29:42 dovecot[4046755]: auth: [lua-auth] [init] script stopped Oct 15 00:29:42 dovecot[4050341]: auth-worker: [lua-auth] [init] script stopped Oct 15 00:29:42 dovecot[4050341]: auth-worker: [lua-auth] [init] script stopped Oct 15 00:29:42 dovecot[4046755]: auth: Panic: file sasl-server.c: line 67 (sasl_server_instance_unref): assertion failed: (sinst->requests == 0) Oct 15 00:29:42 dovecot[4046755]: auth: Error: Raw backtrace: #0 buffer_append[0x70a03bd47c67] -> #1 backtrace_append[0x70a03bd4804b] -> #2 backtrace_get[0x70a03bd48098] -> #3 i_set_failure_send_prefix[0x70a03bd52fb2] -> #4 i_syslog_error_handler[0x70a03bd540d5] -> #5 i_syslog_fatal_handler[0x70a03bd54152] -> #6 i_panic[0x70a03bd53058] -> #7 sasl_server_instance_unref[0x70a03bd14b76] -> #8 auth_sasl_instance_deinit[0x62869f9d22fa] -> #9 auths_init[0x62869f9c562e] -> #10 auths_free[0x62869f9c5691] -> #11 auths_free[0x62869f9c570e] -> #12 main[0x62869f9c5b54] -> #13 __libc_init_first[0x70a03b82a150] -> #14 __libc_start_main[0x70a03b82a200] -> #15 _start[0x62869f9c0370] Oct 15 00:29:42 dovecot[3842726]: master: Error: service(auth): service(auth): child 4046828 killed with signal 6 (core not dumped - https://dovecot.org/bugreport.html#coredumps - set /proc/sys/fs/suid_dumpable to 2) ---------- (IPs, emails and hostnames are masked or removed) The error was triggered when some abusers tried to abuse submission-login at our public endpoint. Context and questions The assertion occurred approximately 30 seconds after the configuration reload, while authentication attempts were being processed. The logs also show repeated Lua target-lookup failures. I have not established whether the crash requires a configuration reload, outstanding authentication requests, Lua lookup errors, or a combination of these conditions. Could you help determine: 1. Whether this assertion is a known issue in Dovecot 2.4.x. 2. Whether there are relevant fixes in a later release. 3. What additional diagnostics would be useful to identify the cause? I will provide the sanitized configuration, package details, and relevant logs. I can investigate reproduction conditions if needed. Thank you. Regards Liubov Pashkova Systems Engineer, Group.One Kind regards, Liubov Pashkova Systems Engineer [1]group.one group.one Carlsgatan 3 | 211 20 MalmAP | Sweden [2]group.one | [3]LinkedIn References Visible links 2. https://www.group.one/ 3. https://www.linkedin.com/company/group-dot-one/

1 1

[ANNOUNCE] dovecot_spam_report - non-blocking spam/ham learning (IMAPSieve + sa-learn)
by Ján Máté 15 Oct '26

15 Oct '26

Hi all, I would like to announce dovecot_spam_report, a small GPL tool that decouples spam/ham reporting via IMAPSieve from sa-learn, so Dovecot no longer blocks while messages are being learned. Download: https://inf-it.com/dovecot_spam_report.tgz The problem ----------- The usual setup ("Replacing antispam plugin with IMAPSieve", https://doc.dovecot.org/latest/core/config/spam_reporting.html) pipes every message moved into or out of Junk directly to sa-learn, and the IMAP process waits for sa-learn to finish for each message. The HOWTO itself warns that this can lock the user out for tens of seconds or minutes; with bulk moves of thousands of messages it gets much worse. JM

2 1

Re: Dovecot 2.4.5 on macOS 27 ARM64: post-authentication IMAP connection closes
by Daniel J. Luke 13 Oct '26

13 Oct '26

I was able to replicate this (or something very similar) on MacOS 15/intel. In my case, if I connect over imap things work, but over imaps the imap process dies with signal 6 (built against openssl 3.6.5). I spent a little time in lldb but wasn't able to isolate what was happening. I didn't see any interesting logs from dovecot (just looked like client disconnected after sending 0 commands). -- Daniel J. Luke

5 4

Configuring for System and Virtual Users
by Mark Olbert 10 Oct '26

10 Oct '26

Hi! I am trying to configure postfix and dovecot 2.4.1 under Debian Trixie to handle both system and virtual users. Some of my virtual users have the same username part as system users (e.g., system account 'mark' and virtual user 'mark(a)jumpforjoysoftware.com'). I've been struggling with getting help from Claude Code and Gemini Pro for several days now, and still can't get everything working. From watching the logs, the problem appears to stem from the username part not being extracted from the FQ user before mail is handled off to lmtp for final delivery. Here are what I believe are the relevant sections of my dovecot.conf: # overall default, need to handle system accounts as exceptions auth_username_format = %{user | lower} # virtual users specified first so search will end when they are found passdb passwd-file { passwd_file_path = /etc/dovecot/passwd } userdb passwd-file { passwd_file_path = /etc/dovecot/passwd userdb_fields { uid = 5000 gid = 5000 home = /var/mail/vhosts/%{user | domain | lower }/%{user | username | lower } mail_driver = maildir mail_path = ~/Maildir } } # system users passdb pam { # apparently, this next line gets ignored auth_username_format = %{user | username | lower} service_name = dovecot } userdb passwd { # or maybe this line does auth_username_format = %{user | username | lower} userdb_fields { home = /home/%{user} mail_driver = maildir mail_path = ~/Maildir } } protocol lmtp { auth_username_format = %{user | username | lower} } service lmtp { unix_listener /var/spool/postfix/private/dovecot-lmtp { mode = 0660 user = postfix group = postfix } } # not sure this is part of the problem, but... service auth { unix_listener /var/spool/postfix/private/auth { mode = 0660 user = postfix group = postfix } } I believe the relevant sections of my postfix main.cf file are: myhostname = mail.theboilingfrog.net mydomain = theboilingfrog.net myorigin = $mydomain mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain mailbox_transport = lmtp:unix:private/dovecot-lmtp virtual_transport = lmtp:unix:private/dovecot-lmtp My system hostname is theboilingfrog.net. This configuration fails to recognize mark@theboilingfrog.net...which is why I think the passdb pam block is ignoring the auth_username_format directive which should strip out the username portion. Claude Code finally got around to suggesting I cut dovecot out of the loop for delivery of emails to system users. I guess I could do that, but I'd love to know if it's possible to keep dovecot engaged with delivering system user emails and have it work property. Another thing is I could update all my email clients to use 'mark' rather than 'mark(a)theboilingfrog.net' to access their email. But, again, I'm curious if there's a way to configure things so I don't have to do that. If it turns out what I'm trying to do is not supported, please let me know. - Mark -

2 1

Re: Dovecot 2.4.5 on macOS 27 ARM64: post-authentication IMAP connection closes
by George 05 Oct '26

05 Oct '26

Hello, I am comparing Dovecot 2.3.21.1 and 2.4.5 on the same arm64 macOS host. Apple Mail and Thunderbird work normally with 2.3.21.1, but both fail at the same post-authentication boundary with 2.4.5. The comparison keeps the client, mailbox data, TLS certificate, CRAM-MD5 credentials, public-IP/hairpin path, and base_dir=/var/run/dovecot the same. Only one Dovecot version is running at a time. With 2.4.5: - TLS and CRAM-MD5 succeed. - SQL passdb and static userdb succeed. - imap-login reports "Logged in". - The authenticated imap process loads its plugins, assumes uid/gid 350, and resolves the expected namespace and Maildir. - It then reports: Disconnected: Connection closed (No commands sent) in=0 out=502 Two Apple Mail attempts repeat the same result. There is no panic, fatal error, signal, or explicit anvil error in the captured interval. The /proc/self/stat and /proc/self/io debug messages also occur with the working 2.3 build on macOS. With 2.3.21.1, the same Apple Mail version proceeds immediately to open INBOX, Junk, and Sent, reads headers and complete messages, and logs out normally. Thunderbird likewise completes NAMESPACE, COMPRESS, ID, SELECT, LIST/FETCH, STATUS, and IDLE with 2.3. Under 2.4, its client trace shows NAMESPACE being sent immediately before the socket closes, while the server-side imap process records no command. One process-model difference is: 2.3: service imap { process_limit = 200 client_limit = 5 service_count = 0 } 2.4: service imap { client_limit = 1 } I understand that client_limit=1 is the recommended 2.4 setting, so I am not assuming this is misconfiguration; I mention it because the failure occurs at the post-login process/handoff boundary. The build already includes commit 5100f0fd576d0600c3f8ad7bb056ae08235cab11, so I do not believe the previously reported peer-PID/anvil fix is simply absent. Attached: 1. doveconf-2.4.5-sanitized.txt 2. dovecot-2.4.5-apple-mail-sanitized.txt I have also prepared a short paired 2.3/2.4 excerpt and can provide the complete sanitized Thunderbird client trace if useful. What additional master/anvil/process logging would best identify where the authenticated connection is being lost on macOS?

1 1

SEGV in fts_search_merge_scores_or in 2.4.5
by Patrick Cernko 05 Oct '26

05 Oct '26

Hi Devs, yesterday I had to SEGV from imap processes (2.4.5) which dumped core. The backtraces were similar: > #0 0x00007fdb234556b4 in fts_search_merge_scores_or (dest=0x7ffde96b1720, src=0x7ffde96b1680) at ./src/plugins/fts/fts-search.c:274 > 274 src_map[srci].uid < src2_map[src2i].uid) { > (gdb) bt > #0 0x00007fdb234556b4 in fts_search_merge_scores_or (dest=0x7ffde96b1720, src=0x7ffde96b1680) at ./src/plugins/fts/fts-search.c:274 > #1 fts_search_merge_scores_level (fctx=fctx@entry=0x55ce3f2347d0, args=0x55ce3f2fad10, idx=idx@entry=0x7ffde96b182c, and_args=false, scores=scores@entry=0x7ffde96b1720) > at ./src/plugins/fts/fts-search.c:329 > #2 0x00007fdb234555fa in fts_search_merge_scores_level (fctx=fctx@entry=0x55ce3f2347d0, args=0x55ce3f2fa878, idx=idx@entry=0x7ffde96b182c, and_args=true, scores=scores@entry=0x7ffde96b17c0) > at ./src/plugins/fts/fts-search.c:322 > #3 0x00007fdb234555fa in fts_search_merge_scores_level (fctx=fctx@entry=0x55ce3f2347d0, args=0x55ce3f22d458, idx=idx@entry=0x7ffde96b182c, and_args=and_args@entry=true, > scores=0x55ce3f2ffb68) at ./src/plugins/fts/fts-search.c:322 > #4 0x00007fdb2345b2ee in fts_search_merge_scores (fctx=0x55ce3f2347d0) at ./src/plugins/fts/fts-search.c:337 > #5 fts_search_try_lookup (fctx=0x55ce3f2347d0) at ./src/plugins/fts/fts-search.c:404 > #6 fts_search_lookup (fctx=fctx@entry=0x55ce3f2347d0) at ./src/plugins/fts/fts-search.c:414 > #7 0x00007fdb2345bc25 in fts_mailbox_search_init (t=<optimized out>, args=0x55ce3f22cd28, sort_program=<optimized out>, wanted_fields=0, wanted_headers=<optimized out>) > at ./src/plugins/fts/fts-storage.c:213 > #8 0x00007fdb266b7d99 in mailbox_search_init (t=0x55ce3f322fb0, args=args@entry=0x55ce3f22cd28, sort_program=sort_program@entry=0x0, wanted_fields=wanted_fields@entry=0, > wanted_headers=wanted_headers@entry=0x0) at ../lib-storage/mail-storage.c:2988 > #9 0x000055ce070d746c in imap_search_start (ctx=0x55ce3f1cb568, sargs=0x55ce3f22cd28, sort_program=0x0) at ./src/imap/imap-search.c:538 > #10 0x000055ce070c3702 in cmd_search (cmd=0x55ce3f1cb1a8) at ./src/imap/cmd-search.c:54 > #11 0x000055ce070c8394 in command_exec (cmd=cmd@entry=0x55ce3f1cb1a8) at ./src/imap/imap-commands.c:208 > #12 0x000055ce070cec20 in client_command_input (cmd=<optimized out>, cmd@entry=0x55ce3f1cb1a8) at ./src/imap/imap-client.c:1359 > #13 0x000055ce070cecb6 in client_command_input (cmd=<optimized out>, cmd@entry=0x55ce3f1cb1a8) at ./src/imap/imap-client.c:1429 > #14 0x000055ce070cef4d in client_command_input (cmd=<optimized out>) at ./src/imap/imap-client.c:1393 > #15 0x000055ce070cf135 in client_handle_next_command (client=0x55ce3f1c9788, remove_io_r=<synthetic pointer>) at ./src/imap/imap-client.c:1471 > #16 client_handle_input (client=client@entry=0x55ce3f1c9788) at ./src/imap/imap-client.c:1485 > #17 0x000055ce070cf527 in client_input (client=0x55ce3f1c9788) at ./src/imap/imap-client.c:1529 > #18 0x00007fdb26379cdb in io_loop_call_io (io=0x55ce3f1cb960) at ../lib/ioloop.c:749 > #19 0x00007fdb2637bb1b in io_loop_handler_run_internal (ioloop=ioloop@entry=0x55ce3f19b5c0) at ../lib/ioloop-epoll.c:222 > #20 0x00007fdb2637bbe4 in io_loop_handler_run (ioloop=ioloop@entry=0x55ce3f19b5c0) at ../lib/ioloop.c:803 > #21 0x00007fdb2637bde8 in io_loop_run (ioloop=0x55ce3f19b5c0) at ../lib/ioloop.c:774 > #22 0x00007fdb262c34be in master_service_run (service=0x55ce3f19ad10, callback=callback@entry=0x55ce070d3e30 <client_connected>) at ../lib-master/master-service.c:1280 > #23 0x000055ce070ba036 in main (argc=<optimized out>, argv=<optimized out>) at ./src/imap/main.c:588 in both cases the SEGV was caused by illegal access to `src_map[srci]`: > (gdb) print src_map[srci] > Cannot access memory at address 0x7fdb23091000 I can provide the coredumps to you (but not public) if you are interested. Best, -- Patrick Cernko <errror(a)errror.org>

2 1

Dovecot 2.4.5 on macOS 27 ARM64: post-authentication IMAP connection closes
by list2＠captainnet.net 05 Oct '26

05 Oct '26

I captured Thunderbird’s client-side IMAP protocol log against both Dovecot 2.3.21.1 and 2.4.5 on the same server, account and Maildir. With 2.3.21.1, CRAM-MD5 authentication succeeds and Thunderbird continues normally through NAMESPACE, COMPRESS, ID and SELECT: ```text <CRAM-MD5 exchange removed> OK [CAPABILITY ...] Logged in SendData: 4 namespace * NAMESPACE (("" "/")) NIL NIL 4 OK Namespace completed SendData: 5 COMPRESS DEFLATE 5 OK Begin compression SendData: 6 ID ("name" "Thunderbird" "version" "157.0.1") * ID ("name" "Dovecot" "version" "2.3.21.1") SendData: 7 select "INBOX" * 7 EXISTS 7 OK [READ-WRITE] Select completed ``` With 2.4.5, authentication also succeeds, but the connection closes immediately when Thunderbird sends its first post-authentication command: ```text <CRAM-MD5 exchange removed> OK [CAPABILITY ...] Logged in login succeeded SendData: 62 namespace CreateNewLineFromSocket: clearing IMAP_CONNECTION_IS_OPEN - rv = 80470002 TellThreadToDie: close socket connection CreateNewLineFromSocket: (null) SetConnectionStatus(0x80470002) ``` The same sequence repeats on the second parallel Thunderbird connection and on subsequent retries. Thunderbird receives no IMAP BAD, NO or BYE response. It never reaches ID, SELECT or mailbox discovery with 2.4.5. Commit 5100f0fd576d0600c3f8ad7bb056ae08235cab11 is already present in the source used for this Dovecot 2.4.5 build, so the observed failure occurs with that change included. The Thunderbird timestamps are UTC. The first 2.4 failure occurred at 2026-10-02 15:31:01 UTC, corresponding to 08:31:01 local server time. I can provide a sanitized longer Thunderbird trace and the corresponding Dovecot log interval if that would be useful.

2 1

the 32-bit issue with time offset is back in 2.4.5 was fixed in 2.4.4
by dovecot＠freakout.de 04 Oct '26

04 Oct '26

# Logs are flooded with messages "Warning: Time moved forward" # The function io_loop_get_wait_time in ioloop.c contains the line: # ioloop->next_max_time.tv_sec = (time_t)(((uint64_t)1 << TIME_T_MAX_BITS) - 1); #On 32-bit systems TIME_T_MAX_BITS is 31 such that the result of this calculation is 1073741823. Far from the #intended "infinity" and even before "now". This leads to problems in the function io_loop_handle_timeouts_real: #the calculation of the time difference between now and next_max_time is then something like -693628953 seconds #which confuses dovecot and floods the logs with these warnings: patch -b -p0 <<'EOF' --- src/lib/time-util.c 2026-08-26 12:00:29.000000000 +0200 +++ src/lib/time-util.c 2026-10-02 13:10:39.000000000 +0200 @@ -166,7 +166,7 @@ #else /* compute in uint64_t: with a 32-bit signed time_t TIME_T_MAX_BITS is 31 and (time_t)1 << 31 would overflow */ - return (time_t)(((uint64_t)1 << TIME_T_MAX_BITS) - 1); + return (time_t)(((uint64_t)1 << TIME_T_MAX_BITS-1) - 1); #endif } EOF

1 0

Mailbox doesn't exist
by Simon B 02 Oct '26

02 Oct '26

Hallo, I was preparing the upgrade to 2.4 and I shot myself in the foot. I am on 2.3.19.1, but I think my issue is not version dependent. I had a folder - created using Horde and showing in Horde and Thunderbird as - Auszüge But on the file system I noticed it was .Ausz%C3%BCge Well, my system is UTF8, so I renamed it... Now Horde still displays it as Auszüge, but does not show any emails in that folder. Thunderbird also displays it as Auszüge, and does show the emails, but neither client will put (move/copy) any new email into that folder.... doveadm mailbox list -u simon(a)myserver.net lists it. doveadm -f table mailbox status -u simon(a)myserver.net "messages vsize" Auszüge says doveadm(simon(a)myserver.net): Error: Mailbox Auszüge: Failed to lookup mailbox status: Mailbox doesn't exist: Auszüge doveadm -f table mailbox status -u simon(a)myserver.net "messages vsize" Ausz%C3%BCge says mailbox messages vsize i.e. shows no messages - but does not complain the Mailbox does not exist. How can I rescue this before proceeding with my upgrade? Thanks. Simon

2 2

Assessing an old Dovecot 2.2.13 for migration
by mercurialuser＠gmail.com 01 Oct '26

01 Oct '26

Actual situation: dovecot 2.2.13 on centos 6.5, previously it was a courier server MTA is exim and it used to drop the emails directly in the filesystem in Maildir format, and it still happens for some of the 80(ish) emails. I then moved to a LMTP delivery via Dovecot to use Dovecot compression. Thunderbird is used, and a imap webmail is also available. There is no quota, by design, biggest mailbox is 54 GB with ten over 30GB. By design, one user has all the mailboxes of its dept collegues available in Thunderbird. Users are defined in a test file with this parameter userdb_mail=maildir:/mailboxes/domains/%d/%n/Maildir In the Maildir the folders are in this format (they use . as separator) and some users are like this: .INBOX.00 IMPORTANT but other are without .INBOX: .00 IMPORTANT Probably the ones with .INBOX prefix were already present in Courier. doveconf namespace reports namespace inbox { disabled = no hidden = no ignore_on_failure = no inbox = yes list = yes location = ... (lines removed prefix = separator = subscriptions = yes type = private } To test dovecot tools since some of the emails are "read-only" (can't receive new emails) I tried to move from a Maildir mailbox to a mdbox (also to have a quicker rsync backup) a issued dovecot backup mdbox:/path/to/mdbox/storage that failed with this error message dsync(username): Error: Mail locations must use the same virtual mailbox hierarchy separator (specify separator for the default namespace) So I started to dig into the problem, discovering that some settings were not set (see doveconf output), that there are 2 different "separator" and that I may, presumably, keep them different on a per-user bases using LAYOUT=fs. I also noticed the .INBOX being present and not present. I'm looking for informations on how to proceed to have dovecot backup work without losing the mail on disk and have all the Maildirs share a common standard. I'd like to use dovecot tools, but an option is to creare a new server, create all the accounts, define the accounts in the user Thunderbirds, and do a "move" between the old and new server .... crossing fingers...

1 0

Making AI Feedback Part of a Supervised Writing Process
by harri.evans90＠protonmail.com 30 Sep '26

30 Sep '26

Begin with the Student’s Reasoning When assessing AI assistance in academic writing, I start with the decisions a student must make. A polished essay offers limited evidence of learning if the writer cannot explain its argument, defend its sources, or justify its revisions. My approach therefore places the student’s reasoning at the center of the writing process and evaluates assistance according to whether it strengthens that reasoning. I consider academic writing software most useful when its function is defined within a supervised workflow. When evaluating a resource such as https://essaysbot.com/, I would first consider how its use fits the assignment’s learning objectives and the instructor’s requirements. Artificial intelligence can help a writer examine an outline, identify unclear explanations, and reconsider paragraph structure. Its educational value depends on how the student interprets the feedback and applies it to the assignment. A writing assistant should create opportunities for analysis while keeping intellectual decisions with the student. The following consultation framework uses an illustrative undergraduate sociology essay about remote work and workplace inequality. I use this example to show how an educator can connect digital assistance with planning, research, and independent revision without treating generated language as evidence of understanding. Establish the Task Before Requesting Output I would begin the consultation by reviewing the assignment instructions with the student. Before opening a digital tool, the writer should identify the research question, intended audience, assessment criteria, citation style, word count, and deadline. These details determine the scope of the essay and give automated feedback a relevant context. For the sociology assignment, a broad question about whether remote work is beneficial would need refinement. A more manageable inquiry could examine how access to remote employment affects workers with different caring responsibilities. The student would then develop a provisional thesis statement after reviewing the assigned readings and locating suitable evidence. At this stage, I would ask the student to prepare an outline independently. A language model could subsequently examine whether the proposed sections overlap or whether an important counterargument remains unaddressed. A focused prompt might request questions about the relationship between employment flexibility and promotion opportunities. This preserves an investigative research process because the student must resolve those questions through reading. Course expectations also belong in this initial discussion. I would check the instructor’s requirements for responsible use, disclosure, and permitted assistance before recommending a particular activity. Academic integrity becomes easier to manage when expectations are translated into specific actions within the student workflow. Move from Feedback to Deliberate Revision My preferred revision cycle addresses one substantive concern at a time. Asking a system to improve an entire essay can produce extensive suggestions with unclear priorities. Asking whether each topic sentence advances the central claim gives the student a defined problem and a basis for evaluating the response. Consider a paragraph describing reduced commuting costs. Its information may be relevant, yet its connection to workplace inequality may remain unexplained. Automated feedback could flag that gap. The student must decide whether the paragraph needs additional evidence, a clearer explanation, or removal. Each option requires a different judgment about the argument. I would review the overall reasoning before sentence clarity, editing, and proofreading. A reverse outline can help: the student summarizes the actual purpose of each paragraph in the existing draft, then compares that sequence with the intended argument. Repetition, unsupported claims, and missing transitions become easier to locate when attention shifts from individual sentences to the essay’s organization. To make the feedback loop educational, I would request a brief revision rationale for major changes. The student should explain why a claim was narrowed, a section moved, or a suggestion rejected. This guided practice encourages critical thinking and gives the educator a clearer view of developing writing skills. It also allows feedback to remain useful when the model’s recommendation is inappropriate. Keep Evidence and Attribution Verifiable I separate source quality from fluent expression. A generated draft may present an explanation confidently without establishing that its supporting material is accurate or relevant. I would therefore require the student to verify factual claims against sources they have retrieved and read, including the context and limitations of the original research. In the sociology example, evidence about professional employees in one industry may not support conclusions about all workers. The writer must examine the study population, methods, and publication context before applying its findings. A tool can suggest verification questions, but the student remains responsible for answering them. Citation awareness should begin during note-taking. I recommend distinguishing direct quotations, paraphrases, and independent analysis before drafting. This practice supports originality and plagiarism awareness while preventing attribution problems from accumulating near the deadline. A system may help explain reference formatting or flag passages that appear to require a citation. Nevertheless, I would check each reference against the original publication and the required style guidance. Bibliographic accuracy includes both identifying a real source and confirming that it supports the associated claim. Assess Learning Through the Final Review During the final review, I would compare output quality with the rubric and ask the student to explain the essay’s reasoning in their own words. The conclusion should answer the research question within the limits of the evidence. Word count management should remove duplication while preserving necessary analysis, rather than reduce every section mechanically. For educators and academic consultants, instructional design should make these checkpoints visible. An outline, source notes, selected feedback, and a short revision explanation can provide useful evidence of the learning process without requiring an exhaustive record of every interaction. I judge AI-supported learning by the quality of the student’s decisions and their ability to apply the same principles independently. Learning support has achieved its purpose when the writer can recognize a weak explanation, investigate its cause, and choose a defensible revision. That capacity gives writing confidence a sound foundation and keeps authorship grounded in informed judgment.

1 0

Dovecot 2.4.5 on macOS 27 ARM64: anvil panic with imap-login pid=-1
by list2＠captainnet.net 30 Sep '26

30 Sep '26

Subject: Dovecot 2.4.5 on macOS 27 ARM64: anvil panic with imap-login pid=-1 I am testing Dovecot 2.4.5 on macOS 27 (Darwin 27.0.0), ARM64/Apple Silicon, migrating a working Dovecot 2.3.21.1 installation. IMAP itself appears to be functioning correctly. Authentication succeeds using CRAM-MD5, the userdb resolves the expected uid/gid/home, Maildir is opened correctly, and Roundcube can see all folders and messages. LMTP delivery also works. However, under multiple IMAP connections I repeatedly see anvil receive an imap-login connection with pid=-1: anvil: Warning: conn unix:anvil (uid=0): Handshake with duplicate service=imap-login pid=-1 - replacing the old connection This can then lead to: anvil: Panic: file anvil-connection.c: line 837: unreached anvil: Fatal: master: service(anvil): child ... killed with signal 6 followed by: anvil: Error: connect limit: disconnection for unknown (pid=..., user=testuser(a)example.com, service=imap, ...) With mail_debug=yes, the IMAP process itself looks healthy immediately around the failure. For example: Debug: Effective uid=350, gid=350, home=/private/var/mail/example.com/testuser@example.com Debug: Namespace inbox: type=private, prefix=, sep=/, inbox=yes, hidden=no, list=yes, subscriptions=yes Debug: maildir++: root=/private/var/mail/example.com/testuser@example.com/Maildir, inbox=/private/var/mail/example.com/testuser@example.com/Maildir Apple Mail successfully establishes TLS and authenticates: imap-login: Info: Logged in: user=<testuser(a)example.com>, method=CRAM-MD5, rip=192.0.2.10, lip=192.0.2.20, TLS Dovecot's own mailbox tools confirm that the mailboxes and messages exist: # doveadm mailbox list -u testuser(a)example.com -s Sent Drafts Archive Trash Junk # doveadm mailbox status -u testuser(a)example.com \ messages uidvalidity uidnext INBOX Sent Sent messages=1 INBOX messages=7 I initially experimented with disabling the anvil-auth-penalty listener, but reverted that. The problem also occurs with the stock/default Dovecot 2.4.5 anvil configuration: service anvil { executable = anvil process_limit = 1 process_min_avail = 1 unix_listener anvil { group = $SET:default_internal_group mode = 0660 } unix_listener anvil-auth-penalty { group = $SET:default_internal_group mode = 0660 type = penalty } unix_listener anvil-connect-limit { group = $SET:default_internal_group mode = 0660 type = connect-limit } } The effective default is currently: mail_max_userip_connections = 10 Dovecot 2.3.21.1 on the same ARM64 Mac, using the same users/Maildirs, does not exhibit this problem. The particularly suspicious part seems to be the imap-login pid=-1 registration immediately preceding the anvil failure. Is this a known 2.4.x issue on macOS/ARM64, and is there a supported way in 2.4.5 to disable anvil connection tracking as a workaround while retaining IMAP service? I can provide the complete doveconf -n, full backtrace, and additional debug logging if useful.

2 1

dovecot submission Outlook issue
by Adrian M 30 Sep '26

30 Sep '26

Hello, I'm testing dovecot submission and I have some issues with Outlook clients. Thunderbird works without a hitch, only Outlook cannot send mails. If someone has seen this please let me know ! The log looks like this: Sep 28 09:36:12 mail dovecot: submission(user1)<1419><Ii0QSIVc2OvAqHBK>: Disconnected: Connection closed (unfinished QUIT command) (state=GREETING) in=44 out=81 Sep 28 09:37:23 mail dovecot: submission(user1)<4909><zOBITIVc6OfAqHBK>: Disconnected: Connection closed (unfinished QUIT command) (state=GREETING) in=44 out=81 My dovecot config has the following lines in local.conf: submission_relay_host = 127.0.0.1 submission_relay_port = 174 submission_relay_trusted = yes service submission-login { inet_listener submission { port = 587 } inet_listener submissions { port = 465 ssl = yes } } Hello, I'm testing dovecot submission and I have some issues with Outlook clients. Thunderbird works without a hitch, only Outlook cannot send mails. If someone has seen this please let me know ! The log looks like this: Sep 28 09:36:12 mail dovecot: submission(user1)<1419><Ii0QSIVc2OvAqHBK>: Disconnected: Connection closed (unfinished QUIT command) (state=GREETING) in=44 out=81 Sep 28 09:37:23 mail dovecot: submission(user1)<4909><zOBITIVc6OfAqHBK>: Disconnected: Connection closed (unfinished QUIT command) (state=GREETING) in=44 out=81 My dovecot config has the following lines in local.conf: submission_relay_host = 127.0.0.1 submission_relay_port = 174 submission_relay_trusted = yes service submission-login { inet_listener submission { port = 587 } inet_listener submissions { port = 465 ssl = yes } }

3 3

Re: Migration to 2.4: Howto get the quota dict writing into a second DB
by Felipe Carneiro 28 Sep '26

28 Sep '26

Hello, This is regarding your message at https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/message/XW53… (I tried to reply on the thread but I don't have permission.) Were you able to get it working? I'm having the same problem with Dovecot 2.4. I've tried configuring it exactly as the documentation says, but I get this error when enabling the quota_clone plugin: *Error: quota_clone: dict_init_auto() failed: dict { .. } named list filter is missing* Same problem reported by other users: https://github.com/postfixadmin/postfixadmin/issues/935 Thanks in advance ! -- Best regards, Felipe Carneiro Hello, This is regarding your message at [1]https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/message/XW… (I tried to reply on the thread but I don't have permission.) Were you able to get it working? I'm having the same problem with Dovecot 2.4. I've tried configuring it exactly as the documentation says, but I get this error when enabling the quota_clone plugin: Error: quota_clone: dict_init_auto() failed: dict { .. } named list filter is missing Same problem reported by other users: [2]https://github.com/postfixadmin/postfixadmin/issues/935 Thanks in advance ! -- Best regards, Felipe Carneiro References Visible links 1. https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/message/XW53… 2. https://github.com/postfixadmin/postfixadmin/issues/935

2 4

Dovecot 2.4.5 - Oath2 proxy
by Jerome Dalle 28 Sep '26

28 Sep '26

Hello I'm trying to set the pssdbb static (as describe in the documentation) to forward my oath2 authentication to backend Unfortunately, dovecot is unable to start with error: auth: Fatal: Cannot initialize oauth2: Missing oauth2_introspection_mode setting If anyone can help ? Thanks Hello I'm trying to set the pssdbb static (as describe in the documentation) to forward my oath2 authentication to backend Unfortunately, dovecot is unable to start with error: auth: Fatal: Cannot initialize oauth2: Missing oauth2_introspection_mode setting If anyone can help ? Thanks

2 1

Dovecot Mailbox Viewer (Windows)
by jay＠designstack.co.uk 25 Sep '26

25 Sep '26

Hi Guys, I’ve been working on 'Dovecot Mailbox Viewer', a free, open-source Windows application for browsing Dovecot mdbox backups without setting up a Dovecot server. It started as a way to help a client access emails from a JetBackup/cPanel backup. You can open a .tar.gz archive or extracted folder, browse mailbox folders, search messages, view HTML emails, save attachments and export emails as pdf or .eml. The app is read-only and leaves the original backup untouched. Everything is processed locally, and remote images are blocked unless you choose to download them. There’s a standalone Windows executable available, so no Python installation is needed. Code, screenshots and downloads: https://github.com/DesignStack/Dovecot-Mailbox-Viewer It’s still early days, so feedback from the Dovecot community would be very welcome! Thanks! Jay

1 0

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

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 09 Sep '26

09 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