August 2026 - dovecot

Config parser bug?
by Pat Suwalski 21 Aug '26

21 Aug '26

Hello, I recently upgraded my servers from Debian Bullseye to Trixie (2.3 -> 2.4). I have a pretty basic config, though I use Maildir instead of Debian's default of mbox. In the process of getting things working correctly for the new config format, I believe I have stumbled on a bug. To make the inbox work correctly, I need the mail_inbox_path variable to be unset. This is because the default shipped 10-mail.conf file from Debian has: mail_driver = mbox mail_home = /home/%{user | username} mail_path = %{home}/mail mail_inbox_path = /var/mail/%{user} So, I overrode the mail_driver and mail_path in my local.conf. From the documentation, it seems like I should be able to set: mail_inbox_path = And that should clear it. Certainly, doveconf shows no mail_inbox_path variable set when that happens. However, no inbox! If I comment out mail_inbox_path from 10-mail.conf, doveconf output is identical, however the inbox works. My workaround is to make it the same as mail_path: mail_inbox_path = ~/Maildir However, I think the variable unsetting is buggy. This is dovecot 2.4.1. --Pat

2 2

Safe upgrade path from 2.4.1 to 2.4.4 (CVE-2026-40020) on Debian 13
by Artem Ignatov 21 Aug '26

21 Aug '26

Hello, (Redirected here from support(a)dovecot.org - I understand that address is for commercial/Pro support, and this is a Community Edition question.) We run a production mail server on Debian GNU/Linux 13 (trixie), using the Dovecot package currently shipped in the Debian 13 stable repository: dovecot-core 1:2.4.1+dfsg1-6+deb13u6 We are affected by CVE-2026-40020 ("IMAP folders can be shared-spammed to everyone"), which as far as we understand is fixed upstream in Dovecot 2.4.4. Debian 13 stable does not yet ship a backported fix, so we are currently working around the issue by not using shared/ACL mailbox access at all, and waiting for an official Debian security update. We would appreciate the community's guidance on a few points: 1. Is a safe, supported upgrade path from 2.4.1 to 2.4.4 recommended for a production instance currently installed from Debian's own package (rather than compiling from source or using a third-party repository)? 2. Are there any breaking changes between 2.4.1 and 2.4.4 we should be aware of - configuration syntax, Maildir index file format compatibility, or anything that would require downtime or re-indexing on a live mail store? 3. Our setup uses SQL-based virtual users/passdb (via PostfixAdmin/MySQL), Sieve filtering, and per-user quotas. Are there any known interactions between these features and the 2.4.4 update that we should test for before rolling it out? 4. Do you have a general recommendation on whether to wait for the Debian security team to backport the fix into 13 stable, versus updating manually ahead of that? Any guidance, or a pointer to relevant release notes/changelog entries between 2.4.1 and 2.4.4, would be very helpful. Thank you, Artem Ignatov IT Administrator, GK INVEST

2 1

Dovecot 2.4: possible bug in quota-status service
by Othmar Truniger 21 Aug '26

21 Aug '26

Hi, I'm testing dovecot 2.4 (2.4.1 on debian trixie) after migrating from 2.3. When checking the quota-status service (quota-status -p postfix) over telnet, the response for new mail over quota returns an empty text for action. Example: # telnet 127.0.0.1 10022 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. recipient=mailtest(a)truniger.ch size=13000000 action= recipient=mailtest(a)truniger.ch size=12000000 action=OK ^] telnet> quit The manual says that an empty value for "quota_status_toolarge" defaults to "quota_status_overquota". But when looking a the actual source code of quote-status.c this does not seem to be the case - the return value is ,\0' for action: Code from line 231: switch (qret) { case QUOTA_ALLOC_RESULT_OK: /* under quota */ value = set->quota_status_success; break; case QUOTA_ALLOC_RESULT_OVER_MAXSIZE: /* even over maximum quota */ case QUOTA_ALLOC_RESULT_OVER_QUOTA_LIMIT: value = set->quota_status_toolarge; if (value[0] == '\0') break; /* fall through */ case QUOTA_ALLOC_RESULT_OVER_QUOTA: case QUOTA_ALLOC_RESULT_OVER_QUOTA_MAILBOX_LIMIT: value = set->quota_status_overquota; break; case QUOTA_ALLOC_RESULT_TEMPFAIL: case QUOTA_ALLOC_RESULT_BACKGROUND_CALC: ret = -1; break; } value = t_strdup(value); settings_free(set); if I'm reading this correctly the value of "value" stays at ,\0' when quota_status_toolarge is equal ,\0'. I can solve the problem by explicitly setting any value for quota_status_toolarge in the configuration. Regards, Othmar Hi, I'm testing dovecot 2.4 (2.4.1 on debian trixie) after migrating from 2.3. When checking the quota-status service (quota-status -p postfix) over telnet, the response for new mail over quota returns an empty text for action. Example: # telnet 127.0.0.1 10022 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. recipient=mailtest(a)truniger.ch size=13000000 action= recipient=mailtest(a)truniger.ch size=12000000 action=OK ^] telnet> quit The manual says that an empty value for "quota_status_toolarge" defaults to "quota_status_overquota". But when looking a the actual source code of quote-status.c this does not seem to be the case - the return value is '\0` for action: Code from line 231: switch (qret) { case QUOTA_ALLOC_RESULT_OK: /* under quota */ value = set->quota_status_success; break; case QUOTA_ALLOC_RESULT_OVER_MAXSIZE: /* even over maximum quota */ case QUOTA_ALLOC_RESULT_OVER_QUOTA_LIMIT: value = set->quota_status_toolarge; if (value[0] == '\0') break; /* fall through */ case QUOTA_ALLOC_RESULT_OVER_QUOTA: case QUOTA_ALLOC_RESULT_OVER_QUOTA_MAILBOX_LIMIT: value = set->quota_status_overquota; break; case QUOTA_ALLOC_RESULT_TEMPFAIL: case QUOTA_ALLOC_RESULT_BACKGROUND_CALC: ret = -1; break; } value = t_strdup(value); settings_free(set); if I'm reading this correctly the value of "value" stays at '\0` when quota_status_toolarge is equal '\0`. I can solve the problem by explicitly setting any value for quota_status_toolarge in the configuration. Regards, Othmar

1 0

Dovecot 2.4: shared mailboxes not working - maybe related to mail_path
by Markus Schönhaber 21 Aug '26

21 Aug '26

Hi, I've had a hard time trying to upgrade my dovecot 2.3 setup to v. 2.4 (debian 13, Dovecot installed from repo.dovecot.org) One thing I still haven't got to work is mailbox sharing. I have configured this (full doveconf -n output attached): mail_driver = mdbox mail_home = /var/spool/vmail/home/%{user | domain}/%{user | username} mail_path = /var/spool/vmail/mail/%{user | domain}/%{user | username} mail_plugins = quota acl namespace inbox { inbox = yes separator = / } namespace shared { mail_home = /var/spool/vmail/home/%{owner_domain}/%{owner_username} list = children prefix = shared/$domain/$username/ separator = / subscriptions = no type = shared } acl_driver = vfile mail_plugins { acl = yes } protocol imap { mail_plugins { imap_acl = yes } } acl_sharing_map { dict file { path = /var/spool/vmail/home/shared-mailboxes } } Now, given two users: 1: sharing-user(a)example.com 2: sharing-client(a)example.net User 1 wants to share his mailbox "4you" to user 2 by setting these acls: > # doveadm acl add -u sharing-user(a)example.com 4you user=sharing-client(a)example.net lookup read write-seen But the shared mailbox isn't visible for user 2 (in fact, not even the namespace is, since list = children). acl debug shows this: > # doveadm acl debug -u sharing-client(a)example.net shared/example.com/sharing-user/4you > doveadm(sharing-client(a)example.net): Error: Mailbox shared/example.com/sharing-user/4you: Mailbox '4you' in namespace shared doesn't exist in /var/spool/vmail/mail/example.net/sharing-client/mailboxes/4you/dbox-Mails So the shared mailbox is looked for in user 2's mail_path, not in user 1's, who shares it and where the mailbox actually resides. So, I tried and set mail_path = /var/spool/vmail/path/%{owner_domain}/%{owner_username} for the shared namespace. This does not only seem reasonable but also is mentioned in the second config example here: https://doc.dovecot.org/2.4.4/core/config/shared_mailboxes.html#user-shared… But that doesn't help. Instead I get: > # doveadm acl debug -u sharing-client(a)example.net shared/example.com/sharing-user/4you > doveadm(sharing-client(a)example.net): Error: Namespace shared: mail_storage settings: Failed to parse configuration: Failed to expand mail_path setting variables: Unknown variable 'owner_domain' > doveadm(sharing-client(a)example.net): Error: Namespace shared: mail_storage settings: Failed to parse configuration: Failed to expand mail_path setting variables: Unknown variable 'owner_domain' > doveadm(sharing-client(a)example.net): Error: Namespace shared: mail_storage settings: Failed to parse configuration: Failed to expand mail_path setting variables: Unknown variable 'owner_domain' > doveadm(sharing-client(a)example.net): Error: Mailbox shared/example.com/sharing-user/4you: Can't open mailbox shared/example.com/sharing-user/4you: Internal error occurred. Refer to server log for more information. [2026-08-20 14:53:40] Swapping %{owner_domain} and %{owner_username} in the config above, I get Unknown variable 'owner_username' as error. If I set mail_path = /var/spool/vmail/mail/example.com/sharing-user i. e. I hard-code the sharing user's mail_path, sharing works for this particular user. But that won't help if a second user wants to share mailboxes too. > # doveadm acl debug -u sharing-client(a)example.net shared/example.com/sharing-user/4you > doveadm(sharing-client(a)example.net): Info: Mailbox shared/example.com/sharing-user/4you: Mailbox '4you' is in namespace shared > doveadm(sharing-client(a)example.net): Info: Mailbox shared/example.com/sharing-user/4you: Mailbox path: /var/spool/vmail/mail/example.com/sharing-user/mailboxes/4you/dbox-Mails > doveadm(sharing-client(a)example.net): Info: Mailbox shared/example.com/sharing-user/4you: All message flags are shared across users in mailbox > doveadm(sharing-client(a)example.net): Info: Mailbox shared/example.com/sharing-user/4you: User sharing-client(a)example.net has rights: lookup read write-seen > doveadm(sharing-client(a)example.net): Info: Mailbox shared/example.com/sharing-user/4you: Mailbox found from dovecot-acl-list > doveadm(sharing-client(a)example.net): Info: Mailbox shared/example.com/sharing-user/4you: User sharing-user(a)example.com found from ACL shared dict > doveadm(sharing-client(a)example.net): Info: Mailbox shared/example.com/sharing-user/4you: Mailbox shared/example.com/sharing-user/4you is visible in LIST What am I doing wrong? How to do ist right? -- Regards mks

2 3

[BUG] IMAP hibernation fails on FreeBSD 15.x with "Invalid peer_dev_major value"
by Jordan Ostrev 20 Aug '26

20 Aug '26

Hi, IMAP hibernation compiles and attempts to run on FreeBSD 15.x (tested with Dovecot 2.4.4 and FreeBSD 15.1), but fails at runtime with: plain imap-hibernate: Error: conn unix:imap-hibernate (uid=125): Failed to parse client input: Invalid peer_dev_major value: 18446744073709551615 Jun 24 21:27:08 classic dovecot[36888]: imap-hibernate: Error: conn unix:imap-hibernate (uid=125): Failed to parse client input: Invalid peer_dev_major value: 18446744073709551615 Jun 24 21:27:08 classic dovecot[36888]: imap(jordan(a)ostreff.info)<37120><ExaV/gNVAdt/AAAB>: Error: Couldn't hibernate imap client: /var/run/dovecot/imap-hibernate returned failure: Failed to parse client input: Invalid peer_dev_major value: 18446744073709551615 Root cause: In src/imap/imap-client-hibernate.c, the code serializes peer_dev_major and peer_dev_minor using major() and minor() macros: c str_printfa(cmd, "\tpeer_dev_major=%lu\tpeer_dev_minor=%lu\tpeer_ino=%llu", (unsigned long)major(peer_st.st_dev), (unsigned long)minor(peer_st.st_dev), (unsigned long long)peer_st.st_ino); On FreeBSD, major() and minor() can return UINT64_MAX (18446744073709551615) for file descriptors that are not block/character devices (such as sockets on tmpfs/devfs). This value exceeds UINT_MAX and cannot be parsed by str_to_uint() in imap-master-client.c. Historical context: This was discussed on the Dovecot mailing list in July 2019 (thread: "Hibernation errors") but apparently never resolved upstream. The same failure mode persists in Dovecot 2.4.4. Impact: IMAP hibernation is effectively non-functional on FreeBSD 15.x Processes remain running indefinitely instead of being hibernated Documentation note: The Dovecot 2.4 documentation states that hibernation "is not supported on kqueue based systems currently, such as FreeBSD." However, the code still compiles and attempts to run, producing these errors rather than being disabled at compile time or gracefully skipped at runtime. Would it make sense to either: Disable hibernation at compile time for kqueue systems, or Add validation for major()/minor() return values before serialization? Thanks, Jordan Hi, IMAP hibernation compiles and attempts to run on FreeBSD 15.x (tested with Dovecot 2.4.4 and FreeBSD 15.1), but fails at runtime with: plain imap-hibernate: Error: conn unix:imap-hibernate (uid=125): Failed to parse client input: Invalid peer_dev_major value: 18446744073709551615 Jun 24 21:27:08 classic dovecot[36888]: imap-hibernate: Error: conn unix:imap-hibernate (uid=125): Failed to parse client input: Invalid peer_dev_major value: 18446744073709551615 Jun 24 21:27:08 classic dovecot[36888]: imap(jordan(a)ostreff.info)<37120><ExaV/gNVAdt/AAAB>: Error: Couldn't hibernate imap client: /var/run/dovecot/imap-hibernate returned failure: Failed to parse client input: Invalid peer_dev_major value: 18446744073709551615 Root cause: In src/imap/imap-client-hibernate.c, the code serializes peer_dev_major and peer_dev_minor using major() and minor() macros: c str_printfa(cmd, "\tpeer_dev_major=%lu\tpeer_dev_minor=%lu\tpeer_ino=%llu", (unsigned long)major(peer_st.st_dev), (unsigned long)minor(peer_st.st_dev), (unsigned long long)peer_st.st_ino); On FreeBSD, major() and minor() can return UINT64_MAX (18446744073709551615) for file descriptors that are not block/character devices (such as sockets on tmpfs/devfs). This value exceeds UINT_MAX and cannot be parsed by str_to_uint() in imap-master-client.c. Historical context: This was discussed on the Dovecot mailing list in July 2019 (thread: "Hibernation errors") but apparently never resolved upstream. The same failure mode persists in Dovecot 2.4.4. Impact: o IMAP hibernation is effectively non-functional on FreeBSD 15.x o Processes remain running indefinitely instead of being hibernated Documentation note: The Dovecot 2.4 documentation states that hibernation "is not supported on kqueue based systems currently, such as FreeBSD." However, the code still compiles and attempts to run, producing these errors rather than being disabled at compile time or gracefully skipped at runtime. Would it make sense to either: 1. Disable hibernation at compile time for kqueue systems, or 2. Add validation for major()/minor() return values before serialization? Thanks, Jordan

3 12

IMAP access marking new messages as "old" for mutt
by Marc Haber 19 Aug '26

19 Aug '26

Hi, this might be a stupid question asked by someone who does not know enough about IMAP, but I'm going to tell you my user story anyway: tl;dr: can I keep dovecot from moving all "NEW" message to· "OLD" state when the Mailbox was opened once and nothing actually read? long version: My mail is delivered to a maildir on a machine I also have a shell account on. That Maildir is huge, it holds half a million messages. I usually access it directly with mutt accessing the spool. In the Mailbox, new messages automatically get the N flag and once I have opened it in mutt, I can mark it as "O" (old). I use that flag for messages that still need further work, I usually have a couple of hundred messages in that state. There is also a third state (I would call it "read") that doesnt display any flags in mutt. Occasionally, I need access to an attachment directly on my work box. In the past, I have moved that message to a sub-maildir which I then access with Thunderbird or neomutt via IMAP and dovecot (configured via userdb). I now want to give neomutt direct IMAP access to the BIG mailbox. I am impressed how quickly the neomutt/dovecot acesses this mailbox. However, once I have once opened that mailbox, all messages that had the N flag in the mutt-on-spool lose that flag immediately, replaced by the O flag. That destroys my method of seeing "O" messages as "needs work". Since that happens with both Thunderbird and neomutt when testing, I suspect, this is either mandated by the protocol (which would be a showstopper for me), or a dovecot issue, maybe even a thing that I could configure in dovecot. Hence, my question, can I configure dovecot to move a "NEW" message to "OLD" only if the message was actually READ/body-displayed by an IMAP client? And, if yes, how do I do that. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

2 1

RE: ai dovecot
by Marc 16 Aug '26

16 Aug '26

No I am curious if they use llms, because I am getting more and more impressed by it. I see suggestions referring to RFC compliant code, which I have been missing in quite a few developers working for me. I think if you are full time developer this can be really helpful. Not to mention those news items where software is ported and scanned for vulnerabilities. > > So you'd like the developers to subject their code to LLMs for audit? > What idiocy is that! > > On Sun, Aug 16, 2026 at 1:33 AM Marc <Marc(a)f1-outsourcing.eu > <mailto:Marc@f1-outsourcing.eu> > wrote: > > > > > > > > > I am just a bit curious, are llm's being used to check the > code or > > help in any other way? > > > > > > > > Why does it bother you? > > > > > > > ??? Can't you read? I am curious, not bothered. > > > > > -- > > Best regards, > Odhiambo WASHINGTON, > Nairobi,KE > +254 7 3200 0004/+254 7 2274 3223 > In an Internet failure case, the #1 suspect is a constant: DNS. > "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) > [How to ask smart questions: http://www.catb.org/~esr/faqs/smart- > questions.html]

1 0

mbox - maildir transition using dovecot lmtp local user auth struggles
by "Tóth Attila" 14 Aug '26

14 Aug '26

Approaching age 49 I passed the time long before when I was excited about a new version or a software upgrade. Why poke something that works? From time to time I'm forced to upgrade hardware and software against my will otherwise could serve many more years. I became the victim of mbox -> maildir transition. First I converted the good old Sendmail to Postfix. Initially it still used procmail delivering in mbox mailboxes, now I converted the mboxes to maildir and changed the way of delivery by dovecot lmtp, since that is the software I use for IMAP access. At least there seem to be no data-loss after a couple of doveadm backup and sync retries. There are just 4 local users, so dovecot was set for pam authentication and it worked (for 20+ years, although there were some bumps while upgrading from 2.3 to 2.4 syntax). Now dovecot lmtp started bouncing mails, because it was trying to authenticate a username including the domain name as well and the backend returned unknown user, since expected local user names. This wasn't a problem with mbox/procmail. I asked AI for help and first suggested to use auth_username_format = %Ln. It soon turned out, that this syntax is obsolete. So I dig into it myself and tried auth_username_format = %{user | lower}. It wasn't picked up by dovecot, symptoms persisted. I also tried auth_username_translation = %{user | split('@') | list_first}, which turned out to be also unsuccessful. I also tried to solve the issue on the postfix side by introducing regex handling, but either lmtp_generic_maps = regexp:/etc/postfix/lmtp_generic or recipient_canonical_maps = regexp:/etc/postfix/recipient_canonical had no influence on the symptoms (regex was: /^([^@]+)@atoth\.sote\.hu$/ ${1}). Also tried virtual conversion and lda. Nothing solved the fricking problem. I ended up using a workaround I'm ashamed to share. I kept passdb pam, but for userdb I created a userdb-file, where I included users both with the local name only and the full email address. This shameful concept is functional, but I have to admit it is disappointing: several ways back and forth for solving an issue were all unsuccessful. And it is exhausting. Any ideas appreciated. BR: Dw. -- dr Tóth Attila, Radiológus, 06-20-825-8057 Attila Toth MD, Radiologist, +36-20-825-8057

1 0

Debian 13 Dovecot 2.4.1 LMTP Error Absent ~/sieve
by Conrad T. Pino 14 Aug '26

14 Aug '26

Hello Dovecot List, Our upgrade from Debian 9 Dovecot 2.2.27 to Debian 13 Dovecot 2.4.1 went well. Only recently we added a new mailbox and LMTP delivery failed. Dovecot redacted error from Postfix log: 451 4.2.0 <user@domain> Temporarily unable to access necessary Sieve scripts (in reply to end of DATA command)) Dovecot redacted errors from Dovecot log: dovecot[736]: lmtp(user@domain): Error: sieve: file storage: Performing t_readlink() on active sieve symlink '(null)' failed: readlink() failed: Bad address dovecot[736]: lmtp(user@domain): Error: sieve: Failed to access active Sieve script in parsonal storage 'default': Internal error occurred. Refer to server log for more information. [2026-08-13] (temporary failure) LMTP delivery works after manually creating ~/sieve directory with correct permissions. I know a PostfixAdmin postcreation script can automate directory creation. Have I overlooked Dovecot setting to have Dovecot create ~/sieve directory during LMTP delivery? Best regards, Conrad T. Pino

1 0

ai dovecot
by Marc 14 Aug '26

14 Aug '26

I am just a bit curious, are llm's being used to check the code or help in any other way?

1 0