- dovecot - dovecot.org

About mail_inbox_path and mail location
by Aki Tuomi 06 Feb '26

06 Feb '26

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

3 4

Error: ldap: auth_passdb_post settings
by Ruud Baart 06 Feb '26

06 Feb '26

Dovecot 2.4.1 works fine on my Debian Trixie server. I use LDAP as backend for the users. I don't have problems. Authentication works fine. However logging show every time the following line: auth-worker(<user name@domain,::1)<109040><3v5ddOlJvrgAAAAAAAAAAAAAAAAAAAAB>: request [7]: Error: ldap: auth_passdb_post settings: Failed to parse configuration: Failed to expand passdb_fields/password setting variables: ldap: No such attribute 'userpassword' The LDAP authentication works correct. So I don't understand this message. My correct working LDAP configuration in auth-ldap.conf.ext: passdb ldap { passdb_use_worker = yes passdb_ldap_filter = (&(objectClass=PromptMailUser)(accountStatus=TRUE)(mailDeliveryaddress=%{user})) ldap_bind = yes fields { user = %{ldap:mailDeliveryaddress} password = %{ldap:userPassword} } } userdb ldap { userdb_use_worker = yes userdb_ldap_filter = (&(objectClass=PromptMailUser)(accountStatus=TRUE)(mailDeliveryaddress=%{user})) fields { home = %{ldap:mailBase} mail = %{ldap:mailMessageStore} mail_path = %{ldap:mailMessageStore} quota_storage_size = %{ldap:dovecotQuota} } }

5 20

Pigeonhole 2.4.2 build failure: cannot find -ldovecot-ldap even without LDAP support
by adesh＠backuply.com 04 Feb '26

04 Feb '26

I'm building Pigeonhole 2.4.2 (fresh tarball from https://pigeonhole.dovecot.org/releases/2.4/dovecot-pigeonhole-2.4.2.tar.gz) against Dovecot 2.4.2 compiled without LDAP support (--without-ldap during Dovecot configure, no libdovecot-ldap.so present). The build fails at linking libdovecot-sieve.la: > > CC ext-fileinto.lo > CC ext-reject.lo > ... > CC sieve.lo > CCLD libdovecot-sieve.la > /opt/rh/devtoolset-11/root/usr/libexec/gcc/x86_64-redhat-linux/11/ld: cannot find -ldovecot-ldap > collect2: error: ld returned 1 exit status > make[4]: *** [Makefile:757: libdovecot-sieve.la] Error 1 NEWS confirms the fix is included: - sieve-ldap-storage: Fix compile without LDAP. Steps tried: make distclean && ./configure --with-dovecot=/usr/local/apps/dovecot --with-ldap=no Confirmed no openldap-devel influencing detection (or temporarily removed) Fresh source extract, no prior build artifacts Configure output shows LDAP as disabled (or paste relevant lines if different). Is there an additional flag needed, or is this a regression/edge case in 2.4.2? Any patch or workaround would be appreciated. System: RHEL-like (devtoolset-11/gcc 11), Dovecot prefix /usr/local/apps/dovecot.

1 0

How to let postfix use dovecot to check quotas for virtual aliases
by jerome＠jolimont.fr 04 Feb '26

04 Feb '26

Hi all. Receiving an email for an alias, I got those errors: <alias(a)domain.tld>Recipient address rejected: Unknown user; I realized this happened when postfix queries dovecot about user quota. Basically, what happens is that postfix queries dovecot using the virutal alias as name, not the virtual user. And since dovecot doesn't find a user under that name, it returns an error and postfix rejects the mail. ### Configuration I followed the docs at https://doc.dovecot.org/latest/core/plugins/quota.html when setting up the server. /etc/postfix/main.cf ``` smtpd_recipient_restrictions = check_policy_service unix:private/quota-status ``` /etc/dovecot/conf.d/90-quota.conf ``` service quota-status { executable = quota-status -p postfix unix_listener /var/spool/postfix/private/quota-status { user = postfix } client_limit = 1 } ``` /etc/dovecot/conf.d/auth-sql.conf.ext ``` userdb sql { query = SELECT '/var/mail/vmail/'||maildir AS home, 110 AS uid, 113 AS gid, quota || 'B' AS quota_storage_size FROM mailbox WHERE username = '%{user}' iterate_query = SELECT username FROM mailbox } ``` ### Solution 1: modify user query This issue was reported and analyzed here: https://dovecot.dovecot.narkive.com/FtjhqCuU/postfix-aliases-with-quota-sta… and there: https://github.com/docker-mailserver/docker-mailserver/issues/2091 A comment (https://dovecot.dovecot.narkive.com/FtjhqCuU/postfix-aliases-with-quota-sta…) suggests to modify the SQL query to also look for aliases. I modified my query like so: ``` query = SELECT '/var/mail/vmail/'||maildir AS home, 110 AS uid, 113 AS gid, quota || 'B' AS quota_storage_size FROM mailbox JOIN alias ON mailbox.username = alias.goto WHERE alias.address = '%{user}'; ``` and it seemed to work. I mean, I can query user quota with an alias: doveadm quota get -u alias(a)domain.tld but the iterate query ignores aliases so doveadm quota get -A only lists users, not aliases (which is what I want) and I can't IMAP login using aliases (which is also what I want) since I didn't modify the password query either. I find this configuration slightly inconsistent: the user query returns aliases, not the iterate query. Is the user query really meant to return aliases as well? Also, I realized this query is broken for alias to multiple addresses. I'd get the following error: Recipient address rejected: Unknown user Surprisingly, it seems to only affect messages from an external source to an alias pointing to an external mailbox. Messages submitted locally (and perhaps messages sent to an alias to local destinations only, I'm not sure) were not affected. ### Solution 2: ignore aliases, it will fail later anyway On another server, I had this configuration: /etc/dovecot/conf.d $ vi 90-quota.conf (Don't put this in `plugin` on dovecot 2.4+.) ``` plugin { quota_status_success = DUNNO quota_status_nouser = DUNNO quota_status_overquota = "552 5.2.2 Mailbox is full" } ``` The alias is unknown so the check returns DUNNO and postfix lets the message pass (postfix log read "delivered via spamassassin service") but then it fails at sieve stage when writing the message: sieve: msgid=<xxx>: failed to store into mailbox 'INBOX': Quota exceeded (mailbox for user is full) The result is what is expected: the message is rejected due to mailbox full. But I don't think it was intended to work this way. And since the message is quota-rejected at sieve stage, I could remove the `check_policy_service` line since it will be rejected for a virtual user (not alias) as well anyway. Right? ### Question What is the recommended configuration to let postfix use dovecot to check quotas for virtual aliases? I couldn't find documentation for this specific use case. Ideally, postfix would query using the resolved user, not the alias. Can this be achieved? Should I remove the check and rely on the fact that writing the message fails at a later step anyway? Thanks. (Question also posted on ServerFault: https://serverfault.com/questions/1197914/how-to-let-postfix-use-dovecot-to…)

3 3

Question about behavior I wound up patching 2.4 to fix
by Andy Baugh 03 Feb '26

03 Feb '26

Howdy, I had a complaint from RoundCube users that the maildir quotas weren't accurate when they logged in after something wound up deleting their maildirsize file on Dovecot 2.4. Since that does IMAP GETQUOTAROOT to fetch the info, I figured we're probably not triggering quota recalculation on maildir like we did on dovecot 2.3 (which doesn't seem to have this issue). Wound up writing a patch to src/plugins/imap-quota/imap-quota-plugin.c to add a hook into cmd_setquota which looks to see if imap_quota is enabled, and if so trigger maildir quota recalculation on IMAP login. This does work to solve the reported issue, but I'm ultimately more curious whether this could even be considered a regression, as per your own documentation for the quota plugin: > Once the maildirsize reaches 5120 bytes, the quota is recalculated and the file is recreated. This makes sure that if quota happens to be broken (e.g. externally deleted files) it won't stay that way forever. This suggests to me that the behavior I'm "fixing" a regression in is actually working "as designed." As such my question would be: Is there a good reason I *should not* be doing this? I would of course be happy to share this patch with the list, but I'm not going to bother if it's actually something the maintainers are not interested in due to it not being a good idea in the first place. Thanks, -- Thomas "Andy" Baugh | Software Development Engineer IV andy.baugh(a)webpros.com www.webpros.com

1 0

Panic: file imap-sieve-storage.c: line 216 (imap_sieve_add_mailbox_event): assertion failed: (ismt->src_box == NULL || ismt->src_box == src_box)
by Christian Kivalo 03 Feb '26

03 Feb '26

Reposting my reply from a few days ago to a thread with the same panic message. I found this in my logs when some mails that got deleted on the phone were still visible in roundcube. I currently have three users that trigger the panic. One user with an iPad accounts for nearly all of the panics. The problem shows when the account is accessed from android (thunderbird) or ipad. The same accounts show no problems when beeing used with roundcube or thunderbird on windows. I enabled core dumps on 2026-01-14 and have ~8500 core dumps of the imap binary until now. What causes this error and how can I fix it? In the logs all I see is the users login, then the panic. # doveconf -n # 2.4.2-2+debian13 (0962ed2104): /etc/dovecot/dovecot.conf # Pigeonhole version 2.4.2-2+debian13 (767418c3) # OS: Linux 6.12.0-custom.kvm x86_64 Debian 13.3 ext4 2026-01-13T21:44:32.317609+01:00 uschi dovecot: imap-login: Logged in: user=<user(a)example.com>, method=PLAIN, rip=<IP1>, lip=<IP2>, mpid=4194077, TLS, session=<cpkID0tId7dUc9rl> 2026-01-13T21:44:38.455379+01:00 uschi dovecot: imap(user(a)example.com)<4194077><cpkID0tId7dUc9rl>: Panic: file imap-sieve-storage.c: line 216 (imap_sieve_add_mailbox_event): assertion failed: (ismt->src_box == NULL || ismt->src_box == src_box) 2026-01-13T21:44:38.458755+01:00 uschi dovecot: imap(user(a)example.com)<4194077><cpkID0tId7dUc9rl>: Error: Raw backtrace: #1 [unw_get_proc_name() failed: -10] -> #2 [unw_get_proc_name() failed: -10] -> #3 i_panic[0x7f6b6c46c2f6] -> #4 [unw_get_proc_name() failed: -10] -> #5 [unw_get_proc_name() failed: -10] -> #6 [unw_get_proc_name() failed: -10] -> #7 mailbox_save_alloc[0x7f6b6ca103c0] -> #8 [unw_get_proc_name() failed: -10] -> #9 command_exec[0x55654e677400] -> #10 [unw_get_proc_name() failed: -10] -> #11 [unw_get_proc_name() failed: -10] -> #12 [unw_get_proc_name() failed: -10] -> #13 client_handle_input[0x55654e67ddc0] -> #14 client_continue_pending_input[0x55654e67e0b0] -> #15 io_loop_call_io[0x7f6b6c565490] -> #16 io_loop_handler_run_internal[0x7f6b6c567230] -> #17 io_loop_handler_run[0x7f6b6c5673c0] -> #18 io_loop_run[0x7f6b6c5675a0] -> #19 master_service_run[0x7f6b6c4b27f0] -> #20 main[0x55654e6688a0] -> #21 [unw_get_proc_name() failed: -10] -> #22 __libc_start_main[0x7f6b6c234ce0] -> #23 _start[0x55654e668eb0] 2026-01-13T21:44:38.459536+01:00 uschi dovecot: imap(user(a)example.com)<4194077><cpkID0tId7dUc9rl>: Fatal: master: service(imap): child 4194077 killed with signal 6 (core dumps disabled - https://dovecot.org/bugreport.html#coredumps) # coredumpctl dump PID: 1071230 (imap) UID: 5000 (vmail) GID: 5000 (vmail) Signal: 6 (ABRT) Timestamp: Fri 2026-01-16 19:17:15 CET (2s ago) Command Line: $'dovecot/imap [user(a)example.com <IP redacted> UID MOVE]' Executable: /usr/lib/dovecot/imap Control Group: /system.slice/dovecot.service Unit: dovecot.service Slice: system.slice Boot ID: 3668d179bda340229a780d5d43e426c3 Machine ID: 05698baa30ae984c9bd014566e16da18 Hostname: uschi Storage: /var/lib/systemd/coredump/core.imap.5000.3668d179bda340229a780d5d43e426c3.1071230.1768587435000000.zst (present) Size on Disk: 1.1M Message: Process 1071230 (imap) of user 5000 dumped core. Module libgcc_s.so.1 from deb gcc-14-14.2.0-19.amd64 Module libstdc++.so.6 from deb gcc-14-14.2.0-19.amd64 Module libzstd.so.1 from deb libzstd-1.5.7+dfsg-1.amd64 Stack trace of thread 1071230: #0 0x00007fbd1ca9f95c n/a (libc.so.6 + 0x9495c) #1 0x00007fbd1ca4acc2 raise (libc.so.6 + 0x3fcc2) #2 0x00007fbd1ca334ac abort (libc.so.6 + 0x284ac) #3 0x00007fbd1cc6caa0 n/a (libdovecot.so.0 + 0x6caa0) #4 0x00007fbd1cd49e67 n/a (libdovecot.so.0 + 0x149e67) #5 0x00007fbd1cc6c3d0 i_panic (libdovecot.so.0 + 0x6c3d0) #6 0x00007fbd1c42f942 n/a (lib95_imap_sieve_plugin.so + 0x4942) #7 0x00007fbd1c431223 n/a (lib95_imap_sieve_plugin.so + 0x6223) #8 0x00007fbd1d258f10 n/a (libdovecot-storage.so.0 + 0x11bf10) #9 0x00007fbd1d1a843b mailbox_save_alloc (libdovecot-storage.so.0 + 0x6b43b) #10 0x00005590b7ed4a69 n/a (n/a + 0x0) ELF object binary architecture: AMD x86-64 -- Christian Kivalo

4 11

Unexpected Configuration Error `Unknown setting: ssl_server_cert_file`
by David Weingut 02 Feb '26

02 Feb '26

Hello, I upgraded from Debian 12 to 13 and thereby also from dovecot 2.3 to 2.4. Now I am facing a weird error in dovecot. The actual error is the following # doveconf -n # 2.4.1-4 (7d8c0e5759): /etc/dovecot/dovecot.conf # Pigeonhole version 2.4.1-4 (0a86619f) doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-ssl.conf line 22: ssl_server_cert_file : Unknown setting: ssl_server_cert_file The corresponding entry in my config is ssl = yes ssl_server_cert_file = /etc/letsencrypt/live/example.com/fullchain.pem ssl_server_key_file = /etc/letsencrypt/live/example.com/privkey.pem I am sorry if I missed something in the archives but I did not find any similar posts. Is there something I am missing here and what would be further required to debug this? Best, David Hello, I upgraded from Debian 12 to 13 and thereby also from dovecot 2.3 to 2.4. Now I am facing a weird error in dovecot. The actual error is the following # doveconf -n # 2.4.1-4 (7d8c0e5759): /etc/dovecot/dovecot.conf # Pigeonhole version 2.4.1-4 (0a86619f) doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-ssl.conf line 22: ssl_server_cert_file : Unknown setting: ssl_server_cert_file The corresponding entry in my config is ssl = yes ssl_server_cert_file = /etc/letsencrypt/live/example.com/fullchain.pem ssl_server_key_file = /etc/letsencrypt/live/example.com/privkey.pem I am sorry if I missed something in the archives but I did not find any similar posts. Is there something I am missing here and what would be further required to debug this? Best, David

2 3

Compiling Dovecot 2.4 on OpenBSD
by Joel Mawhorter 02 Feb '26

02 Feb '26

I'm writing to see if anyone has had success compiling Dovecot 2.4 on OpenBSD. I can't seem to find any documentation that lists prerequisites. At the moment, the 2.4.2 source tarball from the Dovecot site does not seem to compile on my OpenBSD 7.8 system and the error message is not very helpful. I'm unsure if this is just a problem of some required package not being installed. If anyone could point me to info to help move forward, I would appreciate that. Joel

6 19

How can these MBOX files on a Dovecot-based IMAP server be converted to PST for access in Outlook?
by Rawnie Dolgato 31 Jan '26

31 Jan '26

MBOX files stored on a Dovecot-based IMAP server cannot be accessed directly in Microsoft Outlook, because Outlook does not support the MBOX file format. Outlook works with PST files, so a conversion step is mandatory. While it is technically possible to convert MBOX files to EML and then import them into Outlook, this approach is impractical for real-world scenarios. It is time-consuming, difficult to manage, and not suitable when handling bulk mailboxes or large datasets, which is typically the case with server-level backups. For this reason, an MBOX to PST conversion tool (such as BitRecover MBOX to PST Converter) is recommended. It supports bulk MBOX data, preserves folder structure and metadata, and allows selective migration based on criteria like date, sender, or subject. The process runs 100% offline, ensuring data security, and works on Windows, macOS, and Linux, making it suitable for both single and multi-mailbox migrations.

2 1

Meaning of auth-worker disconnected message and relation to LMTP 451 errors on Ubuntu
by Kim Haverblad 31 Jan '26

31 Jan '26

Hi dovecot list, I’m troubleshooting an LMTP delivery issue with Dovecot and would appreciate clarification on the meaning and impact of the following log message, which appears repeatedly during delivery attempts: auth-worker(2961): Debug: conn unix:auth-worker (pid=2948,uid=107): Disconnected: Connection closed (fd=-1) *Environment* * OS: Ubuntu (latest LTS, fully up to date) * Dovecot: distribution package (current version for Ubuntu) * MTA: Postfix * Delivery: LMTP to Dovecot * User database: MySQL (userdb lookup succeeds) * Mail storage: Maildir * Quotas: enabled via userdb (quota_rule) *Context* * LMTP accepts the recipient and completes userdb lookup successfully. * The mailbox path, uid, gid, and quota are correctly returned. * Postfix later receives a 451 4.3.0 Temporary internal error after the DATA phase. * The above auth-worker ... Disconnected: Connection closed (fd=-1)message appears around the same time. *Questions* 1. Is this Disconnected: Connection closed (fd=-1) message expected/normal behavior for auth-worker processes once a lookup is complete? 2. Under what circumstances would this indicate a real problem versus a harmless connection teardown? 3. Could this message itself contribute to, or explain, LMTP 451 4.3.0 Temporary internal error responses? 4. Are there specific auth-worker, LMTP, or debug settings recommended to determine whether this disconnect is abnormal? So far, authentication and userdb lookups appear clean, and there are no explicit permission or quota errors logged, which makes it unclear whether this message is relevant to the delivery failure or simply informational. Any clarification on how to interpret this log entry — and how to confirm whether it is benign or problematic — would be greatly appreciated. Kind Regards, Kim Hi dovecot list, I'm troubleshooting an LMTP delivery issue with Dovecot and would appreciate clarification on the meaning and impact of the following log message, which appears repeatedly during delivery attempts: auth-worker(2961): Debug: conn unix:auth-worker (pid=2948,uid=107): Disconnected: Connection closed (fd=-1) Environment o OS: Ubuntu (latest LTS, fully up to date) o Dovecot: distribution package (current version for Ubuntu) o MTA: Postfix o Delivery: LMTP to Dovecot o User database: MySQL (userdb lookup succeeds) o Mail storage: Maildir o Quotas: enabled via userdb (quota_rule) Context o LMTP accepts the recipient and completes userdb lookup successfully. o The mailbox path, uid, gid, and quota are correctly returned. o Postfix later receives a 451 4.3.0 Temporary internal error after the DATA phase. o The above auth-worker ... Disconnected: Connection closed (fd=-1) message appears around the same time. Questions 1. Is this Disconnected: Connection closed (fd=-1) message expected/normal behavior for auth-worker processes once a lookup is complete? 2. Under what circumstances would this indicate a real problem versus a harmless connection teardown? 3. Could this message itself contribute to, or explain, LMTP 451 4.3.0 Temporary internal error responses? 4. Are there specific auth-worker, LMTP, or debug settings recommended to determine whether this disconnect is abnormal? So far, authentication and userdb lookups appear clean, and there are no explicit permission or quota errors logged, which makes it unclear whether this message is relevant to the delivery failure or simply informational. Any clarification on how to interpret this log entry -- and how to confirm whether it is benign or problematic -- would be greatly appreciated. Kind Regards, Kim

2 4