October 2026 - dovecot

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

12 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

4 3

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

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

05 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.

1 0

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