- dovecot - dovecot.org

Attachments corrupted by sieve "redirect" action
by Michael Orlitzky 18 Dec '25

18 Dec '25

We got a report today from one of our customers that they are unable to "redirect" mail with attachments off-site. At first I was skeptical, because sieve does not mess with the message body... but sure enough, it's easy to reproduce: 1. Create a new address (mailbox) 2. Create a single sieve "redirect" filter for that address, pointing to my own mailbox 3. Send it a message with an attachment 4. An attachment is visible on the message that arrives, but it is corrupt For example: $ cat hello.original.txt Hello, world! but $ cat hello.attached.txt (it's empty). Sending a JPEG image is a bit more enlightening: $ /bin/ls -l *jpg -rw------- 1 mjo mjo 337119 Dec 18 11:15 image.attached.jpg -rw-r--r-- 1 mjo mjo 337173 Dec 18 11:13 image.original.jpg So something _is_ sent, but the start of the file is corrupt. Looking at it in a hex editor, it's only the first few lines that are messed up. This is with dovecot 2.4.2, but notably, we are using zlib compression: mail_plugins = mail_compress mail_compress_write_method = gz I'm curious if anyone else can reproduce this? Redirecting via sieve is not common, so this isn't an emergency, but obviously it is preferable to have it working.

2 1

Imap-login bind errors after upgrading dovecot from 2.3 to 2.4
by onyeibo 18 Dec '25

18 Dec '25

Greetings I updated the OS in a VPS blindly and broke the mail service. I had set up this service over four years ago and never had issues with upgrades until recently. I realized the gravity of my mistake after dovecot refused to start. Version 2.4.1 had arrived and I am in so much trouble. So far, I have adapted the configuraton files to 2.4 standards. "doveadm auth test user" tells me that the authentication is working fine. I am able to view old mails via doveadm. However, I get nothing new from mail clients. The maillog tells me that mails are getting queued (why?). I see status=sent (250.2.0.0) in some transactions, but that is the extent of success. However, I still get a nagging error message (see the end of this mail). dovecot -n # Pigeonhole version 2.4.1-4 (0a86619f) # OS: Linux 6.17.11-300.fc43.x86_64 x86_64 Fedora release 43 (Forty Three) dovecot_config_version = 2.4.1 auth_debug = yes auth_mechanisms = plain login dovecot_storage_version = 2.4.1 first_valid_uid = xxxx mail_driver = maildir mail_home = /home/mails/%{user | domain}/%{user | username} mail_path = %{home}/Maildir mail_privileged_group = mail passdb_default_password_scheme = BLF-CRYPT protocols { imap = yes lmtp = yes sieve = yes } sql_driver = pgsql ssl = required ssl_cipher_list = PROFILE=SYSTEM pgsql localhost { parameters { dbname = postfix password = xxxxxxx user = postfix } } passdb sql {n query = SELECT username AS user, password FROM mailbox WHERE username = '%{user}' AND active='1' } userdb sql { query = SELECT '/home/mails/' || maildir AS home, xxxx as uid, xxxx as gid FROM mailbox WHERE username = '%{user}' AND active = '1' } namespace inbox { inbox = yes mailbox Drafts { auto = create special_use = "\\Drafts" } mailbox Junk { auto = create special_use = "\\Junk" } mailbox Trash { auto = create special_use = "\\Trash" } mailbox Sent { auto = create special_use = "\\Sent" } mailbox "Sent Messages" { special_use = "\\Sent" } } service lmtp { executable = lmtp -L process_min_avail = 5 user = vmail unix_listener /var/spool/postfix/private/dovecot-lmtp { group = postfix mode = 0600 user = postfix } } service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0600 user = postfix } } service stats { unix_listener stats-reader { group = vmail mode = 0660 user = vmail } unix_listener stats-writer { group = vmail mode = 0660 user = vmail } } ssl_server { cert_file = /etc/letsencrypt/live/xxxxxxx.com/fullchain.pem dh_file = /etc/dovecot/dh.pem key_file = /etc/letsencrypt/live/xxxxxxx.com/privkey.pem prefer_ciphers = server } protocol lmtp { info_log_path = /var/log/lmtp/dovecot-lmtp.log mail_plugins { sieve = yes } } service managesieve-login { inet_listener sieve { port = 4190 } } service managesieve { } protocol sieve { managesieve_implementation_string = Dovecot Pigeonhole } sieve_script personal { active_path = ~/.dovecot.sieve path = ~/sieve} I did adjust an entry in postfix (master.cf). I switched from dovecot-lda to dovecot-lmtp. LDA was throwing permission errors when accessing the cert file. Most reference materials recommended LMTP because its processes already have the required privileges. So ... master.cf (postfix)dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/libexec/dovecot/deliver -f ${sender} -a ${original_recipient} -d ${user}@${nexthop}# maillog errors Dec 16 22:16:29 xxxxxxx.com dovecot[139456]: master: Error: bind(/run/dovecot/srv.imap-login/139456) failed: No such file or directory Dec 16 22:16:29 xxxxxxx.com dovecot[139456]: master: Fatal: Failed to create per-PID unix_listener %{pid}: net_listen_unix(/run/dovecot/srv.imap-login/139456) failed: No such file or directory Dec 16 22:16:29 xxxxxxx.com dovecot[809]: master: Error: service(imap-login): command startup failed, throttling for 2.000 secsDec 16 22:16:29 xxxxxxx.com dovecot[139216]: imap-login: Fatal: master: service(imap-login): child 139456 returned error 89 (Fatal failure) What am I missing? Regards Onyeibo Greetings I updated the OS in a VPS blindly and broke the mail service. I had set up this service over four years ago and never had issues with upgrades until recently. I realized the gravity of my mistake after dovecot refused to start. Version 2.4.1 had arrived and I am in so much trouble. So far, I have adapted the configuraton files to 2.4 standards. "doveadm auth test user" tells me that the authentication is working fine. I am able to view old mails via doveadm. However, I get nothing new from mail clients. The maillog tells me that mails are getting queued (why?). I see status=sent (250.2.0.0) in some transactions, but that is the extent of success. However, I still get a nagging error message (see the end of this mail). dovecot -n # Pigeonhole version 2.4.1-4 (0a86619f) # OS: Linux 6.17.11-300.fc43.x86_64 x86_64 Fedora release 43 (Forty Three) dovecot_config_version = 2.4.1 auth_debug = yes auth_mechanisms = plain login dovecot_storage_version = 2.4.1 first_valid_uid = xxxx mail_driver = maildir mail_home = /home/mails/%{user | domain}/%{user | username} mail_path = %{home}/Maildir mail_privileged_group = mail passdb_default_password_scheme = BLF-CRYPT protocols { imap = yes lmtp = yes sieve = yes } sql_driver = pgsql ssl = required ssl_cipher_list = PROFILE=SYSTEM pgsql localhost { parameters { dbname = postfix password = xxxxxxx user = postfix } } passdb sql {n query = SELECT username AS user, password FROM mailbox WHERE username = '%{user}' AND active='1' } userdb sql { query = SELECT '/home/mails/' || maildir AS home, xxxx as uid, xxxx as gid FROM mailbox WHERE username = '%{user}' AND active = '1' } namespace inbox { inbox = yes mailbox Drafts { auto = create special_use = "\\Drafts" } mailbox Junk { auto = create special_use = "\\Junk" } mailbox Trash { auto = create special_use = "\\Trash" } mailbox Sent { auto = create special_use = "\\Sent" } mailbox "Sent Messages" { special_use = "\\Sent" } } service lmtp { executable = lmtp -L process_min_avail = 5 user = vmail unix_listener /var/spool/postfix/private/dovecot-lmtp { group = postfix mode = 0600 user = postfix } } service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0600 user = postfix } } service stats { unix_listener stats-reader { group = vmail mode = 0660 user = vmail } unix_listener stats-writer { group = vmail mode = 0660 user = vmail } } ssl_server { cert_file = /etc/letsencrypt/live/xxxxxxx.com/fullchain.pem dh_file = /etc/dovecot/dh.pem key_file = /etc/letsencrypt/live/xxxxxxx.com/privkey.pem prefer_ciphers = server } protocol lmtp { info_log_path = /var/log/lmtp/dovecot-lmtp.log mail_plugins { sieve = yes } } service managesieve-login { inet_listener sieve { port = 4190 } } service managesieve { } protocol sieve { managesieve_implementation_string = Dovecot Pigeonhole } sieve_script personal { active_path = ~/.dovecot.sieve path = ~/sieve } I did adjust an entry in postfix (master.cf). I switched from dovecot-lda to dovecot-lmtp. LDA was throwing permission errors when accessing the cert file. Most reference materials recommended LMTP because its processes already have the required privileges. So ... master.cf (postfix) dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/libexec/dovecot/deliver -f ${sender} -a ${original_recipient} -d ${user}@${nexthop}# maillog errors Dec 16 22:16:29 [1]xxxxxxx.com dovecot[139456]: master: Error: bind(/run/dovecot/srv.imap-login/139456) failed: No such file or directory Dec 16 22:16:29 [2]xxxxxxx.com dovecot[139456]: master: Fatal: Failed to create per-PID unix_listener %{pid}: net_listen_unix(/run/dovecot/srv.imap-login/139456) failed: No such file or directory Dec 16 22:16:29 [3]xxxxxxx.com dovecot[809]: master: Error: service(imap-login): command startup failed, throttling for 2.000 secs Dec 16 22:16:29 [4]xxxxxxx.com dovecot[139216]: imap-login: Fatal: master: service(imap-login): child 139456 returned error 89 (Fatal failure) What am I missing? Regards Onyeibo References Visible links 1. http://xxxxxxx.com/ 2. http://xxxxxxx.com/ 3. http://xxxxxxx.com/ 4. http://xxxxxxx.com/

4 9

Bug Report: authCacheFlush HTTP API crashes with assertion failure
by Yurii Krainiuk 17 Dec '25

17 Dec '25

*## Title* authCacheFlush HTTP API crashes with assertion failure - type mismatch between API schema and implementation *## Dovecot Version* 2.4.2 *## Component* doveadm HTTP API *## Description* The authCacheFlush command via doveadm HTTP API causes a server crash with an assertion failure. The HTTP API schema declares the user parameter as array type, but the internal implementation (doveadm_cmd_param_str) expects string type, causing a type mismatch assertion failure. *## Steps to Reproduce* 1. Send any authCacheFlush request to doveadm HTTP API: bash curl -X POST \ -H "Authorization: X-Dovecot-API <api_key>" \ -H "Content-Type: application/json" \ -d '[["authCacheFlush",{"user":"username(a)domain.com"},"tag1"]]' \ http://localhost:8080/doveadm/v1 2. Or with user as array (matching the declared schema): bash curl -X POST \ -H "Authorization: X-Dovecot-API <api_key>" \ -H "Content-Type: application/json" \ -d '[["authCacheFlush",{"user":["username(a)domain.com"]},"tag1"]]' \ http://localhost:8080/doveadm/v1 3. Or without any parameters: bash curl -X POST \ -H "Authorization: X-Dovecot-API <api_key>" \ -H "Content-Type: application/json" \ -d '[["authCacheFlush",{},"tag1"]]' \ http://localhost:8080/doveadm/v1 *## Expected Result* Auth cache should be flushed and API returns success response like: json [["doveadmResponse",[{"entries":1}],"tag1"]] *## Actual Result* Server crashes with empty reply (HTTP connection closed). The doveadm process is killed with signal 6 (SIGABRT). *## Error Log* Panic: file doveadm-cmd-parse.c: line 120 (doveadm_cmd_param_str): assertion failed: (param->type == CMD_PARAM_STR) Error: Raw backtrace: #0 test_subprocess_fork[0x7362eb54a570] -> #1 backtrace_append[0x7362eb54a820] -> #2 backtrace_get[0x7362eb54a9c0] -> #3 e_info[0x7362eb556370] -> #4 i_syslog_fatal_handler[0x7362eb5564b0] -> #5 i_panic[0x7362eb474f28] -> #6 [unw_get_proc_name() failed: -10] -> #7 http_server_connection_shut_down[0x7362eb4e6a00] -> #8 io_loop_call_io[0x7362eb572510] -> #9 io_loop_handler_run_internal[0x7362eb5743a0] -> #10 io_loop_handler_run[0x7362eb574540] -> #11 io_loop_run[0x7362eb574740] -> #12 master_service_run[0x7362eb4bc640] -> #13 main[0x64c4233d74f0] -> #14 __libc_init_first[0x7362eb02a150] -> #15 __libc_start_main[0x7362eb02a200] -> #16 _start[0x64c4233d76e0] Fatal: master: service(doveadm): child 2302469 killed with signal 6 (core dumped) *## API Schema (from GET /doveadm/v1)* The API endpoint reports the following schema for authCacheFlush: json { "command": "authCacheFlush", "parameters": [ {"name": "socketPath", "type": "string"}, {"name": "user", "type": "array"} ] } *## Analysis* The API schema declares user as array, but line 120 in doveadm-cmd-parse.c calls doveadm_cmd_param_str() which asserts param->type == CMD_PARAM_STR. This type mismatch causes the crash. The relevant assertion in source code: c // doveadm-cmd-parse.c:120 assertion failed: (param->type == CMD_PARAM_STR) *## Note* - The CLI command doveadm auth cache flush <user> works correctly - Only the HTTP API is affected - All authentication methods (X-Dovecot-API header, Basic Auth) produce the same crash - The crash occurs regardless of whether parameters are provided or not *## Workaround* Currently no workaround via HTTP API. Must use CLI directly or via SSH. *## Environment* - OS: Linux (Ubuntu/Debian) - Dovecot: 2.4.2 - doveadm HTTP API enabled on port 8080 ## Title authCacheFlush HTTP API crashes with assertion failure - type mismatch between API schema and implementation ## Dovecot Version 2.4.2 ## Component doveadm HTTP API ## Description The authCacheFlush command via doveadm HTTP API causes a server crash with an assertion failure. The HTTP API schema declares the user parameter as array type, but the internal implementation (doveadm_cmd_param_str) expects string type, causing a type mismatch assertion failure. ## Steps to Reproduce 1. Send any authCacheFlush request to doveadm HTTP API: bash curl -X POST \ -H "Authorization: X-Dovecot-API <api_key>" \ -H "Content-Type: application/json" \ -d '[["authCacheFlush",{"user":"[1]username(a)domain.com"},"tag1"]]' \ [2]http://localhost:8080/doveadm/v1 2. Or with user as array (matching the declared schema): bash curl -X POST \ -H "Authorization: X-Dovecot-API <api_key>" \ -H "Content-Type: application/json" \ -d '[["authCacheFlush",{"user":["[3]username(a)domain.com"]},"tag1"]]' \ [4]http://localhost:8080/doveadm/v1 3. Or without any parameters: bash curl -X POST \ -H "Authorization: X-Dovecot-API <api_key>" \ -H "Content-Type: application/json" \ -d '[["authCacheFlush",{},"tag1"]]' \ [5]http://localhost:8080/doveadm/v1 ## Expected Result Auth cache should be flushed and API returns success response like: json [["doveadmResponse",[{"entries":1}],"tag1"]] ## Actual Result Server crashes with empty reply (HTTP connection closed). The doveadm process is killed with signal 6 (SIGABRT). ## Error Log Panic: file doveadm-cmd-parse.c: line 120 (doveadm_cmd_param_str): assertion failed: (param->type == CMD_PARAM_STR) Error: Raw backtrace: #0 test_subprocess_fork[0x7362eb54a570] -> #1 backtrace_append[0x7362eb54a820] -> #2 backtrace_get[0x7362eb54a9c0] -> #3 e_info[0x7362eb556370] -> #4 i_syslog_fatal_handler[0x7362eb5564b0] -> #5 i_panic[0x7362eb474f28] -> #6 [unw_get_proc_name() failed: -10] -> #7 http_server_connection_shut_down[0x7362eb4e6a00] -> #8 io_loop_call_io[0x7362eb572510] -> #9 io_loop_handler_run_internal[0x7362eb5743a0] -> #10 io_loop_handler_run[0x7362eb574540] -> #11 io_loop_run[0x7362eb574740] -> #12 master_service_run[0x7362eb4bc640] -> #13 main[0x64c4233d74f0] -> #14 __libc_init_first[0x7362eb02a150] -> #15 __libc_start_main[0x7362eb02a200] -> #16 _start[0x64c4233d76e0] Fatal: master: service(doveadm): child 2302469 killed with signal 6 (core dumped) ## API Schema (from GET /doveadm/v1) The API endpoint reports the following schema for authCacheFlush: json { "command": "authCacheFlush", "parameters": [ {"name": "socketPath", "type": "string"}, {"name": "user", "type": "array"} ] } ## Analysis The API schema declares user as array, but line 120 in doveadm-cmd-parse.c calls doveadm_cmd_param_str() which asserts param->type == CMD_PARAM_STR. This type mismatch causes the crash. The relevant assertion in source code: c // doveadm-cmd-parse.c:120 assertion failed: (param->type == CMD_PARAM_STR) ## Note - The CLI command doveadm auth cache flush <user> works correctly - Only the HTTP API is affected - All authentication methods (X-Dovecot-API header, Basic Auth) produce the same crash - The crash occurs regardless of whether parameters are provided or not ## Workaround Currently no workaround via HTTP API. Must use CLI directly or via SSH. ## Environment - OS: Linux (Ubuntu/Debian) - Dovecot: 2.4.2 - doveadm HTTP API enabled on port 8080 References Visible links 1. mailto:username@domain.com 2. http://localhost:8080/doveadm/v1 3. mailto:username@domain.com 4. http://localhost:8080/doveadm/v1 5. http://localhost:8080/doveadm/v1

2 1

mTLS ldap auth failure against openldap + TLSVerifyClient: demand
by Patrick Laimbock 15 Dec '25

15 Dec '25

Hi, I'm trying to setup up a Dovecot/Postfix/OpenLDAP combo on a Fedora 43 aarch64 box with the following versions: dovecot-2.4.2 from https://src.fedoraproject.org/rpms/dovecot/tree/rawhide and rebuilt for F43 at https://copr.fedorainfracloud.org/coprs/patrickl/dovecot/ postfix-3.10.3 openldap-2.6.10 openssl-3.5.4 Problem: I can't seem to make Dovecot (lmtp) establish a mTLS connection with the slapd server. Postfix works fine when using /etc/postfix/ldap-aliases.cf etc to get info from the slapd server which demands that the client sends a certificate due to olcTLSVerifyClient: demand. This is with a self-signed CA, intermediate CA and client & server certificates. Dovecot journalctl error: lmtp(92847): Error: lmtp-server: conn unix:pid=92846,uid=89 [1]: rcpt patrick@<domain>: Failed to lookup user patrick@<domain>: Internal error occurred. Refer to server log for more information. # doveadm log errors Dec 15 22:35:41.655525 Error: auth: ldap(ldaps://<FQDN>:636): Connection lost to LDAP server, reconnecting <snipped many more of the same message> Slapd error: TLS trace: SSL_accept:before SSL initialization <snip> TLS trace: SSL_accept:TLSv1.3 early data TLS trace: SSL_accept:error in TLSv1.3 early data TLS trace: SSL_accept:TLSv1.3 early data TLS trace: SSL3 alert write:fatal:unknown TLS trace: SSL_accept:error in error TLS: can't accept: error:0A0000C7:SSL routines::peer did not return a certificate. TLS accept failure error=-1 id=1178, closing conn=1178 fd=15 closed (TLS negotiation failure) It seems that Dovecot does not send its client certificate to the slapd server when asked? Perhaps due to a config error? Example with postfix where the client cert is sent and mTLS succeeds: # postmap -q info@<domain> ldap:/etc/postfix/ldap-aliases.cf TLS trace: SSL_accept:before SSL initialization TLS trace: SSL_accept:before SSL initialization SSL_accept:SSLv3/TLS read SSL_accept:TLSv1.3 early data TLS trace: SSL_accept:error in TLSv1.3 early data TLS trace: SSL_accept:TLSv1.3 early data TLS certificate verification: depth: 2, err: 0, subject: /C=ZZ/ST=FooBar/O=Example/OU=IT/CN=ExampleCA issuer: /C=ZZ/ST=FooBar/O=Example/OU=IT/CN=ExampleCA TLS certificate verification: depth: 1, err: 0, subject: /C=ZZ/ST=FooBar/O=Example/OU=IT/CN=ExampleSubCA, issuer: /C=ZZ/ST=FooBar/O=Example/OU=IT/CN=ExampleCA TLS certificate verification: depth: 0, err: 0, subject: /CN=postfix-ldap, issuer: /C=ZZ/ST=FooBar/O=Example/OU=IT/CN=ExampleSubCA TLS trace: SSL_accept:TLSv1.3 read client compressed certificate TLS trace: SSL_accept:SSLv3/TLS read certificate verify TLS trace: SSL_accept:SSLv3/TLS read finished TLS trace: SSL_accept:SSLv3/TLS write session ticket TLS trace: SSL_accept:SSLv3/TLS write session ticket conn=1000 fd=13 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384 Dovecot config # dovecot -n: # 2.4.2 (0962ed2104): /etc/dovecot/dovecot.conf # Pigeonhole version 2.4.2 (767418c3) # OS: Linux 6.17.11-300.fc43.aarch64 aarch64 Fedora release 43 (Forty Three) # Hostname: <FQDN> # 5 default setting changes since version 2.4.1 dovecot_config_version = 2.4.1 auth_mechanisms = plain dovecot_storage_version = 2.4.1 first_valid_uid = 1000 ldap_auth_dn = cn=dovecot,dc=hosted,dc=ldap ldap_auth_dn_password = # hidden, use -P to show it ldap_uris = ldaps://<FQDN> log_debug = category=ssl mail_driver = sdbox mail_gid = vmail mail_home = /var/mail/virtual/%{user | domain}/%{user | username} mail_path = ~/mail mail_uid = vmail protocols { imap = yes lmtp = yes } ssl = required ssl_cipher_list = PROFILE=SYSTEM ssl_cipher_suites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 ssl_min_protocol = TLSv1.3 namespace inbox { inbox = yes separator = / } ssl_server { ca_file = /etc/pki/dovecot/certs/dovecot_ca_bundle.pem cert_file = /etc/pki/dovecot/certs/kronos.laimbock.nl.crt key_file = /etc/pki/dovecot/private/kronos.laimbock.nl_nopass.key.crt prefer_ciphers = server request_client_cert = yes require_crl = no } ssl_client { ca_file = /etc/pki/dovecot/certs/dovecot_ca_bundle.pem cert_file = /etc/pki/dovecot/certs/dovecot-ldap.crt key_file = /etc/pki/dovecot/private/dovecot-ldap_nopass.key.crt require_valid_cert = yes } protocol !smtp { auth_ssl_require_client_cert = yes } passdb ldap { ldap_base = ou=People,ou=%{ user | domain },dc=hosted,dc=ldap default_password_scheme = CRYPT fields { user = %{ldap:mail} } bind = yes filter = (&(objectClass=person)(mail=%{user})) } userdb ldap { ldap_base = ou=People,ou=%{ user | domain },dc=hosted,dc=ldap fields { user = %{ldap:mail} } filter = (&(objectClass=person)(uid=%{user})) } service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } } The dovecot_ca_bundle.pem is created with # cat subca.crt ca.crt > dovecot_ca_bundle.pem The RootCA is imported into the trust store via: # cp ca.crt /etc/pki/ca-trust/source/anchors/ # update-ca-trust extract The public certificates live in /etc/pki/dovecot/certs: lrwxrwxrwx. 1 root root 16 Dec 15 15:49 1c2dd8a4.0 -> dovecot-ldap.crt lrwxrwxrwx. 1 root root 22 Dec 15 15:49 8dafd16f.0 -> <FQDN>.crt lrwxrwxrwx. 1 root root 9 Dec 15 20:15 d18284cf.0 -> subca.crt -rw-r--r--. 1 root root 773 Dec 12 21:21 dhparam -rw-r--r--. 1 root root 3456 Dec 15 21:34 dovecot_ca_bundle.pem -rw-r--r--. 1 root root 1586 Dec 15 20:15 dovecot-ldap.crt -rw-r--r--. 1 root root 1655 Dec 15 20:15 <FQDN>.crt -rw-r--r--. 1 root root 1850 Dec 15 20:15 subca.crt The private keys live in /etc/pki/dovecot/private: -rw-------. 1 root root 1704 Dec 15 20:15 dovecot-ldap_nopass.key.crt -rw-------. 1 root root 1704 Dec 15 20:15 <FQDN>_nopass.key.crt SELinux: there are no AVCs in /var/log/audit/audit.log but to make sure I ran: # restorecon -v -F -R /etc/dovecot # restorecon -v -F -R /etc/pki/doveecot With setenforce 0 no change in results. The slapd config: dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /run/openldap/slapd.args olcPidFile: /run/openldap/slapd.pid olcPasswordCryptSaltFormat: $6$%s olcLogLevel: 1023 # cat subca.crt ca.crt > slapd_ca_bundle.pem olcTLSCACertificateFile: /etc/openldap/certs/slapd_ca_bundle.pem olcTLSCertificateFile: /etc/openldap/certs/<FQDN>.crt olcTLSCertificateKeyFile: /etc/openldap/certs/<FQDN>_nopass.key.crt olcTLSCipherSuite: TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 olcTLSVerifyClient: demand olcTLSCRLCheck: none I would appreciate any hints what I missed, what to read, where to look, etc If you need more info I'll be happy to provide. Thanks! Cheers, Patrick

1 0

mTLS ldap auth failure against openldap + TLSVerifyClient: demand
by Patrick Laimbock 15 Dec '25

15 Dec '25

Hi, I'm trying to setup up a Dovecot/Postfix/OpenLDAP combo on a Fedora 43 aarch64 box with the following versions: dovecot-2.4.2 from https://src.fedoraproject.org/rpms/dovecot/tree/rawhide and rebuilt for F43 at https://copr.fedorainfracloud.org/coprs/patrickl/dovecot/ postfix-3.10.3 openldap-2.6.10 openssl-3.5.4 Problem: I can't seem to make Dovecot (lmtp) establish a mTLS connection with the slapd server. Postfix works fine when using /etc/postfix/ldap-aliases.cf etc to get info from the slapd server which demands that the client sends a certificate due to olcTLSVerifyClient: demand. This is with a self-signed CA, intermediate CA and client & server certificates. Dovecot journalctl error: lmtp(92847): Error: lmtp-server: conn unix:pid=92846,uid=89 [1]: rcpt patrick@<domain>: Failed to lookup user patrick@<domain>: Internal error occurred. Refer to server log for more information. # doveadm log errors Dec 15 22:35:41.655525 Error: auth: ldap(ldaps://<FQDN>:636): Connection lost to LDAP server, reconnecting <snipped many more of the same message> Slapd error: TLS trace: SSL_accept:before SSL initialization <snip> TLS trace: SSL_accept:TLSv1.3 early data TLS trace: SSL_accept:error in TLSv1.3 early data TLS trace: SSL_accept:TLSv1.3 early data TLS trace: SSL3 alert write:fatal:unknown TLS trace: SSL_accept:error in error TLS: can't accept: error:0A0000C7:SSL routines::peer did not return a certificate. TLS accept failure error=-1 id=1178, closing conn=1178 fd=15 closed (TLS negotiation failure) It seems that Dovecot does not send its client certificate to the slapd server when asked? Config error? Example with postfix where this succeeds: # postmap -q info@<domain> ldap:/etc/postfix/ldap-aliases.cf TLS trace: SSL_accept:before SSL initialization TLS trace: SSL_accept:before SSL initialization SSL_accept:SSLv3/TLS read SSL_accept:TLSv1.3 early data TLS trace: SSL_accept:error in TLSv1.3 early data TLS trace: SSL_accept:TLSv1.3 early data TLS certificate verification: depth: 2, err: 0, subject: /C=ZZ/ST=FooBar/O=Example/OU=IT/CN=ExampleCA issuer: /C=ZZ/ST=FooBar/O=Example/OU=IT/CN=ExampleCA TLS certificate verification: depth: 1, err: 0, subject: /C=ZZ/ST=FooBar/O=Example/OU=IT/CN=ExampleSubCA, issuer: /C=ZZ/ST=FooBar/O=Example/OU=IT/CN=ExampleCA TLS certificate verification: depth: 0, err: 0, subject: /CN=postfix-ldap, issuer: /C=ZZ/ST=FooBar/O=Example/OU=IT/CN=ExampleSubCA TLS trace: SSL_accept:TLSv1.3 read client compressed certificate TLS trace: SSL_accept:SSLv3/TLS read certificate verify TLS trace: SSL_accept:SSLv3/TLS read finished TLS trace: SSL_accept:SSLv3/TLS write session ticket TLS trace: SSL_accept:SSLv3/TLS write session ticket conn=1000 fd=13 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384 Dovecot config # dovecot -n: # 2.4.2 (0962ed2104): /etc/dovecot/dovecot.conf # Pigeonhole version 2.4.2 (767418c3) # OS: Linux 6.17.11-300.fc43.aarch64 aarch64 Fedora release 43 (Forty Three) # Hostname: <FQDN> # 5 default setting changes since version 2.4.1 dovecot_config_version = 2.4.1 auth_mechanisms = plain dovecot_storage_version = 2.4.1 first_valid_uid = 1000 ldap_auth_dn = cn=dovecot,dc=hosted,dc=ldap ldap_auth_dn_password = # hidden, use -P to show it ldap_uris = ldaps://<FQDN> log_debug = category=ssl mail_driver = sdbox mail_gid = vmail mail_home = /var/mail/virtual/%{user | domain}/%{user | username} mail_path = ~/mail mail_uid = vmail protocols { imap = yes lmtp = yes } ssl = required ssl_cipher_list = PROFILE=SYSTEM ssl_cipher_suites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 ssl_min_protocol = TLSv1.3 namespace inbox { inbox = yes separator = / } ssl_server { ca_file = /etc/pki/dovecot/certs/dovecot_ca_bundle.pem cert_file = /etc/pki/dovecot/certs/kronos.laimbock.nl.crt key_file = /etc/pki/dovecot/private/kronos.laimbock.nl_nopass.key.crt prefer_ciphers = server request_client_cert = yes require_crl = no } ssl_client { ca_file = /etc/pki/dovecot/certs/dovecot_ca_bundle.pem cert_file = /etc/pki/dovecot/certs/dovecot-ldap.crt key_file = /etc/pki/dovecot/private/dovecot-ldap_nopass.key.crt require_valid_cert = yes } protocol !smtp { auth_ssl_require_client_cert = yes } passdb ldap { ldap_base = ou=People,ou=%{ user | domain },dc=hosted,dc=ldap default_password_scheme = CRYPT fields { user = %{ldap:mail} } bind = yes filter = (&(objectClass=person)(mail=%{user})) } userdb ldap { ldap_base = ou=People,ou=%{ user | domain },dc=hosted,dc=ldap fields { user = %{ldap:mail} } filter = (&(objectClass=person)(uid=%{user})) } service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } } The dovecot_ca_bundle.pem is created with # cat subca.crt ca.crt > dovecot_ca_bundle.pem The RootCA is imported into the trust store via: # cp ca.crt /etc/pki/ca-trust/source/anchors/ # update-ca-trust extract The public certificates live in /etc/pki/dovecot/certs: lrwxrwxrwx. 1 root root 16 Dec 15 15:49 1c2dd8a4.0 -> dovecot-ldap.crt lrwxrwxrwx. 1 root root 22 Dec 15 15:49 8dafd16f.0 -> <FQDN>.crt lrwxrwxrwx. 1 root root 9 Dec 15 20:15 d18284cf.0 -> subca.crt -rw-r--r--. 1 root root 773 Dec 12 21:21 dhparam -rw-r--r--. 1 root root 3456 Dec 15 21:34 dovecot_ca_bundle.pem -rw-r--r--. 1 root root 1586 Dec 15 20:15 dovecot-ldap.crt -rw-r--r--. 1 root root 1655 Dec 15 20:15 <FQDN>.crt -rw-r--r--. 1 root root 1850 Dec 15 20:15 subca.crt The private keys live in /etc/pki/dovecot/private: -rw-------. 1 root root 1704 Dec 15 20:15 dovecot-ldap_nopass.key.crt -rw-------. 1 root root 1704 Dec 15 20:15 <FQDN>_nopass.key.crt SELinux: there are no AVCs in /var/log/audit/audit.log but to make sure I ran: # restorecon -v -F -R /etc/dovecot # restorecon -v -F -R /etc/pki/doveecot With setenforce 0 no change in results. The slapd config: dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /run/openldap/slapd.args olcPidFile: /run/openldap/slapd.pid olcPasswordCryptSaltFormat: $6$%s olcLogLevel: 1023 # cat subca.crt ca.crt > slapd_ca_bundle.pem olcTLSCACertificateFile: /etc/openldap/certs/slapd_ca_bundle.pem olcTLSCertificateFile: /etc/openldap/certs/<FQDN>.crt olcTLSCertificateKeyFile: /etc/openldap/certs/<FQDN>_nopass.key.crt olcTLSCipherSuite: TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 olcTLSVerifyClient: demand olcTLSCRLCheck: none I would appreciate any hints what I missed, what to read, where to look, etc If you need more info I'll be happy to provide. Thanks! Cheers, Patrick

1 0

Why doesn't Dovecot documentation specify which files to edit?
by n4ch0 13 Dec '25

13 Dec '25

I've noticed that the official Dovecot documentation frequently omits crucial information about which specific files should be modified when configuring different functionalities. Concrete examples: In the LMTP integration guide with Postfix (https://doc.dovecot.org/2.4.2/howto/lmtp/postfix.html#postfix-and-dovecot-l…) It indicates to modify the socket configuration, but doesn't specify in which file this modification should be made In the quota plugin documentation (https://doc.dovecot.org/2.4.2/core/plugins/quota.html#quota-plugin-quota) It requests enabling the quota module, but doesn't mention the corresponding configuration file I managed to achieve the configuration I wanted but it took more time than it should have. My question: I understand that Dovecot uses a modular configuration system and that technically I can place directives in any file. However, wouldn't it be clearer and more efficient if the documentation followed an established order and specified recommended locations? For example: "Edit /etc/dovecot/conf.d/10-master.conf to configure the LMTP socket" "Enable the quota plugin in /etc/dovecot/conf.d/10-mail.conf" Is there a technical reason why the documentation deliberately avoids recommending specific files, or does it simply assume that users already know these conventions? Is there a general guide about Dovecot's configuration file structure and best practices for organizing them? Thanks!

5 6

Dovecot crash after waking up from sleep
by Peter Psenak 13 Dec '25

13 Dec '25

Hi, I'm experiencing a dovecot crash every time my PC wakes up from sleep. Is this a know issues? # 2.4.0 (daeb6bc59c): /opt/homebrew/etc/dovecot/dovecot.conf # Pigeonhole version 2.4.0 (1b2d5bb9) # OS: Darwin 25.1.0 arm64 File system: APFS Dec 11 22:24:20 master: Panic: file ./time-util.h: line 40 (timeval_add_usecs): assertion failed: (usecs >= 0) Dec 11 22:24:20 master: Error: Raw backtrace: 0 libdovecot.0.dylib 0x0000000102dc35f4 backtrace_append + 72 -> 1 libdovecot.0.dylib 0x0000000102dc3738 backtrace_get + 44 -> 2 libdovecot.0.dylib 0x0000000102dd0b64 default_fatal_finish + 72 -> 3 libdovecot.0.dylib 0x0000000102dcf614 default_error_handler + 0 -> 4 libdovecot.0.dylib 0x0000000102dcf5e0 fatal_handler_real + 0 -> 5 dovecot 0x0000000102b1a8fc master_fatal_callback + 248 -> 6 libdovecot.0.dylib 0x0000000102dcf794 i_fatal + 0 -> 7 libdovecot.0.dylib 0x0000000102e24ce0 event_callback.cold.1 + 0 -> 8 libdovecot.0.dylib 0x0000000102de61c4 io_loops_timeouts_update + 308 -> 9 \libdovecot.0.dylib 0x0000000102e24668 io_loop_handle_timeouts.cold.1 + 20 -> 10 libdovecot.0.dylib 0x0000000102de49b8 io_loop_handle_timeouts + 560 -> 11 libdovecot.0.dylib 0x0000000102de6e64 io_loop_handler_run_internal + 388 -> 12 libdovecot.0.dylib 0x0000000102de4f00 io_loop_handler_run + 220 -> 13 libdovecot.0.dylib 0x0000000102de4e04 io_loop_run + 88 -> 14 libdovecot.0.dylib 0x0000000102d4ec3c master_service_run + 28 -> 15 dovecot 0x0000000102b1a224 main + 2944 -> 16 dyld 0x000000019ff4dd54 start + 7184 thanks, Peter

2 1

Re: Why doesn't Dovecot documentation specify which files to edit?
by Michael Slusarz 11 Dec '25

11 Dec '25

See, e.g., https://doc.dovecot.org/2.4.2/core/config/quick.html#tldr-i-just-want-dovec… michael > On 12/11/2025 3:29 PM MST Chad Wallace via dovecot <dovecot(a)dovecot.org> wrote: > > > I think the configuration layout you're seeing may be provided by your > distribution (Debian, RedHat, etc.). In the original release provided > by Dovecot, I only see a single config file: dovecont.conf.in > > Also, it is quite easy to find which file has certain types of > configuration: > > $ grep -ri lmtp /etc/dovecot > > > On Thu, 11 Dec 2025 20:47:44 +0000 > n4ch0 via dovecot <dovecot(a)dovecot.org> wrote: > > > I've noticed that the official Dovecot documentation frequently omits > > crucial information about which specific files should be modified > > when configuring different functionalities. Concrete examples: > > > > In the LMTP integration guide with Postfix > > (https://doc.dovecot.org/2.4.2/howto/lmtp/postfix.html#postfix-and-dovecot-l…) > > > > It indicates to modify the socket configuration, but doesn't specify > > in which file this modification should be made > > > > > > In the quota plugin documentation > > (https://doc.dovecot.org/2.4.2/core/plugins/quota.html#quota-plugin-quota) > > > > It requests enabling the quota module, but doesn't mention the > > corresponding configuration file > > > > > > > > I managed to achieve the configuration I wanted but it took more time > > than it should have. My question: I understand that Dovecot uses a > > modular configuration system and that technically I can place > > directives in any file. However, wouldn't it be clearer and more > > efficient if the documentation followed an established order and > > specified recommended locations? For example: > > > > "Edit /etc/dovecot/conf.d/10-master.conf to configure the LMTP socket" > > "Enable the quota plugin in /etc/dovecot/conf.d/10-mail.conf" > > > > Is there a technical reason why the documentation deliberately avoids > > recommending specific files, or does it simply assume that users > > already know these conventions? Is there a general guide about > > Dovecot's configuration file structure and best practices for > > organizing them? > > > > Thanks! > > _______________________________________________ > > dovecot mailing list -- dovecot(a)dovecot.org > > To unsubscribe send an email to dovecot-leave(a)dovecot.org > > > > -- > Chad Wallace > Software Developer | The Lodging Company® > P: +1 250 869 4931 ext. 251 > TF: +1 888 676 9977 > E: cwallace(a)lodgingcompany.com > W: www.lodgingcompany.com > _______________________________________________ > dovecot mailing list -- dovecot(a)dovecot.org > To unsubscribe send an email to dovecot-leave(a)dovecot.org

1 0

About mail_inbox_path and mail location
by Aki Tuomi 10 Dec '25

10 Dec '25

Hi! We've been noticing that many people are configuring mail_inbox_path. I assume that for most people this is because debian decided to include it in their default config, so that it would use /var/mail boxes for user INBOXes. If your inbox *does not* reside in some weird location, you should *not* set this setting to any value, instead you can either ensure it's commented out, or set to empty value. IN PARTICULAR, IT IS **NOT** REQUIRED SETTING. Setting it to some random weird value like '.' will just cause Problems, setting it to $MAIL_HOME/ or something else will just be either pointless or cause problems. Some most common conversions (please adjust to your environment) mail_home= /home/vmail/%u => mail_home = /home/vmail/%{user} mail_home = /home/vmail/%d/%u => mail_home = /home/vmail/%{user|domain}/%{user|username} or some variant of this. mail_location = maildir:~/ => mail_path = ~/ mail_driver = maildir mail_location = maildir:/var/srv/foo/%d/%u => mail_path = /var/srv/foo/%{user|domain}/%{user|username} mail_driver = maildir In addition you might want to convert INDEX=~/.index => mail_index_path=~/.index CONTROL=~/.control => mail_control_path=~/.control LAYOUT=fs => mailbox_list_layout=fs A minimal working config is mail_home=/home/vmail/%{user} mail_driver=maildir mail_path=~/maildir mail_uid=vmail mail_gid=vmail ## If you have settings like namespace other { location = maildir:/foo/bar } this converts into namespace other { mail_path = /foo/bar # optional, if this is matches your top level mail_driver = maildir } Hope this clears out some of the confusion. Aki

2 1

Migration of the Maildir standard from Dovecot 2.3 to Dovecot 2.4
by byteme＠linuxmaker.net 10 Dec '25

10 Dec '25

Hello everyone, I have a Dovecot 2.3 installation on a Debian 12 Linux system that is being upgraded to Dovecot 2.4. The server hosts many domains with numerous email accounts. Users had created folder structures containing many received and sent emails, following the Maildir standard as "dot-prefixed folders." When switching to Dovecot 2.4, all these emails and folders are no longer visible. This is what it looks like on the old system: root@mx1 /var/vmail/example.com/systemmails # ll -a insgesamt 256 drwx------ 14 vmail vmail 4096 3. Nov 09:15 . drwx------ 15 vmail vmail 4096 6. Apr 2021 .. drwx------ 5 vmail vmail 4096 3. Nov 09:15 .Archive drwx------ 2 vmail vmail 86016 27. Okt 12:19 cur -rw------- 1 vmail vmail 0 15. Sep 2018 dovecot-acl-list -rw------- 1 vmail vmail 1080 29. Okt 06:50 dovecot.index -rw------- 1 vmail vmail 23400 30. Okt 01:36 dovecot.index.cache -rw------- 1 vmail vmail 10600 30. Okt 01:41 dovecot.index.log -rw------- 1 vmail vmail 6627 26. Aug 09:56 dovecot.index.thread -rw------- 1 vmail vmail 24 20. Apr 2024 dovecot-keywords -rw------- 1 vmail vmail 1256 3. Nov 09:05 dovecot.list.index -rw------- 1 vmail vmail 5156 3. Nov 09:15 dovecot.list.index.log -rw------- 1 vmail vmail 672 15. Jul 16:45 dovecot.mailbox.log -rw------- 1 vmail vmail 1781 30. Okt 01:36 dovecot-uidlist -rw------- 1 vmail vmail 8 15. Jul 16:45 dovecot-uidvalidity -r--r--r-- 1 vmail 1002 0 15. Sep 2018 dovecot-uidvalidity.5b9d20a3 -r--r--r-- 1 vmail vmail 0 15. Sep 2018 dovecot-uidvalidity.5b9d20a5 drwx------ 5 vmail vmail 4096 3. Nov 09:15 .Drafts drwx------ 5 vmail vmail 4096 3. Nov 09:15 .INBOX.Fail2ban drwx------ 5 vmail vmail 4096 3. Nov 09:15 .INBOX.vzdump drwx------ 5 vmail vmail 4096 3. Nov 09:15 .Junk drwx------ 2 vmail vmail 36864 30. Okt 01:36 new drwx------ 5 vmail vmail 4096 3. Nov 09:15 .Quarantine drwx------ 5 vmail vmail 4096 3. Nov 09:15 .Sent drwx------ 3 vmail vmail 4096 3. Dez 06:25 sieve -rw------- 1 vmail vmail 70 15. Jul 16:45 subscriptions drwx------ 2 vmail vmail 4096 2. Nov 16:41 tmp drwx------ 5 vmail vmail 4096 3. Nov 09:15 .Trash This should be preserved so that users don't notice the system upgrade. Dovecot 2.4 works quite differently in this regard. What solution is there for migrating both the namespace and the existing emails to Dovecot 2.4? Thank you for your suggestions ByteMe

5 21