October 2026 - dovecot

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