- dovecot - dovecot.org

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