- dovecot - dovecot.org

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

18 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

4 9

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

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

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

2 1

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

15 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 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

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

09 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

1 0

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