- dovecot - dovecot.org

Freebsd Dovecot24 port
by The Doctor 23 Aug '26

23 Aug '26

Something is not correct. Dovecot 2.3 ports does work, but not the 2.4 ports Here are errors I am seeing Aug 21 15:01:01 auth: Debug: conn unix:login (uid=30) [9]: client in: AUTH 1 PLAIN protocol=imap final-resp-ok secured=tls session=f5oT75RZ zsYKDgAE lip=204.209.81.1 rip=10.14.0.4 lport=993 rport=50 894 ssl_ja3_hash=b8f77ef1c9705bb58db7ce238ba640d7 local_name=pop3.nk.ca resp=AGRhdmUAIS0xLSFAIyQlXiYqKCkxMjM0NTY3ODkw (previous base64 data may contain sensitive data) Aug 21 15:01:01 auth(?,10.14.0.4,sasl:plain)<f5oT75RZzsYKDgAE>: Debug: sasl(plai n): Request create Aug 21 15:01:01 auth(?,10.14.0.4,sasl:plain)<f5oT75RZzsYKDgAE>: Debug: penalty(1 0.14.0.4): Delaying response for 0 seconds Aug 21 15:01:01 auth(?,10.14.0.4,sasl:plain)<f5oT75RZzsYKDgAE>: Debug: sasl(plai n): Started interaction with initial response (size=30) Aug 21 15:01:01 auth(dave,10.14.0.4,sasl:plain)<f5oT75RZzsYKDgAE>: Debug: sasl(p lain): Set authid 'dave' Aug 21 15:01:01 auth(dave,10.14.0.4,sasl:plain)<f5oT75RZzsYKDgAE>: Debug: sasl(plain): Performing plain passdb verification Aug 21 15:01:01 auth(dave,10.14.0.4,sasl:plain)<f5oT75RZzsYKDgAE>: Debug: passwd-file: Performing passdb lookup Aug 21 15:01:01 auth(dave,10.14.0.4,sasl:plain)<f5oT75RZzsYKDgAE>: Info: passwd-file: missing passwd file: scheme=CRYPT /etc/master.passwd Aug 21 15:01:01 auth(dave,10.14.0.4,sasl:plain)<f5oT75RZzsYKDgAE>: Debug: passwd-file: Finished passdb lookup Aug 21 15:01:01 auth(dave,10.14.0.4,sasl:plain)<f5oT75RZzsYKDgAE>: Debug: sasl(p lain): Finished plain passdb verification (status=user-unknown) Aug 21 15:01:01 auth(dave,10.14.0.4,sasl:plain)<f5oT75RZzsYKDgAE>: Debug: sasl(plain): Interaction failed Aug 21 15:01:01 auth(dave,10.14.0.4,sasl:plain)<f5oT75RZzsYKDgAE>: Debug: Auth request finished Aug 21 15:01:01 auth(dave,10.14.0.4,sasl:plain)<f5oT75RZzsYKDgAE>: Debug: delaying auth failure Aug 21 15:01:03 auth: Debug: conn unix:login (uid=30) [9]: client passdb out: FAIL 1 user=dave Aug 21 15:01:03 auth(dave,10.14.0.4)<f5oT75RZzsYKDgAE>: Debug: sasl(plain): Request destroy Aug 21 15:01:03 imap-login: Info: Login aborted: Connection closed (auth failed, 1 attempts in 2 secs) (auth_failed): user=<dave>, method=PLAIN, rip=10.14.0.4, lip=204.209.81.1, TLS Aug 21 15:01:03 auth: Debug: conn unix:login (uid=30) [9]: Disconnected: EOF (fd=26) Aug 21 15:01:08 master: Info: Dovecot v2.4.4 (8b687aa65c) starting up for imap, pop3, lmtp I switch back to dovecot 2.3 .X no problem. -- Member - Liberal International This is doctor(a)nk.ca Ici doctor(a)nk.ca Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism ; 31 years in the ISP business!

5 9

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

22 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

3 3

Global sieve variables don't work in 2.4.4
by inaugurator＠ya.ru 22 Aug '26

22 Aug '26

Hi everyone! I have created a minimal reproducible setup. First, let's prepare the environment and create the necessary directories: ```shell getent group vmail >/dev/null \ || groupadd -g 500 vmail; \ getent passwd vmail \ | awk -F: '$3 == "500" && $4 == "vmail"' >/dev/null \ || { id vmail >/dev/null 2>&1 && usermod -u 500 -g vmail vmail \ || useradd -u 500 -g vmail -M -s /usr/sbin/nologin vmail; } mkdir -p /mail && chown vmail:vmail -R /mail cat > /mail/global_bug.sieve <<EOF require ["variables", "include"]; global "global_var"; set "global_var" "hello"; EOF cat > /mail/before_bug.sieve <<EOF require ["variables", "include", "vnd.dovecot.debug"]; global "global_var"; include :global :optional "global_bug"; debug_log "\${global_var}"; EOF ``` Then, we configure dovecot.conf: ``` dovecot_config_version = 2.4.4 dovecot_storage_version = 2.4.4 auth_allow_cleartext = yes mail_driver = maildir mail_home = /mail/%{user} mail_inbox_path = .INBOX mail_uid = vmail mail_gid = vmail first_valid_uid = 500 protocols { imap = yes } mail_plugins { imap_sieve = yes } service imap-login { inet_listener imaps { port = 0 } } passdb anypass { driver = static fields { nopassword = yes } } sieve_global_extensions { vnd.dovecot.debug = yes } sieve_script global_bug { driver = file path = /mail/global_bug.sieve type = global } namespace inbox { inbox = yes separator = / mailbox INBOX { auto = subscribe sieve_script before_bug { driver = file path = /mail/before_bug.sieve cause = APPEND type = before } } } ``` If we run an APPEND command to the INBOX directory: ```shell curl -v -u "user1:hello" -k "imap://localhost:143/INBOX" --upload-file /tmp/test.eml ``` the log shows an empty message. ``` imap(user1)<3155434><YNISPNZYHtV/AAAB>: sieve: DEBUG: ``` However, if we change the configuration and the Sieve script by replacing "global" with "personal", I see my hello in debug log: ``` ... sieve_script global_bug { driver = file path = /mail/global_bug.sieve type = personal # !!! } ... require ["variables", "include", "vnd.dovecot.debug"]; global "global_var"; include :personal :optional "global_bug"; # !!! debug_log "\${global_var}"; ... imap(user1)<3155659><iiiIhNZYgpl/AAAB>: sieve: DEBUG: hello ``` Why am I unable to import a global variable into a before script if it is defined in a global script? Thank You in advance!

1 1

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

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

BUG 2.4 regression: a wrong password over PLAIN is reported as a temporary failure, and the invalid_grant branch is now dead code
by Ihor Rusyn 14 Aug '26

14 Aug '26

Summary With passdb oauth2 doing a password grant, a wrong password makes dovecot answer the IMAP client a NO [UNAVAILABLE] Temporary authentication failure. and log it at Error: level. 2.3 answered AUTHENTICATIONFAILED for the same exchange. PASSDB_RESULT_PASSWORD_MISMATCH is still in db-oauth2.c, but for the password grant it can no longer be reached. Environment Dovecot *2.4.4 (8b687aa65c)*, the official dovecot/dovecot:2.4.4-root image, unmodified. Compared against *2.3.21*. Reproduction Any RFC 6749 compliant authorization server. Point passdb oauth2 at its token endpoint with grant_type=password and attempt an IMAP LOGIN with a wrong password. The server answers, as §5.2 prescribes: HTTP 400 {"error":"invalid_grant","error_description":"Invalid credentials"} *2.3.21:* NO [AUTHENTICATIONFAILED], logged at info level. *2.4.4:* NO [UNAVAILABLE] Temporary authentication failure, logged as auth(user,ip,sasl:plain): Error: oauth2-grant: oauth2 failed: Password grant failed: Invalid credentials imap-login: Login aborted: Logged out (auth service reported temporary failure, 1 attempts in 3 secs) (temp_fail) Cause src/auth/db-oauth2.c is identical in both versions: passdb_result = PASSDB_RESULT_INTERNAL_FAILURE; if (result->error != NULL) error = result->error; else { error = db_oauth2_field_find(result->fields, "error"); if (error == NULL) error = "OAuth2 server returned failure without error field"; else if (strcmp("invalid_grant", error) == 0) passdb_result = PASSDB_RESULT_PASSWORD_MISMATCH; } What changed is what reaches result->error. In *2.3.21*, src/lib-oauth2/oauth2-request.c:113-129 set error only when the JSON *parser* failed. A well-formed error body parsed fine, so error was NULL, res.error stayed NULL, and db-oauth2.c took the else branch, found invalid_grant among the fields and returned PASSWORD_MISMATCH. In *2.4.4*, src/lib-oauth2/oauth2-request.c:136-149 added: /* check if fields contain error now */ const struct oauth2_field *error_field = array_lsearch(&req->fields, "error", request_field_cmp); if (error_field != NULL) { error = error_field->value; /* "invalid_grant" */ /* check for detailed error */ error_field = array_lsearch(&req->fields, "error_description", request_field_cmp); if (error_field != NULL) error = error_field->value; /* overwritten: "Invalid credentials" */ } req->json_parsed_cb(req, error); oauth2_request_continue() then does if (error != NULL) res.error = error;, so result->error is always set on failure and db-oauth2.c never reaches the branch that recognises invalid_grant. The machine-readable code is replaced by the human-readable description before anything can act on it. Note that error_description is *optional* in RFC 6749 §5.2 — so a fully compliant server triggers this simply by being helpful. Omitting it does not help either: error would then hold invalid_grant and still be assigned to res.error, taking the same branch. Why it matters - Mail clients treat [UNAVAILABLE] as a server problem and retry rather than prompting for the password, so users are not told their password is wrong. - Monitoring reads a user error as a service failure — on a farm this is the difference between a quiet log and a page. - RFC 5530 defines AUTHENTICATIONFAILED for a failed authentication and UNAVAILABLE for a temporarily unavailable server. Reporting the former as the latter tells the client something untrue about the server. There is no anti-enumeration benefit in the current behaviour: the same provider response is returned for a wrong password and for a non-existent account, so both are indistinguishable to the client under either mapping. Summary With passdb oauth2 doing a password grant, a wrong password makes dovecot answer the IMAP client a NO [UNAVAILABLE] Temporary authentication failure. and log it at Error: level. 2.3 answered AUTHENTICATIONFAILED for the same exchange. PASSDB_RESULT_PASSWORD_MISMATCH is still in db-oauth2.c, but for the password grant it can no longer be reached. Environment Dovecot 2.4.4 (8b687aa65c), the official dovecot/dovecot:2.4.4-root image, unmodified. Compared against 2.3.21. Reproduction Any RFC 6749 compliant authorization server. Point passdb oauth2 at its token endpoint with grant_type=password and attempt an IMAP LOGIN with a wrong password. The server answers, as S5.2 prescribes: HTTP 400 {"error":"invalid_grant","error_description":"Invalid credentials"} 2.3.21: NO [AUTHENTICATIONFAILED], logged at info level. 2.4.4: NO [UNAVAILABLE] Temporary authentication failure, logged as auth(user,ip,sasl:plain): Error: oauth2-grant: oauth2 failed: Password grant failed: Invalid credentials imap-login: Login aborted: Logged out (auth service reported temporary failure, 1 attempts in 3 secs) (temp_fail) Cause src/auth/db-oauth2.c is identical in both versions: passdb_result = PASSDB_RESULT_INTERNAL_FAILURE; if (result->error != NULL) error = result->error; else { error = db_oauth2_field_find(result->fields, "error"); if (error == NULL) error = "OAuth2 server returned failure without error field"; else if (strcmp("invalid_grant", error) == 0) passdb_result = PASSDB_RESULT_PASSWORD_MISMATCH; } What changed is what reaches result->error. In 2.3.21, src/lib-oauth2/oauth2-request.c:113-129 set error only when the JSON parser failed. A well-formed error body parsed fine, so error was NULL, res.error stayed NULL, and db-oauth2.c took the else branch, found invalid_grant among the fields and returned PASSWORD_MISMATCH. In 2.4.4, src/lib-oauth2/oauth2-request.c:136-149 added: /* check if fields contain error now */ const struct oauth2_field *error_field = array_lsearch(&req->fields, "error", request_field_cmp); if (error_field != NULL) { error = error_field->value; /* "invalid_grant" */ /* check for detailed error */ error_field = array_lsearch(&req->fields, "error_description", request_field_cmp); if (error_field != NULL) error = error_field->value; /* overwritten: "Invalid credentials" */ } req->json_parsed_cb(req, error); oauth2_request_continue() then does if (error != NULL) res.error = error;, so result->error is always set on failure and db-oauth2.c never reaches the branch that recognises invalid_grant. The machine-readable code is replaced by the human-readable description before anything can act on it. Note that error_description is optional in RFC 6749 S5.2 -- so a fully compliant server triggers this simply by being helpful. Omitting it does not help either: error would then hold invalid_grant and still be assigned to res.error, taking the same branch. Why it matters o Mail clients treat [UNAVAILABLE] as a server problem and retry rather than prompting for the password, so users are not told their password is wrong. o Monitoring reads a user error as a service failure -- on a farm this is the difference between a quiet log and a page. o RFC 5530 defines AUTHENTICATIONFAILED for a failed authentication and UNAVAILABLE for a temporarily unavailable server. Reporting the former as the latter tells the client something untrue about the server. There is no anti-enumeration benefit in the current behaviour: the same provider response is returned for a wrong password and for a non-existent account, so both are indistinguishable to the client under either mapping.

1 0

IMAP4rev2: extended LIST drops \Sent, \Drafts, \Trash and \Junk unless the client sends the RFC 6154 return option that IMAP4rev2 does not define
by dennis＠dennisameling.com 14 Aug '26

14 Aug '26

SYSTEM INFORMATION ================== Dovecot version: 2.4.4 (8b687aa65c), Pigeonhole 2.4.4 (3beb331a) OS: Linux 6.12.76-linuxkit aarch64, Debian 13.5 (official dovecot/dovecot:2.4.4 container image, digest sha256:723e3392fe16c6fad8ddc605ea767cc01b4bad 9cd9f13eb1dbac15e79c89b2d4) Host: Docker 29.6.2 (linux/arm64) on macOS 26, Apple silicon CPU architecture: aarch64 (arm64) Filesystem: Docker named volume (overlay2) inside the Docker Desktop VM. Not NFS. Feature: experimental IMAP4rev2 (imap4rev2_enable, mail_utf8_extensions) Client: our own IMAP client library (Rust), but reproduced below with openssl s_client so that no client code is involved The configuration is the image's own /etc/dovecot/dovecot.conf, unmodified: nothing of ours is in it. Rather than paste 200 lines of your own defaults, "doveconf -n" for it is docker run --rm --entrypoint doveconf dovecot/dovecot:2.4.4 -n and we will gladly send the output if you would prefer it inline. The three settings that bear on this report are imap4rev2_enable = yes, mail_utf8_extensions = yes and mailbox_list_utf8 = yes, all three of which the image sets itself. SUMMARY ======= In an IMAP4rev2 session, an extended LIST (one carrying any RETURN (...) clause) omits the special-use mailbox attributes unless the client also sends RETURN (SPECIAL-USE). IMAP4rev2 folded those attributes into the base protocol and defines no SPECIAL-USE return option, so a client that implements only RFC 9051 has no defined way to ask for them, and therefore cannot obtain them from any extended LIST at all. The practical effect for such a client is that every folder loses its role the moment the client asks for anything else -- in our case RETURN (STATUS (UNSEEN)), to fetch unread counts in the same round trip. It cannot find the \Sent folder to place a copy of a sent message in, cannot find \Trash to move a deleted message to, and renders the mailbox list without role icons or ordering. We are not asking for a workaround: we already send RETURN (SPECIAL-USE) on both dialects, since Dovecot advertises the SPECIAL-USE capability in a rev2 session too. This report is about what a strictly RFC 9051 client is able to do. That decision in our client is here, in case it is of interest -- the comment above it records what we found on your server: https://github.com/allodia-eu/email-calendar-sync-engine/blob/fa85b88121132… REPRODUCTION ============ No configuration is required. dovecot/dovecot:2.4.4 ships imap4rev2_enable = yes and mail_utf8_extensions = yes in its own /etc/dovecot/dovecot.conf, and its "@mailbox_defaults = english" creates Drafts/Junk/Sent/Trash with special-use attributes. docker run -d --name dovecot-stock -p 127.0.0.1:11999:31993 \ -e USER_PASSWORD=stock-test-pw \ dovecot/dovecot:2.4.4 { printf 'a1 LOGIN alice(a)example.com stock-test-pw\r\n'; sleep 2; printf 'a2 ENABLE IMAP4rev2\r\n'; sleep 1; printf 'a3 LIST "" "*"\r\n'; sleep 1; printf 'a4 LIST "" "*" RETURN (STATUS (UNSEEN))\r\n'; sleep 1; printf 'a5 LIST "" "*" RETURN (SPECIAL-USE STATUS (UNSEEN))\r\n'; sleep 1; printf 'a6 LOGOUT\r\n'; sleep 1; } \ | openssl s_client -connect 127.0.0.1:11999 -quiet TRANSCRIPT ========== Verbatim; the greeting and the CAPABILITY lines are elided. S: * ENABLED IMAP4REV2 S: a2 OK Enabled (0.001 + 0.000 secs). C: a3 LIST "" "*" S: * LIST (\HasNoChildren \Drafts) "/" Drafts S: * LIST (\HasNoChildren \Junk) "/" Junk S: * LIST (\HasNoChildren \Sent) "/" Sent S: * LIST (\HasNoChildren \Trash) "/" Trash S: * LIST (\HasNoChildren) "/" INBOX S: a3 OK List completed (0.001 + 0.000 secs). --> correct: the role attributes are present C: a4 LIST "" "*" RETURN (STATUS (UNSEEN)) S: * LIST () "/" Drafts S: * STATUS Drafts (UNSEEN 0) S: * LIST () "/" Junk S: * STATUS Junk (UNSEEN 0) S: * LIST () "/" Sent S: * STATUS Sent (UNSEEN 0) S: * LIST () "/" Trash S: * STATUS Trash (UNSEEN 0) S: * LIST () "/" INBOX S: * STATUS INBOX (UNSEEN 0) S: a4 OK List completed (0.034 + 0.000 + 0.033 secs). --> the problem: every role attribute is gone, and IMAP4rev2 gives the client no option to ask for them back C: a5 LIST "" "*" RETURN (SPECIAL-USE STATUS (UNSEEN)) S: * LIST (\Trash) "/" Trash S: * STATUS Trash (UNSEEN 0) S: * LIST (\Sent) "/" Sent S: * STATUS Sent (UNSEEN 0) S: * LIST (\Junk) "/" Junk S: * STATUS Junk (UNSEEN 0) S: * LIST (\Drafts) "/" Drafts S: * STATUS Drafts (UNSEEN 0) S: * LIST () "/" INBOX S: * STATUS INBOX (UNSEEN 0) S: a5 OK List completed (0.002 + 0.000 + 0.001 secs). --> present again, but only via the RFC 6154 return option, which RFC 9051 does not define WHY WE BELIEVE a4 IS NOT CORRECT FOR IMAP4rev2 ============================================== 1. RFC 9051 section 7.3.1 makes the special-use attributes ordinary LIST mailbox attributes: "In addition to the base mailbox name attributes defined above, an IMAP server MAY also include any or all of the following attributes that denote 'role' (or 'special-use') of a mailbox. These attributes are included along with base attributes defined above." Appendix E item 2 lists "the list of new mailbox attributes from SPECIAL-USE [RFC6154]" among what IMAP4rev2 folded in. 2. RFC 9051 section 6.3.9.2 defines the return options for IMAP4rev2 as exactly SUBSCRIBED, CHILDREN and STATUS. There is no SPECIAL-USE return option. Nor is SPECIAL-USE among the selection options in section 6.3.9.1, which are SUBSCRIBED, REMOTE and RECURSIVEMATCH; it survives in RFC 9051 only as an unexplained C: A002 LIST (SPECIAL-USE) "" "*" in the NAMESPACE examples in section 6.3.10, which may itself be worth an erratum. 3. Section 6.3.9 says "a client MUST NOT send an option for which the server has not advertised support", so a strictly rev2 client will not invent one. Taken together, an RFC 9051-only client can obtain the role attributes on a basic LIST but never on an extended one, which means it cannot combine roles with RETURN (STATUS ...) -- the single round trip that RFC 5819 exists to provide. Since RFC 9051 section 6.3.9 also states that return options "MUST NOT cause the server to report information about additional mailbox names", but says nothing about removing base attributes, we read a4 as a case where an attribute defined as base data is being withheld. Note the contrast with \HasNoChildren in the same transcript: it also disappears in a4, but CHILDREN is a return option in RFC 9051, so a rev2 client can ask for it back. For special-use there is no equivalent. WHAT WE BELIEVE CORRECT BEHAVIOUR WOULD BE ========================================== In a session where IMAP4rev2 has been ENABLEd, include the special-use attributes in extended LIST responses without requiring RETURN (SPECIAL-USE) -- that is, treat them as the base mailbox attributes that RFC 9051 section 7.3.1 defines them to be. The RFC 6154 return option would remain accepted for IMAP4rev1 sessions. NOTE ON IMAP4rev1: WE BELIEVE THAT BEHAVIOUR IS CORRECT ======================================================= The same server on an IMAP4rev1 session behaves identically, and there we read it as compliant. RFC 6154 section 2 says "The extended LIST command MAY return SPECIAL-USE attributes even if the client does not specify the return option", and MAY is not MUST. This report concerns only IMAP4rev2 sessions, where the way to ask was removed along with the need to. CONTACT ======= Happy to test a patch. The reproduction is a single "docker run", and we keep both an IMAP4rev1 and an IMAP4rev2 Dovecot fixture in our CI, so a fix can be regression-tested on both dialects.

2 1

Request for official Dovecot 2.4 RPMs for Amazon Linux 2023
by Yashar Fakhari 14 Aug '26

14 Aug '26

Hello Dovecot team, Would you consider providing official Dovecot 2.4 RPMs for Amazon Linux 2023 on both x86_64 and aarch64? I needed Dovecot 2.4 for FTS Flatcurve because Amazon Linux 2023 currently provides Dovecot 2.3 without a Flatcurve package, while the standalone Flatcurve project for 2.3 is EOL and development has moved into Dovecot core. I have developed a working experimental build process, and I hope the lessons from it could help make Amazon Linux 2023 easier to add to your release workflow: The entire build runs through GitHub Actions using Amazon Linux 2023 containers. GitHub repo: https://github.com/YasharF/dovecot.2.4.ALinux2023 Workflow files .github/workflow:- watch.yml monitors Dovecot's RPM repository for new releases.- build.yml, using build/build.sh, rebuilds the RPMs for both architectures with two documented spec adjustments.- verify.yml runs basic verification tests.- publish.yml publishes verified artifacts as a DNF-compatible repository. I am currently using the resulting RPMs in production. This project is intended only as a temporary bridge until AWS or Dovecot provides official packages. Official, continuously updated Dovecot packages would remain valuable even if AWS later adopts a newer release. As a distribution, AWS/Amazon Linux may freeze the packaged version and provide primarily security fixes rather than each subsequent Dovecot feature and bug-fix release. Thank you for considering this. Let me know if I can contribute in any other way for this. Best regards, Yashar Fakharihttps://github.com/YasharFhttps://linkedin.com/in/YasharF Hello Dovecot team, Would you consider providing official Dovecot 2.4 RPMs for Amazon Linux 2023 on both x86_64 and aarch64? I needed Dovecot 2.4 for FTS Flatcurve because Amazon Linux 2023 currently provides Dovecot 2.3 without a Flatcurve package, while the standalone Flatcurve project for 2.3 is EOL and development has moved into Dovecot core. I have developed a working experimental build process, and I hope the lessons from it could help make Amazon Linux 2023 easier to add to your release workflow: The entire build runs through GitHub Actions using Amazon Linux 2023 containers. GitHub repo: https://github.com/YasharF/dovecot.2.4.ALinux2023 Workflow files .github/workflow: - watch.yml monitors Dovecot's RPM repository for new releases. - build.yml, using build/build.sh, rebuilds the RPMs for both architectures with two documented spec adjustments. - verify.yml runs basic verification tests. - publish.yml publishes verified artifacts as a DNF-compatible repository. I am currently using the resulting RPMs in production. This project is intended only as a temporary bridge until AWS or Dovecot provides official packages. Official, continuously updated Dovecot packages would remain valuable even if AWS later adopts a newer release. As a distribution, AWS/Amazon Linux may freeze the packaged version and provide primarily security fixes rather than each subsequent Dovecot feature and bug-fix release. Thank you for considering this. Let me know if I can contribute in any other way for this. Best regards, Yashar Fakhari https://github.com/YasharF https://linkedin.com/in/YasharF

2 1

fts-flatcurve 2.4.4: after "doveadm fts optimize" a mailbox stops indexing new mail (empty current.<id> shard, missing iamglass)
by Ihor Rusyn 13 Aug '26

13 Aug '26

Hello, "doveadm fts optimize" leaves the mailbox in a state where no new mail can be indexed. The existing index survives and searches over already-indexed mail keep working, so the damage is invisible until the next message arrives. Version: 2.4.4 (8b687aa65c), packaged in a container image FTS: fts_flatcurve, substring_search = yes, min_term_size default (2) fts_autoindex = yes, fts_search_add_missing = yes Index store: NFSv3 (rsize/wsize 32768, local_lock=none) Mail store: NFSv3, maildir Reproduction ------------ 1) Starting point: a healthy index. # doveadm fts flatcurve check -u user(a)example.com INBOX INBOX guid=88885837bb33136365390000d09efc50 errors=0 shards=1 # ls /indexes/.../.INBOX/fts-flatcurve/*/ current.1786117302443530: flintlock iamglass postlist.glass termlist.glass # doveadm search -u user(a)example.com mailbox INBOX text a | tail -1 88885837bb33136365390000d09efc50 58 2) Optimize. Exits 0, prints nothing. # doveadm fts optimize -u user(a)example.com # echo $? 0 3) State afterwards: the compacted data is in a new index.<n> directory, and the pre-existing current.<id> directory is still present but EMPTY. # ls /indexes/.../.INBOX/fts-flatcurve/*/ current.1786117302443530: index.1464: flintlock iamglass postlist.glass termlist.glass # ls -ld .../fts-flatcurve/current.1786117302443530 drwx------ 2 dovecot dovecot 4096 Aug 7 16:08 .../current.1786117302443530 # doveadm fts flatcurve check -u user(a)example.com INBOX Error: fts-flatcurve(INBOX): Cannot open DB (RO; current.1786117302443530); DatabaseNotFoundError: Couldn't detect type of database Error: fts-flatcurve(INBOX): Check failed; DatabaseOpeningError: Directory does not contain a Xapian database Searching already-indexed mail still works at this point: # doveadm search -u user(a)example.com mailbox INBOX text a | tail -1 88885837bb33136365390000d09efc50 58 4) Deliver one message and index it. This is where it breaks: # printf 'From: a(a)b.c\nSubject: reproprobe\n\nbody\n' \ | doveadm save -u user(a)example.com -m INBOX Info: Mailbox INBOX: save: box=INBOX, uid=59, subject=reproprobe # doveadm index -u user(a)example.com INBOX Error: fts-flatcurve(INBOX): Cannot open DB (RW, current.1786117302443530): .../current.1786117302443530/iamglass: Failed to open glass revision file for reading (No such file or directory) Error: cmd index: Mailbox INBOX: Precache for UID=59 failed: Internal error 5) From now on SEARCH fails too, because fts_search_add_missing makes it index first: # doveadm search -u user(a)example.com mailbox INBOX text reproprobe Error: Mailbox INBOX: indexer failed to index mailbox Error: cmd search: Searching mailbox INBOX failed: Internal error occurred. Over IMAP the client sees: NO [SERVERBUG] Internal error occurred. It does not recover by itself ----------------------------- "doveadm index" and autoindexing both take the same write path and fail the same way. "doveadm fts rescan" does not help either -- it also cannot open the empty shard. The only repair we found is to delete the folder's fts-flatcurve directory and index the folder again. Impact ------ A quiet mailbox looks fine for as long as nothing is delivered to it, so this can sit unnoticed. We found it because a monitoring mailbox that receives one message per minute started returning SERVERBUG on SEARCH. In our case a maintenance run that called "doveadm fts optimize" per mailbox left 114 mailboxes in this state, which is all of the ones that had any mail. Possible cause (not verified) ----------------------------- In fts_flatcurve_xapian_optimize_box_do() every shard is first opened for writing ("We need to lock all of the mailboxes so nothing changes while we are optimizing"), and the old current.*/index.* directories are then deleted from disk while those write handles are still open. A handle that is closed afterwards appears to recreate its directory without a glass revision file, which matches what is left behind. Also, in the same function the result of fts_flatcurve_xapian_rename_db(backend, dbpath, NULL, error_r) is discarded: rename_db() does not update the path it is given and returns the new path only through newpath_r, which is NULL at this call site. I have not tried to confirm either of these beyond reading the code. Not the same as the known root-owned iamglass report ---------------------------------------------------- There is an older report where "doveadm fts optimize -A" run from cron as root left iamglass owned by root, producing the same error string. That is not this: here the directories are owned by the mail user (dovecot:dovecot, 0700) and the revision file does not exist at all. -- Best regards, Ihor Rusyn Hello, "doveadm fts optimize" leaves the mailbox in a state where no new mail can be indexed. The existing index survives and searches over already-indexed mail keep working, so the damage is invisible until the next message arrives. Version: 2.4.4 (8b687aa65c), packaged in a container image FTS: fts_flatcurve, substring_search = yes, min_term_size default (2) fts_autoindex = yes, fts_search_add_missing = yes Index store: NFSv3 (rsize/wsize 32768, local_lock=none) Mail store: NFSv3, maildir Reproduction ------------ 1) Starting point: a healthy index. # doveadm fts flatcurve check -u [1]user(a)example.com INBOX INBOX guid=88885837bb33136365390000d09efc50 errors=0 shards=1 # ls /indexes/.../.INBOX/fts-flatcurve/*/ current.1786117302443530: flintlock iamglass postlist.glass termlist.glass # doveadm search -u [2]user(a)example.com mailbox INBOX text a | tail -1 88885837bb33136365390000d09efc50 58 2) Optimize. Exits 0, prints nothing. # doveadm fts optimize -u [3]user(a)example.com # echo $? 0 3) State afterwards: the compacted data is in a new index.<n> directory, and the pre-existing current.<id> directory is still present but EMPTY. # ls /indexes/.../.INBOX/fts-flatcurve/*/ current.1786117302443530: index.1464: flintlock iamglass postlist.glass termlist.glass # ls -ld .../fts-flatcurve/current.1786117302443530 drwx------ 2 dovecot dovecot 4096 Aug 7 16:08 .../current.1786117302443530 # doveadm fts flatcurve check -u [4]user(a)example.com INBOX Error: fts-flatcurve(INBOX): Cannot open DB (RO; current.1786117302443530); DatabaseNotFoundError: Couldn't detect type of database Error: fts-flatcurve(INBOX): Check failed; DatabaseOpeningError: Directory does not contain a Xapian database Searching already-indexed mail still works at this point: # doveadm search -u [5]user(a)example.com mailbox INBOX text a | tail -1 88885837bb33136365390000d09efc50 58 4) Deliver one message and index it. This is where it breaks: # printf 'From: a(a)b.c\nSubject: reproprobe\n\nbody\n' \ | doveadm save -u [6]user(a)example.com -m INBOX Info: Mailbox INBOX: save: box=INBOX, uid=59, subject=reproprobe # doveadm index -u [7]user(a)example.com INBOX Error: fts-flatcurve(INBOX): Cannot open DB (RW, current.1786117302443530): .../current.1786117302443530/iamglass: Failed to open glass revision file for reading (No such file or directory) Error: cmd index: Mailbox INBOX: Precache for UID=59 failed: Internal error 5) From now on SEARCH fails too, because fts_search_add_missing makes it index first: # doveadm search -u [8]user(a)example.com mailbox INBOX text reproprobe Error: Mailbox INBOX: indexer failed to index mailbox Error: cmd search: Searching mailbox INBOX failed: Internal error occurred. Over IMAP the client sees: NO [SERVERBUG] Internal error occurred. It does not recover by itself ----------------------------- "doveadm index" and autoindexing both take the same write path and fail the same way. "doveadm fts rescan" does not help either -- it also cannot open the empty shard. The only repair we found is to delete the folder's fts-flatcurve directory and index the folder again. Impact ------ A quiet mailbox looks fine for as long as nothing is delivered to it, so this can sit unnoticed. We found it because a monitoring mailbox that receives one message per minute started returning SERVERBUG on SEARCH. In our case a maintenance run that called "doveadm fts optimize" per mailbox left 114 mailboxes in this state, which is all of the ones that had any mail. Possible cause (not verified) ----------------------------- In fts_flatcurve_xapian_optimize_box_do() every shard is first opened for writing ("We need to lock all of the mailboxes so nothing changes while we are optimizing"), and the old current.*/index.* directories are then deleted from disk while those write handles are still open. A handle that is closed afterwards appears to recreate its directory without a glass revision file, which matches what is left behind. Also, in the same function the result of fts_flatcurve_xapian_rename_db(backend, dbpath, NULL, error_r) is discarded: rename_db() does not update the path it is given and returns the new path only through newpath_r, which is NULL at this call site. I have not tried to confirm either of these beyond reading the code. Not the same as the known root-owned iamglass report ---------------------------------------------------- There is an older report where "doveadm fts optimize -A" run from cron as root left iamglass owned by root, producing the same error string. That is not this: here the directories are owned by the mail user (dovecot:dovecot, 0700) and the revision file does not exist at all. -- Best regards, Ihor Rusyn References Visible links 1. mailto:user@example.com 2. mailto:user@example.com 3. mailto:user@example.com 4. mailto:user@example.com 5. mailto:user@example.com 6. mailto:user@example.com 7. mailto:user@example.com 8. mailto:user@example.com

4 6

Reports to this list held twice for message size — please release them from moderation
by Ihor Rusyn 11 Aug '26

11 Aug '26

Hello, I have twice tried to send a bug report to this list, and both times the message was blocked for exceeding the size limit with error "The message is larger than the 40 KB maximum size" The report is long because it is meant to be actionable: environment details, exact reproduction steps, log excerpts and strace output. That is the material a maintainer asks for first — and it is exactly what the size limit rejects. If this list is where technical reports belong, a limit that blocks them works against its purpose. Could you please release both of my held messages from moderation and reply on the thread? If long reports are not wanted here, I would appreciate a pointer to where they should go instead. The subject of email was «2.4.4 fts-flatcurve: fts optimize silently destroys a folder's index when the index is on NFS», sent on today from this address. -- Best regards, Ihor Ru Hello, I have twice tried to send a bug report to this list, and both times the message was blocked for exceeding the size limit with error "The message is larger than the 40 KB maximum size" The report is long because it is meant to be actionable: environment details, exact reproduction steps, log excerpts and strace output. That is the material a maintainer asks for first -- and it is exactly what the size limit rejects. If this list is where technical reports belong, a limit that blocks them works against its purpose. Could you please release both of my held messages from moderation and reply on the thread? If long reports are not wanted here, I would appreciate a pointer to where they should go instead. The subject of email was <<2.4.4 fts-flatcurve: fts optimize silently destroys a folder's index when the index is on NFS>>, sent on today from this address. -- Best regards, Ihor Ru

3 2

2.4.4 fts-flatcurve: fts optimize silently destroys a folder's index when the index is on NFS
by Ihor Rusyn 11 Aug '26

11 Aug '26

Hello, Summary ======= On Dovecot 2.4.4 with fts_flatcurve and mail_index_path on NFS, "doveadm fts optimize" leaves behind an empty shard directory. That directory remains the shard every subsequent write opens, so from that point on the folder can no longer index new mail. The operation reports success and logs nothing at the time. The damage is permanent and, on a folder that receives no new mail, invisible. Two separate defects are involved, and both are reported below: (1) fts optimize deletes a shard directory whose files it still holds open. On a local filesystem the unlink succeeds invisibly; NFS cannot express "unlink but keep open" and silly-renames instead, so the directory survives. (2) unlink_directory() reports success when rmdir() failed, which is what makes (1) silent rather than loud. Environment =========== Dovecot 2.4.4 CE (8b687aa65c) container image sha256:d6b2f80db2e656a9250583712a82397e2752b35ad7e4e2e71c85fdc0d510137d base Debian 13 trixie fts_flatcurve (Xapian glass) libxapian30 1.4.29-3 (libxapian.so.30.14.1) substring_search = yes, min_term_size = 2 optimize_limit at its default of 10 dovecot_storage_version = 2.3.0 mail_index_path on NFSv3; mail storage on a separate NFS export NFS client is the host, not the container: Debian 12 bookworm, kernel 6.1.0-51-amd64 x86_64 nfs-common 1:2.6.2-4+deb12u1 mount options: rw,noatime,vers=3,rsize=32768,wsize=32768,hard, nordirplus,proto=tcp,timeo=600,retrans=2,sec=sys, local_lock=none Impact ====== An operator does not have to invoke optimize to be exposed: with the default optimize_limit = 10, flatcurve runs it itself once a folder accumulates ten shards. Every active folder therefore reaches this eventually. Already-indexed mail stays searchable, so the folder looks healthy. Only indexing of new mail fails. With fts_search_add_missing = yes, the first SEARCH after new mail arrives attempts to index it, fails, and the client receives NO [SERVERBUG]. I hit this while migrating a host from 2.3 to 2.4: 114 mailboxes were left in this state in a single run, and it surfaced only because a monitoring mailbox began answering SERVERBUG. Defect 1: fts optimize leaves an empty shard directory on NFS ============================================================= Steps to reproduce ------------------ 1. Configure fts_flatcurve with the index path on an NFSv3 mount. 2. Take a mailbox with mail in INBOX (a few hundred messages is enough) and build the index: doveadm index -u <user> INBOX Confirm one shard exists: ls <index>/.INBOX/fts-flatcurve/ -> current.<id> 3. Run: doveadm fts optimize -u <user> INBOX (Alternatively, let it fire on its own by driving the folder past optimize_limit shards.) 4. While it runs, list the shard directory repeatedly - .nfsXXXX entries appear inside current.<id>. 5. After it finishes, note the exit status is 0 and no error was logged. List the directory again: index.<n> was created as expected, and current.<id> is still there, now empty. 6. Deliver one new message, then: doveadm index -u <user> INBOX Expected vs actual ------------------ Expected: after optimize, only the compacted index.<n> remains, and subsequent indexing writes to a new shard. Actual: the stale empty current.<id> remains and is reopened for writing, so step 6 fails: Cannot open DB (RW, current.<id>): .../current.<id>/iamglass: Failed to open glass revision file for reading (No such file or directory) cmd index: Mailbox INBOX: Precache for UID=59 failed and IMAP SEARCH on that folder returns NO [SERVERBUG]. What I observed while diagnosing -------------------------------- strace of "doveadm fts optimize" on NFSv3 shows the old shard's files being unlinked while handles on them are still open, so the directory cannot be removed: unlink(...) = 0 (x7, every file in the shard) rmdir(...) = -1 ENOTEMPTY (Directory not empty) rename(...) = 0 (optimize -> index.N, proceeds regardless) Once the process exits, the NFS client reaps the .nfsXXXX files and the directory is simply empty. What does not help ------------------ NFSv4.1, mounting with nolock, "doveadm fts rescan", "doveadm index", and full re-indexing all take the same write path into the same empty shard and fail identically. Removing the empty directory (or the folder's whole fts-flatcurve tree) and re-indexing restores the folder; setting optimize_limit = 0 avoids the situation but leaves the index spread across many shards. Defect 2: unlink_directory() returns success when rmdir() failed ================================================================ The ENOTEMPTY above never reaches the caller. unlink_directory() in src/lib/unlink-directory.c returns 1 when the final rmdir() fails, the same value it returns on success: if (rmdir(dir) < 0 && errno != ENOENT) { *error_r = t_strdup_printf("rmdir(%s) failed: %m", dir); return errno == ENOENT ? 0 : 1; } The "errno != ENOENT" guard already establishes that errno is not ENOENT, so the ternary always yields 1. Callers cannot distinguish "directory removed" from "directory still there", and the error message it composed is discarded. Any condition that makes rmdir() fail with something other than ENOENT reproduces this, so the return value is wrong independently of NFS - every caller of unlink_directory() is affected. The code path is unchanged in current main. -- Best regards, Ihor Ru Hello, Summary ======= On Dovecot 2.4.4 with fts_flatcurve and mail_index_path on NFS, "doveadm fts optimize" leaves behind an empty shard directory. That directory remains the shard every subsequent write opens, so from that point on the folder can no longer index new mail. The operation reports success and logs nothing at the time. The damage is permanent and, on a folder that receives no new mail, invisible. Two separate defects are involved, and both are reported below: (1) fts optimize deletes a shard directory whose files it still holds open. On a local filesystem the unlink succeeds invisibly; NFS cannot express "unlink but keep open" and silly-renames instead, so the directory survives. (2) unlink_directory() reports success when rmdir() failed, which is what makes (1) silent rather than loud. Environment =========== Dovecot 2.4.4 CE (8b687aa65c) container image sha256:d6b2f80db2e656a9250583712a82397e2752b35ad7e4e2e71c85fdc0d510137d base Debian 13 trixie fts_flatcurve (Xapian glass) libxapian30 1.4.29-3 (libxapian.so.30.14.1) substring_search = yes, min_term_size = 2 optimize_limit at its default of 10 dovecot_storage_version = 2.3.0 mail_index_path on NFSv3; mail storage on a separate NFS export NFS client is the host, not the container: Debian 12 bookworm, kernel 6.1.0-51-amd64 x86_64 nfs-common 1:2.6.2-4+deb12u1 mount options: rw,noatime,vers=3,rsize=32768,wsize=32768,hard, nordirplus,proto=tcp,timeo=600,retrans=2,sec=sys, local_lock=none Impact ====== An operator does not have to invoke optimize to be exposed: with the default optimize_limit = 10, flatcurve runs it itself once a folder accumulates ten shards. Every active folder therefore reaches this eventually. Already-indexed mail stays searchable, so the folder looks healthy. Only indexing of new mail fails. With fts_search_add_missing = yes, the first SEARCH after new mail arrives attempts to index it, fails, and the client receives NO [SERVERBUG]. I hit this while migrating a host from 2.3 to 2.4: 114 mailboxes were left in this state in a single run, and it surfaced only because a monitoring mailbox began answering SERVERBUG. Defect 1: fts optimize leaves an empty shard directory on NFS ============================================================= Steps to reproduce ------------------ 1. Configure fts_flatcurve with the index path on an NFSv3 mount. 2. Take a mailbox with mail in INBOX (a few hundred messages is enough) and build the index: doveadm index -u <user> INBOX Confirm one shard exists: ls <index>/.INBOX/fts-flatcurve/ -> current.<id> 3. Run: doveadm fts optimize -u <user> INBOX (Alternatively, let it fire on its own by driving the folder past optimize_limit shards.) 4. While it runs, list the shard directory repeatedly - .nfsXXXX entries appear inside current.<id>. 5. After it finishes, note the exit status is 0 and no error was logged. List the directory again: index.<n> was created as expected, and current.<id> is still there, now empty. 6. Deliver one new message, then: doveadm index -u <user> INBOX Expected vs actual ------------------ Expected: after optimize, only the compacted index.<n> remains, and subsequent indexing writes to a new shard. Actual: the stale empty current.<id> remains and is reopened for writing, so step 6 fails: Cannot open DB (RW, current.<id>): .../current.<id>/iamglass: Failed to open glass revision file for reading (No such file or directory) cmd index: Mailbox INBOX: Precache for UID=59 failed and IMAP SEARCH on that folder returns NO [SERVERBUG]. What I observed while diagnosing -------------------------------- strace of "doveadm fts optimize" on NFSv3 shows the old shard's files being unlinked while handles on them are still open, so the directory cannot be removed: unlink(...) = 0 (x7, every file in the shard) rmdir(...) = -1 ENOTEMPTY (Directory not empty) rename(...) = 0 (optimize -> index.N, proceeds regardless) Once the process exits, the NFS client reaps the .nfsXXXX files and the directory is simply empty. What does not help ------------------ NFSv4.1, mounting with nolock, "doveadm fts rescan", "doveadm index", and full re-indexing all take the same write path into the same empty shard and fail identically. Removing the empty directory (or the folder's whole fts-flatcurve tree) and re-indexing restores the folder; setting optimize_limit = 0 avoids the situation but leaves the index spread across many shards. Defect 2: unlink_directory() returns success when rmdir() failed ================================================================ The ENOTEMPTY above never reaches the caller. unlink_directory() in src/lib/unlink-directory.c returns 1 when the final rmdir() fails, the same value it returns on success: if (rmdir(dir) < 0 && errno != ENOENT) { *error_r = t_strdup_printf("rmdir(%s) failed: %m", dir); return errno == ENOENT ? 0 : 1; } The "errno != ENOENT" guard already establishes that errno is not ENOENT, so the ternary always yields 1. Callers cannot distinguish "directory removed" from "directory still there", and the error message it composed is discarded. Any condition that makes rmdir() fail with something other than ENOENT reproduces this, so the return value is wrong independently of NFS - every caller of unlink_directory() is affected. The code path is unchanged in current main. -- Best regards, Ihor Ru

1 0

Tribulations trying to pin-down viable sieve script constraints in connection with imap events.
by sjh_dovecot_org＠shic.co.uk 10 Aug '26

10 Aug '26

Hi Dovecot experts... I've recently started what I expected to be a tiny project to migrate from a legacy ad-hoc procmail by embracing Sieve scripting. I have two different frustrations - depending upon which approach I adopt to trigger spam-training actions. *Option 1*: Trigger actions when messages are moved to/from Spam folder. This mostly works... but has has a niggle I can't see how to overcome. I don't have only one 'Spam' folder - I have a hierarchy of folders - with names like "Spam.2026.July" and "Spam.Unsubscribed.2023". My 'learn ham' sieve script uses "imap.mailbox" from environment to determine if the email is being moved out of the Spam hierarchy. This works well. Unfortunately, when triggering 'learn spam' - the value of imap.mailbox is always the destination mailbox 'Spam' - not the source mailbox from which the spammy email has been moved. I can't see any way to trigger a spam reporting action, within Sieve scripts, if (and only if) a message is moved from a folder that does not have a name matching 'Spam.*' into the folder 'Spam'. This restriction is required so that adjustments to filed spam messages do not result in a single email being wrongly presented multiple times for learning as a spam example. This multiple reporting might otherwise happen if, for example, a message was moved between 'Spam' and 'Spam.2025.July" ; "Spam.2025.August" and "Spam.ForReview.2025" several times. Have I overlooked a reliable way to determine the source folder, in a Sieve script, when a message is moved (copied) to the Spam folder? *Option 2*: Trigger actions when the Thunderbird 'Junk' and 'Not Junk' buttons are pressed I accept it would be preferable to avoid depending upon client-specific flags... but I do expect Thunderbird to be the mail client... and marking messages as Junk/Spam in Thunderbird does promise a neat user interface experience. I've read RFC 6785 (also RFC 5228 and RFC 5232). I understand that the "imap.changedflags" environment value is set both when flags have been added and when removed... and that it is expected that hasflag should be used to determine if the imap.changedflag flag was added or removed. This makes perfect sense, in principle... but the actual behaviour I see is peculiar. With a sieve script /var/dovecot-sieve/scripts/flags_changed.sieve (compiled with sievec) like this: require ["environment", "imap4flags", "imapsieve", "variables", "vnd.dovecot.debug"]; if header :matches "subject" "*" { debug_log "FLAG-EMAIL Subject: ${1}"; } if environment :matches "imap.changedflags" "*" { debug_log "FLAG-EMAIL changedflags : ${1}"; } if hasflag :matches "*" { debug_log "FLAG-EMAIL hasflag : ${1}"; } and configuration in /etc/dovecot/conf.d/90-sieve.conf like this (N.B. user sieve script does not interact with flags... type=after and type=before behave similarly): sieve_script flags_changed { type = after cause = flag path = /var/dovecot-sieve/scripts/flags_changed.sieve } I experimented with the "Junk" and "Not Junk" buttons for an email with a distinctive subject. The following nested bullet-list summarises the values I found for various scenarios. My experiment followed this order of scenarios - there should have been no flag changes, for the email in question, between each of the scenarios in the test sequence. * Scenario 1 - Fresh, not-deterimed-to-be-spam email arrives in Inbox... - Sieve script invocation 1 * imap.changedflags => NonJunk * hasflag => NonJunk - Notes: As expected. * Scenario 2 - Same email is marked as read by Thunderbird after it has been displayed onscreen for a while... - Sieve script invocation 2 * imap.changedflags => \Seen * hasflag => \seen - Notes: Flags are case insensitive - but odd lower case distinction. What happened to NonJunk flag from Scenario 1? * Scenario 3 - Junk button pressed to manually mark this email as spam... - Sieve script invocation 3 * imap.changedflags => Junk * hasflag => \seen - Sieve script invocation 4 * imap.changedflags => NonJunk * hasflag => \seen - Notes: Why neither Junk nor NonJunk flags set for hasflag? * Scenario 4 - "Not Junk" button is pressed to manually mark this email as ham... - Sieve script invocation 5 * imap.changedflags => NonJunk * hasflag => \seen - Sieve script invocation 6 * imap.changedflags => Junk * hasflag => \seen - Sieve script invocation 7 * imap.changedflags => \Seen * hasflag => NonJunk Perhaps it is relevant... where I have captured the value from hasflag... that only one token is ever reported - even where I'd expect multiple flags present. I would have expected at least to see both 'Junk' and 'NotJunk' alongside '\seen' for hasflag at appropriate stages in the sequence of scenarios. Is there a problem with how I've used the :match idiom (with "*") intending to capture all the flags associated with the message? (If so, what approach should I have used instead?) Is there a bug which prevents using the hasflag feature to disambiguate between a flag reported for imap.changedflags having been added versus having been removed? If not, where have I gone wrong? Versions... Server-side: Debian Trixie: dovecot-core/stable,stable-security,now 1:2.4.1+dfsg1-6+deb13u6 amd64 [installed] dovecot-imapd/stable,stable-security,now 1:2.4.1+dfsg1-6+deb13u6 amd64 [installed] dovecot-sieve/stable,stable-security,now 1:2.4.1+dfsg1-6+deb13u6 amd64 [installed] Client-side: Windows 11 Thunderbird 140.12.1esr (64-bit) Steve NonJunk \seen 5 Junk \seen 6 \Seen NonJunk 7 Weird... Is NonJunk reported for hasflag because it is now the only flag associated with the message (after \Seen flag removed)?

3 5

[patch] proposed patch for managing timeouts on doveadm iteration with -A
by John Fawcett 10 Aug '26

10 Aug '26

Hi having further investigated the timeouts mentioned in the previous thread, I am submitting this patch as a potential solution. Basically with -A doveadm parameter, the 155 second timeout is applied to the whole end to end transaction. With -F parameter the 155 second timeout is applied to each single user operation. Changing the logic of -A to follow -F looks a bit invasive. So this patch does more or less the same thing, i.e. giving each user operation 155 seconds timeout, done in a different way. Whenever another username is returned, the timeout is reset. PS I got help from Claude on this. best regards John

3 5

Bug report: Pigeonhole Sieve delivery plugin fails to load in Dovecot 2.4 — undefined symbol mail_deliver_ctx_get_log_var_expand_table
by Developer Sub N Grill 08 Aug '26

08 Aug '26

Hello Dovecot Team, I am reporting what appears to be a packaging/ABI issue affecting the Pigeonhole Sieve delivery plugin in Dovecot 2.4. I have performed extensive diagnostics and would appreciate any guidance. Environment Operating System: Debian 13 (Trixie), amd64 Repository: Official Dovecot CE repository (repo.dovecot.org/ce-2.4-latest/debian/trixie) Installed package version:2:2.4.4-5+debian13 Installed packages: dovecot-core dovecot-sieve dovecot-lmtpd dovecot-imapd dovecot-pop3d dovecot-managesieved dovecot-pgsql All packages are installed at the exact same version. Problem Description When enabling the Sieve delivery plugin with: mail_plugins { sieve = yes } Dovecot fails to load the plugin with the following error: sievec: Fatal: Couldn't load required plugin /usr/lib/dovecot/modules/lib90_sieve_plugin.so: dlopen() failed: /usr/lib/dovecot/modules/lib90_sieve_plugin.so: undefined symbol: mail_deliver_ctx_get_log_var_expand_table As a result, message delivery fails entirely whenever the Sieve delivery plugin is enabled. Disabling the plugin restores normal mail delivery. Diagnostics Performed1. Package verification All installed packages are version 2:2.4.4-5+debian13 from the official Dovecot CE repository. There are no mixed package versions. 2. Symbol verification I searched for the symbol mail_deliver_ctx_get_log_var_expand_table throughout the Dovecot libraries. Results: nm -D on libdovecot-lda.so.0.0.0 → symbol not found readelf -sW on libdovecot-lda.so.0.0.0 → symbol not found Recursive search across all .so files under: /usr/lib/dovecot/ /usr/lib/x86_64-linux-gnu/dovecot/ → symbol not exported anywhere The symbol string exists inside both: lib90_sieve_plugin.so libdovecot-lda.so.0.0.0 but only as plain text (visible via grep), never as an exported ELF symbol. 3. Dependency verification ldd on lib90_sieve_plugin.so shows dependencies on: libdovecot-sieve.so.0 libdovecot-storage.so.0 libdovecot.so.0 It does not directly link against libdovecot-lda.so. 4. Standalone sievec Compiling a Sieve script works correctly: sievec /tmp/test.sieve Exit status is 0 as long as no configuration enables the Sieve delivery plugin. The failure only occurs once: mail_plugins { sieve = yes } is present in the configuration. Reproduced on a Clean Debian 13 Installation To rule out configuration or upgrade issues, I reproduced the exact same problem on a completely clean debian:13-slim container. I installed only the Debian stable packages: apt-get install dovecot-core dovecot-sieve dovecot-lmtpd (version 1:2.4.1+dfsg1-6+deb13u6) Using the same production configuration with: mail_plugins { sieve = yes } produces the exact same error: sievec: Fatal: Couldn't load required plugin ... undefined symbol: mail_deliver_ctx_get_log_var_expand_table This indicates the problem is not caused by: mixed package versions an upgrade issue local modifications custom configuration The issue reproduces consistently on both: Dovecot CE 2.4.4 Debian 13's packaged Dovecot 2.4.1 Questions Is mail_deliver_ctx_get_log_var_expand_table a new internal function that should be exported in Dovecot 2.4? Was there an ABI change affecting the Pigeonhole plugin? Is this a known issue in the Dovecot 2.4.x packages? If so, is a fix planned (for example, in 2.4.5)? Is there any recommended workaround for using Sieve during message delivery (e.g. moving spam to the Junk folder) while this issue is unresolved? I am trying to use the new Dovecot 2.4 configuration syntax (sieve_script_type, sieve_script_precedence, and sieve_script_path), since sieve_before and the plugin {} block were removed in 2.4. Thank you for your time. I would be happy to provide additional logs, the complete doveconf -n output, or a core dump if that would be helpful. Best regards, Miguel A Morales Server: Debian 13 (amd64) Dovecot: 2.4.4-5+debian13 Hello Dovecot Team, I am reporting what appears to be a packaging/ABI issue affecting the Pigeonhole Sieve delivery plugin in Dovecot 2.4. I have performed extensive diagnostics and would appreciate any guidance. Environment o Operating System: Debian 13 (Trixie), amd64 o Repository: Official Dovecot CE repository (repo.dovecot.org/ce-2.4-latest/debian/trixie) o Installed package version: 2:2.4.4-5+debian13 Installed packages: o dovecot-core o dovecot-sieve o dovecot-lmtpd o dovecot-imapd o dovecot-pop3d o dovecot-managesieved o dovecot-pgsql All packages are installed at the exact same version. Problem Description When enabling the Sieve delivery plugin with: mail_plugins { sieve = yes } Dovecot fails to load the plugin with the following error: sievec: Fatal: Couldn't load required plugin /usr/lib/dovecot/modules/lib90_sieve_plugin.so: dlopen() failed: /usr/lib/dovecot/modules/lib90_sieve_plugin.so: undefined symbol: mail_deliver_ctx_get_log_var_expand_table As a result, message delivery fails entirely whenever the Sieve delivery plugin is enabled. Disabling the plugin restores normal mail delivery. Diagnostics Performed 1. Package verification All installed packages are version 2:2.4.4-5+debian13 from the official Dovecot CE repository. There are no mixed package versions. 2. Symbol verification I searched for the symbol mail_deliver_ctx_get_log_var_expand_table throughout the Dovecot libraries. Results: o nm -D on libdovecot-lda.so.0.0.0 -> symbol not found o readelf -sW on libdovecot-lda.so.0.0.0 -> symbol not found o Recursive search across all .so files under: o /usr/lib/dovecot/ o /usr/lib/x86_64-linux-gnu/dovecot/ -> symbol not exported anywhere o The symbol string exists inside both: o lib90_sieve_plugin.so o libdovecot-lda.so.0.0.0 but only as plain text (visible via grep), never as an exported ELF symbol. 3. Dependency verification ldd on lib90_sieve_plugin.so shows dependencies on: o libdovecot-sieve.so.0 o libdovecot-storage.so.0 o libdovecot.so.0 It does not directly link against libdovecot-lda.so. 4. Standalone sievec Compiling a Sieve script works correctly: sievec /tmp/test.sieve Exit status is 0 as long as no configuration enables the Sieve delivery plugin. The failure only occurs once: mail_plugins { sieve = yes } is present in the configuration. Reproduced on a Clean Debian 13 Installation To rule out configuration or upgrade issues, I reproduced the exact same problem on a completely clean debian:13-slim container. I installed only the Debian stable packages: apt-get install dovecot-core dovecot-sieve dovecot-lmtpd (version 1:2.4.1+dfsg1-6+deb13u6) Using the same production configuration with: mail_plugins { sieve = yes } produces the exact same error: sievec: Fatal: Couldn't load required plugin ... undefined symbol: mail_deliver_ctx_get_log_var_expand_table This indicates the problem is not caused by: o mixed package versions o an upgrade issue o local modifications o custom configuration The issue reproduces consistently on both: o Dovecot CE 2.4.4 o Debian 13's packaged Dovecot 2.4.1 Questions 1. Is mail_deliver_ctx_get_log_var_expand_table a new internal function that should be exported in Dovecot 2.4? Was there an ABI change affecting the Pigeonhole plugin? 2. Is this a known issue in the Dovecot 2.4.x packages? If so, is a fix planned (for example, in 2.4.5)? 3. Is there any recommended workaround for using Sieve during message delivery (e.g. moving spam to the Junk folder) while this issue is unresolved? I am trying to use the new Dovecot 2.4 configuration syntax (sieve_script_type, sieve_script_precedence, and sieve_script_path), since sieve_before and the plugin {} block were removed in 2.4. Thank you for your time. I would be happy to provide additional logs, the complete doveconf -n output, or a core dump if that would be helpful. Best regards, Miguel A Morales Server: Debian 13 (amd64) Dovecot: 2.4.4-5+debian13

3 2

Can't connect to MySQL without SSL
by dovecot＠fagschlunger.at 08 Aug '26

08 Aug '26

Hi! I try to migrate from dovecot 2.3 to dovecot CE 2.4, but within a docker container. But I always get the following error from Dovecot CE: Error: auth: mysql(host.docker.internal): Connect failed to database (foobar): TLS/SSL error: self-signed certificate in certificate chain - waiting for 1 seconds before retry This is how I configured the mysql connection: mysql host.docker.internal { host = host.docker.internal port = 3306 user = ... password = ... dbname = foobar ssl = no } So MySQL runs on the host machine directly, not in a container - therefore I'm using "host.docker.internal" as an host. But I don't need SQL encryption, since both MySQL and Dovecot run on the same machine. So why the heck does it look like, Dovecot is trying to connect using SSL? Best regards, Billie

5 7

Re: [patch] proposed patch for managing timeouts on doveadm iteration with -A
by MK 07 Aug '26

07 Aug '26

>On 26. Jul 2026, at 0.17, John Fawcett via dovecot <dovecot(a)dovecot.org> wrote: >> >> Hi >> >> having further investigated the timeouts mentioned in the previous thread, I am submitting this patch as a potential solution. >> >> Basically with -A doveadm parameter, the 155 second timeout is applied to the whole end to end transaction. With -F parameter the 155 second >timeout is applied to each single user operation. Changing the logic of -A to follow -F looks a bit invasive. So this patch does more or less the >same thing, i.e. giving each user operation 155 seconds timeout, done in a different way. Whenever another username is returned, the timeout is >reset. >> >> PS I got help from Claude on this. > >Some further improvements via Fable - does this still fix your problems? > >commit 9deefd88b37d4e9bfecdf6bd1c9fa8a3f9d6b100 >Author: Timo Sirainen <timo.sirainen(a)open-xchange.com> >Date: Wed Aug 5 21:33:42 2026 +0000 > > lib-auth-client: Extend LIST request timeout whenever a username is returned > > The auth lookup timeout (155 seconds by default) was applied to the whole > LIST request, i.e. the entire user enumeration. With large installations > listing all users can easily take longer than that, causing e.g. > doveadm -A to fail with "Auth server request timed out". > > Reset the request's timeout whenever another username is returned. This > turns the timeout into a "no progress for N seconds" stall detector, > matching how independent short-lived per-user requests (e.g. as used when > iterating -F user files) never accumulate a single deadline across the > whole run. > > The timeout handling assumes that requests expire in creation order, so > extending is only allowed while the request is alone on its connection. > This is always the case for LIST, which is asserted at init already. Timo can you say in which upcoming version this patch will be included? Oliver

1 0

Detection of HAVE_MYSQL_SSL_VERIFY_SERVER_CERT is broken
by Tomas Volf 31 Jul '26

31 Jul '26

Hello, detection of HAVE_MYSQL_SSL_VERIFY_SERVER_CERT is currently broken, and the macro is never defined. The test program fails, but for incorrect reason. --8<---------------cut here---------------start------------->8--- conftest.c:140:20: error: expected declaration specifiers or '...' before ',' token 140 | _au_m4_changequote(,) | ^ conftest.c:140:21: error: expected declaration specifiers or '...' before ')' token 140 | _au_m4_changequote(,) | ^ In file included from /gnu/store/6lmd3apzkmhwzj3yn0inyj484m9qml6y-mariadb-connector-c-3.4.5/include/mariadb/mysql.h:35, from conftest.c:141: /gnu/store/7iwcvd0gjrfq6bj7zvf3r59baw6vib5a-gcc-14.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/14.3.0/include/stdarg.h:103:9: error: unknown type name '__gnuc_va_list' 103 | typedef __gnuc_va_list va_list; | ^~~~~~~~~~~~~~ --8<---------------cut here---------------end--------------->8--- Fix is to delete the only occurrence of _au_m4_changequote([,]) in the m4/want_mysql.m4 file. However, that will reveal a compilation error here: --8<---------------cut here---------------start------------->8--- #ifdef HAVE_MYSQL_SSL_VERIFY_SERVER_CERT int ssl_verify_server_cert = ssl_set->ssl_client_require_valid_cert ? 1 : 0; mysql_options(db->mysql, MYSQL_OPT_SSL_VERIFY_SERVER_CERT, (void *)&ssl_verify_server_cert); #endif #else --8<---------------cut here---------------end--------------->8--- Variable `ssl_set' does not exist and should be `db->ssl_set'. Have a nice day, Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

1 0

Confusion about mailbox_list_layout=fs
by Roland Hieber 27 Jul '26

27 Jul '26

Hi, I am trying to understand how 'mailbox_list_layout = fs' is working when I have 'mail_driver = Maildir' (on Dovecot 2.4.1-4 from Debian trixie). If I look at 'doveconf -a', I see that 'mailbox_list_layout = fs' is already the default, however, the Maildirs from my freshly created test user are still created on disk in the format .INBOX.subfolder instead of INBOX/subfolder, which is in conflict with what the documentation says at <https://doc.dovecot.org/2.4.3/core/config/mailbox_formats/maildir.html#dire…>. However, if I set 'mailbox_list_layout = fs' *explicitely* in the global part of /etc/dovecot/conf.d/10-mail.conf, then delete all files and folders in the mail home of my test user, reload dovecot, send a test mail, and create a new subfolder for my test user in Thunderbird, the new subfolder gets created on disk as INBOX/subfolder, just like I expect. The behaviour is consistently reproducable in both directions: I also get maildirs with dots again after I delete mailbox_list_layout from 10-mail.conf, reload dovecot, and clear the mail home of my test user. What is going on here…? I don't see any change in 'doveconf -a' between these two use cases (the output is literally identical, and it's both showing 'mailbox_list_layout = fs'), and obviously it's missing from 'doveconf -n' because it's the default. I also found out that it is possible to override this setting per user by using the 'userdb_mailbox_list_layout' option in the extra fields of the userdb, but I'm not setting any extra fields there for my test user. Output of 'doveconf -n' (redacted where necessary) is attached. Regards, - Roland -- Roland Hieber, Pengutronix e.K. | rhi(a)pengutronix.de | Steuerwalder Str. 21 | https://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

2 2

Doveadm and iterate query
by Bogusław Juza 25 Jul '26

25 Jul '26

Hi! I have a problem with Dovecot on Debian 13: Dovecot 2.4.1, Debian Trixie > doveadm mailbox path -A INBOX >/dev/null doveadm(email@domain): Error: auth-master: userdb list: User listing returned failure doveadm: Error: cmd mailbox path: Failed to iterate through some users userdb sql { iterate_query = SELECT `email` AS `user` FROM `users` } In syslog file: dovecot: auth: Error: auth-worker: Aborted LIST request for *: Shutting down I have over 30k users in sql DB, doveadm with -A option is dying few second after start with this error, printing about 10% of users. I need much more time (FE command "doveadm expunge -A mailbox Spam savedbefore 3w" could run over 30 minutes). What I'm doing wrong? Bogusław Juza

5 12

Reporting a Patch needed: Fix-anvil-busy-loop-on-EPOLLHUP-when-a-multiplex-cha.patch
by David Lanning 24 Jul '26

24 Jul '26

The attached patch spec is what we had to deploy to cover the matter. The attached patch spec is what we had to deploy to cover the matter.

2 1

Strange characters in log file
by Doug Hardie 21 Jul '26

21 Jul '26

I am occasionally finding some strange characters in the log file. I have captured on entry that vi cannot handle. It simply won't go past this record. I suspect the issue is around 0347 in the record below. Any ideas how to prevent this from happening as it makes it difficult to find specific records in the log. vi is unable to delete the line with this issue. mail# head -1 imaplog.test | od -t x1c 0000000 4a 75 6c 20 31 37 20 30 32 3a 33 34 3a 35 35 20 J u l 1 7 0 2 : 3 4 : 5 5 0000020 6d 61 69 6c 20 64 6f 76 65 63 6f 74 5b 35 32 39 m a i l d o v e c o t [ 5 2 9 0000040 30 5d 3a 20 69 6d 61 70 28 64 6f 75 67 29 5b 31 0 ] : i m a p ( d o u g ) [ 1 0000060 30 2e 30 2e 31 2e 32 33 32 5d 3c 4e 74 79 78 52 0 . 0 . 1 . 2 3 2 ] < N t y x R 0000100 4d 74 57 4e 64 38 4b 41 41 48 6f 3e 3a 20 64 65 M t W N d 8 K A A H o > : d e 0000120 6c 65 74 65 3a 20 62 6f 78 3d 44 65 6c 65 74 65 l e t e : b o x = D e l e t e 0000140 64 20 4d 65 73 73 61 67 65 73 2c 20 75 69 64 3d d M e s s a g e s , u i d = 0000160 35 38 32 32 31 33 2c 20 6d 73 67 69 64 3d 3c 39 5 8 2 2 1 3 , m s g i d = < 9 0000200 31 30 35 30 36 39 31 2e 31 34 37 36 39 34 36 2e 1 0 5 0 6 9 1 . 1 4 7 6 9 4 6 . 0000220 31 37 38 33 35 38 37 39 33 35 37 36 36 40 6d 61 1 7 8 3 5 8 7 9 3 5 7 6 6 @ m a 0000240 72 6b 65 74 6f 2d 70 6c 61 74 66 6f 72 6d 2d 2d r k e t o - p l a t f o r m - - 0000260 65 6d 61 69 6c 2d 73 65 6e 64 65 72 2d 70 72 6f e m a i l - s e n d e r - p r o 0000300 64 2d 62 61 74 63 68 2d 63 6c 75 2e 2e 2e 2c 20 d - b a t c h - c l u . . . , 0000320 73 69 7a 65 3d 35 35 39 39 30 2c 20 66 72 6f 6d s i z e = 5 5 9 9 0 , f r o m 0000340 3d 57 4f 52 4c 44 e2 4d 2d 5e 40 4d 2d 5e 59 73 = W O R L D 342 M - ^ @ M - ^ Y s 0000360 20 54 69 6d 20 4c 61 6d 65 72 20 3c 65 64 69 74 T i m L a m e r < e d i t 0000400 6f 72 40 77 6e 67 2e 6f 72 67 3e 0a o r @ w n g . o r g > \n 0000414 -- Doug I am occasionally finding some strange characters in the log file. I have captured on entry that vi cannot handle. It simply won't go past this record. I suspect the issue is around 0347 in the record below. Any ideas how to prevent this from happening as it makes it difficult to find specific records in the log. vi is unable to delete the line with this issue. mail# head -1 imaplog.test | od -t x1c 0000000 4a 75 6c 20 31 37 20 30 32 3a 33 34 3a 35 35 20 J u l 1 7 0 2 : 3 4 : 5 5 0000020 6d 61 69 6c 20 64 6f 76 65 63 6f 74 5b 35 32 39 m a i l d o v e c o t [ 5 2 9 0000040 30 5d 3a 20 69 6d 61 70 28 64 6f 75 67 29 5b 31 0 ] : i m a p ( d o u g ) [ 1 0000060 30 2e 30 2e 31 2e 32 33 32 5d 3c 4e 74 79 78 52 0 . 0 . 1 . 2 3 2 ] < N t y x R 0000100 4d 74 57 4e 64 38 4b 41 41 48 6f 3e 3a 20 64 65 M t W N d 8 K A A H o > : d e 0000120 6c 65 74 65 3a 20 62 6f 78 3d 44 65 6c 65 74 65 l e t e : b o x = D e l e t e 0000140 64 20 4d 65 73 73 61 67 65 73 2c 20 75 69 64 3d d M e s s a g e s , u i d = 0000160 35 38 32 32 31 33 2c 20 6d 73 67 69 64 3d 3c 39 5 8 2 2 1 3 , m s g i d = < 9 0000200 31 30 35 30 36 39 31 2e 31 34 37 36 39 34 36 2e 1 0 5 0 6 9 1 . 1 4 7 6 9 4 6 . 0000220 31 37 38 33 35 38 37 39 33 35 37 36 36 40 6d 61 1 7 8 3 5 8 7 9 3 5 7 6 6 @ m a 0000240 72 6b 65 74 6f 2d 70 6c 61 74 66 6f 72 6d 2d 2d r k e t o - p l a t f o r m - - 0000260 65 6d 61 69 6c 2d 73 65 6e 64 65 72 2d 70 72 6f e m a i l - s e n d e r - p r o 0000300 64 2d 62 61 74 63 68 2d 63 6c 75 2e 2e 2e 2c 20 d - b a t c h - c l u . . . , 0000320 73 69 7a 65 3d 35 35 39 39 30 2c 20 66 72 6f 6d s i z e = 5 5 9 9 0 , f r o m 0000340 3d 57 4f 52 4c 44 e2 4d 2d 5e 40 4d 2d 5e 59 73 = W O R L D 342 M - ^ @ M - ^ Y s 0000360 20 54 69 6d 20 4c 61 6d 65 72 20 3c 65 64 69 74 T i m L a m e r < e d i t 0000400 6f 72 40 77 6e 67 2e 6f 72 67 3e 0a o r @ w n g . o r g > \n 0000414 -- Doug

2 4

AW: AW: [EXT] Re: doveadm backup / purge problems since migration from 2.3 to 2.4
by MK 21 Jul '26

21 Jul '26

>>> On 09/07/2026 13:30 EEST MK <dovecot-ml(a)mk.de> wrote: >>> >>> >>> >> On 09/07/2026 11:58 EEST MK via dovecot <dovecot(a)dovecot.org>> wrote: >>> >> >>> >> >>> >> Hi everyone, >>> >> >>> >> I have a two-server setup where all user data from the actively used server is periodically transferred to the second server using "doveadm >backup". For this, I currently use a script that caches a list of all users (containing only the usernames) via "doveadm user '*' " and then >executes the command "doveadm backup -u [username] tcp:1.2.3.4" (target host) for each user. I use a similarly structured script for a daily >"doveadm purge", where a purge is performed per user instead of a backup. >>> >> >>> >> Under version 2.3, I always ran both commands using the "-A" flag (doveadm purge -A and doveadm backup -A tcp:1.2.3.4). Since migrating >from Dovecot 2.3 to 2.4, this no longer works. When running the purge, the process always aborts after a certain number of users with the >following error message: >>> >> >>> >> doveadm(john(a)doe.de): Error: auth-master: userdb list: User listing returned failure >>> >> >>> >>> >>> >Try adding >>> > >>> >log_debug=category=auth >>> > >>> >and see if it can shed light one this. >>> >>> I'll add it to the config and get back next time the problem occurs. >>> >>> >> It's not the same User allways but after nearly the same time or amount of users the script has processed. >>> >> Since I couldn't identify the exact cause of the error and suspect it might be related to changes in how the SQL iterate query is >integrated in the 2.4 configuration (I use MySQL as the backend) I switched to the script described above. >>> >> >>> >> Then since is used the new script I have a non-reproducible issue. After the initial data transfer (when the target is still empty) the >amount of data is equal to the source. Then after one of the next transfers the data is twice as high. It is random as to which subsequent >transfer triggers this. When comparing the quotas on the source and target server, the output is identical on both. Even running `quota recalc` >makes no difference. If I check the user directories, I can see that the `storage` folder contains nearly double the number of files and used >disk space per user. >>> >> >>> >> My second problem is that when I run the purge script on the second server (target), it sometimes deletes all emails for all users, also >non-reproducible. Afterwards, all files under "storage" are gone, and the quota shows 0 emails. I did not have this issue with the exactly same >purge script on the first server which is the source for the backup. >>> >> >>> >>> >What does your purge script do? >>> >>> I have attached it so you can take a look. >>> Is it a known issue that the -A option doesn't work as well as it did in 2.3? >>> >>> >> >>And you are sure it's the purge doing it, and not running doveadm sync? > >If you mean delete everything, yes. There is nothing else running there. No other scripts, nothing other is accessing Dovecot. >A few times I have seen it live and the other times I can see in my logging that when the script starts the space is sinking and sinking near to >zero until the script ends. I'm logging the disk space every minute. > >It’s clear that these are two different problems right? (purge deletes everything and backup writes to mutch data) > >What do I have to search for in the logfiles if the problem oncours? What is interesting for you? The debug makes realy mutch log entries. Update to this. Since I activated the debugging on 09/07/2026 the problem did not occur again, really strange. I can't explain it sice I haven't changed anything other than enabling debugging. Oliver

1 0

Sieve vnd.dovecot.config extension does not work when mail is delivered to lmtp inet_listener but works when delivered to lmtp unix_listener
by DK 20 Jul '26

20 Jul '26

Hello. I have a strange problem with sieve scripts vnd.dovecot.config extension processing on newest dovecot 2.3 and 2.4. When I deliver mail via lmtp unix_listener sieve script can get sieve_env_* variable with no problem. However when I deliver mail via lmtp inet_listener sieve script can not get the same sieve_env_* variable. I deliver mails from postfix to lmtp inet_listener directly (not via haproxy). The same postfix is used when testing lmtp unix_listener mail delivery which works. Any clues what could be the cause of such problem? DK

2 3

How to use sieve_env_ variables in 2.4.4?
by inaugurator＠ya.ru 16 Jul '26

16 Jul '26

Hi Dear Devs! In the previous version 2.3.x I used variables with the **sieve_env_** prefix to access them later in Sieve scripts, for example `sieve_env_hello = hello` changed to `"${env.vnd.dovecot.config.hello}"`. But now I am getting an error ``` doveconf: Fatal: Error in configuration file /etc/dovecot/dovecot.conf line 11: sieve_env_hello: Unknown setting: sieve_env_hello ``` Thank you in advance!

2 2

dsync does not like sieve
by Stéphane Veyret 14 Jul '26

14 Jul '26

Hi, I’m using Dovecot for many years. My installation is configured to manage spam using sieve. In the same time, I have a backup server, connecting to the main server every night in order to backup emails (note that the main server is not pushing its data, but the backup server is pulling them). Dovecot v2.4 made me re-write the configuration files, so maybe I missed something, but since then, I cannot make both these service work in the same time. With my current configuration, the backup server is terminating in error with the following logs: dsync-remote(example(a)example.com)<HbkSGoKQG2o8+gEAGKlOPA>: Error: brain S: Exporting mailbox INBOX failed: Mailbox attribute iteration failed: Internal error occurred. Refer to server log for more information. [2026-05-31 03:36:03] (and there are no more logs anywhere). Because this message <https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/MGCGR…> was suggesting there could be a problem with sieve, I tried to modify the configuration. And indeed, when changing sieve configuration, the backup is working again. But then, my spam filter isn’t anymore. Here are the relevant parts of the configuration for managing sieve. Can someone help me saying what could be wrong? protocols { sieve = yes imap = yes lmtp = yes } sieve_extensions { fileinto = yes reject = yes envelope = yes encoded-character = yes vacation = yes subaddress = yes comparator-i;ascii-numeric = yes relational = yes regex = yes imap4flags = yes copy = yes include = yes body = yes variables = yes enotify = yes environment = yes mailbox = yes date = yes index = yes ihave = yes duplicate = yes mime = yes foreverypart = yes extracttext = yes vnd.dovecot.pipe = yes vnd.dovecot.environment = yes } sieve_pipe_bin_dir = /etc/dovecot/sieve sieve_pipe_socket_dir = sieve-pipe sieve_plugins { sieve_imapsieve = yes sieve_extprograms = yes } service managesieve-login { inet_listener sieve { port = 4190 } } sieve_script personal { } sieve_script default { path = /etc/dovecot/sieve/spam.sieve } protocol imap { mail_plugins { acl = yes quota = yes imap_acl = yes imap_quota = yes imap_sieve = yes } } protocol lmtp { mail_plugins { acl = yes quota = yes sieve = yes } } namespace user { inbox = yes prefix = separator = / type = private mailbox * { sieve_script reportspam { cause = flag path = /etc/dovecot/sieve/report-spam.sieve type = before } } } Thank you. Stéphane -- Bien cordialement, / Plej kore, Stéphane Veyret Hi, I'm using Dovecot for many years. My installation is configured to manage spam using sieve. In the same time, I have a backup server, connecting to the main server every night in order to backup emails (note that the main server is not pushing its data, but the backup server is pulling them). Dovecot v2.4 made me re-write the configuration files, so maybe I missed something, but since then, I cannot make both these service work in the same time. With my current configuration, the backup server is terminating in error with the following logs: dsync-remote([1]example(a)example.com)<HbkSGoKQG2o8+gEAGKlOPA>: Error: brain S: Exporting mailbox INBOX failed: Mailbox attribute iteration failed: Internal error occurred. Refer to server log for more information. [2026-05-31 03:36:03] (and there are no more logs anywhere). Because [2]this message was suggesting there could be a problem with sieve, I tried to modify the configuration. And indeed, when changing sieve configuration, the backup is working again. But then, my spam filter isn't anymore. Here are the relevant parts of the configuration for managing sieve. Can someone help me saying what could be wrong? protocols { sieve = yes imap = yes lmtp = yes } sieve_extensions { fileinto = yes reject = yes envelope = yes encoded-character = yes vacation = yes subaddress = yes comparator-i;ascii-numeric = yes relational = yes regex = yes imap4flags = yes copy = yes include = yes body = yes variables = yes enotify = yes environment = yes mailbox = yes date = yes index = yes ihave = yes duplicate = yes mime = yes foreverypart = yes extracttext = yes vnd.dovecot.pipe = yes vnd.dovecot.environment = yes } sieve_pipe_bin_dir = /etc/dovecot/sieve sieve_pipe_socket_dir = sieve-pipe sieve_plugins { sieve_imapsieve = yes sieve_extprograms = yes } service managesieve-login { inet_listener sieve { port = 4190 } } sieve_script personal { } sieve_script default { path = /etc/dovecot/sieve/spam.sieve } protocol imap { mail_plugins { acl = yes quota = yes imap_acl = yes imap_quota = yes imap_sieve = yes } } protocol lmtp { mail_plugins { acl = yes quota = yes sieve = yes } } namespace user { inbox = yes prefix = separator = / type = private mailbox * { sieve_script reportspam { cause = flag path = /etc/dovecot/sieve/report-spam.sieve type = before } } } Thank you. Stephane -- Bien cordialement, / Plej kore, Stephane Veyret References Visible links 1. mailto:example@example.com 2. https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/MGCGR…

3 8

imap-sieve, question concerning "sieve_user_email" and variables, migration from 2.3 to 2.4
by Claus-Justus Heine 14 Jul '26

14 Jul '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 3

NFC normalization rename errors after 2.3 to 2.4 upgrade (mdbox)
by Jan Münnich 14 Jul '26

14 Jul '26

Hi, We just upgraded from 2.3 to 2.4.3 and are now getting errors like this for any mailbox with German umlauts in the name: "Error: Failed to rename mailbox 'Anträge' for NFC normalization: Mailbox doesn't exist: Anträge" The mailboxes work fine otherwise, doveadm mailbox status shows them with correct message counts. The errors show up on IMAP access but don't seem to break anything. We're using mdbox. On disk the directory is stored as mUTF-7: Antr&AOQ-ge doveadm mailbox list gives back the name with c3 a4 for the ä, which is already NFC. We double-checked with python3 unicodedata and it confirms the name is NFC. So it seems like dovecot is trying to rename something that doesn't need renaming, and then failing. Is there a way to turn off this automatic rename? Or is this a known issue with mdbox and mUTF-7 directory names? Any help would be appreciated to find out if this is a bug or a configuration issue on our side! Thanks, Jan

5 11

crash in sieve-filter with 2.4.4
by Noah Meyerhans 13 Jul '26

13 Jul '26

Forwarded from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1139275 A certain poison pill message seems to crash sieve-filter. A reproducer script, email message, and sieve script are at https://salsa.debian.org/noahm/dovecot/-/tree/sieve-crash/debian/tests/siev… The problem is not reproducible with 2.4.1, so it seems to be a regression introduced since then. Coredump details follow: root@dovecot-test:/home/noahm/dovecot# coredumpctl info | cat PID: 110911 (sieve-filter) TID: 110911 (sieve-filter) UID: 65534 (nobody) GID: 65534 (nogroup) Signal: 6 (ABRT) Timestamp: Mon 2026-06-08 19:16:37 UTC (29s ago) Command Line: sieve-filter -u dep8 -e -W -D -C -v /srv/dovecot-dep8/test.sieve INBOX Executable: /usr/bin/sieve-filter Control Group: /user.slice/user-1000.slice/session-5.scope Unit: session-5.scope Slice: user-1000.slice Session: 5 Owner UID: 1000 (noahm) Boot ID: 46469969e01043559d913ef8ab625856 Machine ID: a497a098bd094c1c8f7c8ed02aa21853 Hostname: dovecot-test Storage: /var/lib/systemd/coredump/core.sieve-filter.65534.46469969e01043559d913ef8ab625856.110911.1780946197000000.zst (present) Size on Disk: 253.5K Message: Process 110911 (sieve-filter) of user 65534 dumped core. Module libgcc_s.so.1 from deb gcc-16-16.1.0-1.amd64 Module libstdc++.so.6 from deb gcc-16-16.1.0-1.amd64 Stack trace of thread 110911: #0 0x00007fe06b09fcfc n/a (libc.so.6 + 0x97cfc) #1 0x00007fe06b048d02 raise (libc.so.6 + 0x40d02) #2 0x00007fe06b0304b2 abort (libc.so.6 + 0x284b2) #3 0x00007fe06b26ed45 n/a (libdovecot.so.0 + 0x6ed45) #4 0x00007fe06b357597 default_fatal_handler (libdovecot.so.0 + 0x157597) #5 0x00007fe06b26ec72 i_panic (libdovecot.so.0 + 0x6ec72) #6 0x00007fe06b273b90 n/a (libdovecot.so.0 + 0x73b90) #7 0x00007fe06b3498fb n/a (libdovecot.so.0 + 0x1498fb) #8 0x00007fe06b34a784 n/a (libdovecot.so.0 + 0x14a784) #9 0x00007fe06b34a93b buffer_append (libdovecot.so.0 + 0x14a93b) #10 0x00007fe06b344cc6 dregex_code_match_groups (libdovecot.so.0 + 0x144cc6) #11 0x00007fe06b806a27 n/a (libdovecot-sieve.so.0 + 0x6da27) #12 0x00007fe06b806cd0 n/a (libdovecot-sieve.so.0 + 0x6dcd0) #13 0x00007fe06b7ee411 sieve_match_value (libdovecot-sieve.so.0 + 0x55411) #14 0x00007fe06b7ee711 sieve_match (libdovecot-sieve.so.0 + 0x55711) #15 0x00007fe06b7f5862 n/a (libdovecot-sieve.so.0 + 0x5c862) #16 0x00007fe06b7eccde sieve_interpreter_continue (libdovecot-sieve.so.0 + 0x53cde) #17 0x00007fe06b7fbfbe sieve_execute (libdovecot-sieve.so.0 + 0x62fbe) #18 0x00005638c0022fcf main (sieve-filter + 0x3fcf) #19 0x00007fe06b031f77 n/a (libc.so.6 + 0x29f77) #20 0x00007fe06b032027 __libc_start_main (libc.so.6 + 0x2a027) #21 0x00005638c0023791 _start (sieve-filter + 0x4791) ELF object binary architecture: AMD x86-64

2 1

sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
by michael.merz＠wtnet.de 11 Jul '26

11 Jul '26

Hello, I've been evaluating sieve-test (Pigeonhole, dovecot-sieve package, version 2.3.21, as shipped with Ubuntu 24.04 LTS) as an offline testing tool for a personal Sieve ruleset that currently runs on a Cyrus IMAPd/CMU Sieve 3.0 backend. I'd like to ask for some clarification on two points, in case I'm missing a configuration option. 1) PCRE support My ruleset makes extensive use of the `(?i)` inline case-insensitivity flag within :regex tests, which is valid under PCRE (as used by Cyrus). When running sieve-test, I get: error: invalid regular expression '(?i)...' for regex match: invalid preceding regular expression. Checking `dovecot --build-options` shows no PCRE entry, which suggests the Ubuntu-packaged binary was compiled without --with-pcre and falls back to POSIX extended regex. Question: Is PCRE support in Pigeonhole's regex extension purely a compile-time decision (i.e. something that would need to be addressed at the distribution packaging level, not via runtime configuration), or is there a runtime way to enable PCRE matching that I might have missed (e.g. via -o, sieve_extensions, or similar)? 2) Return-Path in the `address` test Several of my rules use: address :domain :is "return-path" "..." Cyrus accepts this. Pigeonhole's sieve-test rejects it with: error: specified header 'return-path' is not allowed for the address test. I understand this is likely an RFC 5228 strictness difference (Cyrus being more permissive than the RFC requires). Is there a recommended alternative within Sieve itself to achieve the same effect (testing the address portion of Return-Path) while staying within what Pigeonhole accepts - e.g. via the `header` test combined with some address-parsing approach, or via the envelope test instead? For context: I'm not running a Dovecot mail server myself. I'm using sieve-test purely as an offline syntax/behaviour verification tool before deploying ruleset changes to a separate Cyrus-based production system. I understand this is a bit of an unusual use case, so any guidance on whether Pigeonhole is well suited for this kind of cross-implementation testing at all would also be appreciated. Thank you for your time and for maintaining Pigeonhole. Best regards, Michael Merz Hello, I've been evaluating sieve-test (Pigeonhole, dovecot-sieve package, version 2.3.21, as shipped with Ubuntu 24.04 LTS) as an offline testing tool for a personal Sieve ruleset that currently runs on a Cyrus IMAPd/CMU Sieve 3.0 backend. I'd like to ask for some clarification on two points, in case I'm missing a configuration option. 1) PCRE support My ruleset makes extensive use of the `(?i)` inline case-insensitivity flag within :regex tests, which is valid under PCRE (as used by Cyrus). When running sieve-test, I get: error: invalid regular expression '(?i)...' for regex match: invalid preceding regular expression. Checking `dovecot --build-options` shows no PCRE entry, which suggests the Ubuntu-packaged binary was compiled without --with-pcre and falls back to POSIX extended regex. Question: Is PCRE support in Pigeonhole's regex extension purely a compile-time decision (i.e. something that would need to be addressed at the distribution packaging level, not via runtime configuration), or is there a runtime way to enable PCRE matching that I might have missed (e.g. via -o, sieve_extensions, or similar)? 2) Return-Path in the `address` test Several of my rules use: address :domain :is "return-path" "..." Cyrus accepts this. Pigeonhole's sieve-test rejects it with: error: specified header 'return-path' is not allowed for the address test. I understand this is likely an RFC 5228 strictness difference (Cyrus being more permissive than the RFC requires). Is there a recommended alternative within Sieve itself to achieve the same effect (testing the address portion of Return-Path) while staying within what Pigeonhole accepts -- e.g. via the `header` test combined with some address-parsing approach, or via the envelope test instead? For context: I'm not running a Dovecot mail server myself. I'm using sieve-test purely as an offline syntax/behaviour verification tool before deploying ruleset changes to a separate Cyrus-based production system. I understand this is a bit of an unusual use case, so any guidance on whether Pigeonhole is well suited for this kind of cross-implementation testing at all would also be appreciated. Thank you for your time and for maintaining Pigeonhole. Best regards, Michael Merz

4 13

Client sent invalid input for CATEGORY
by Mail Operations 09 Jul '26

09 Jul '26

Hello list We are running a dovecot 2.4 instance and the following errors start to pop up after a listener is configured to scrape metrics with Prometheus: ... dovecot[2090309]: stats: Error: conn unix:stats (pid=2090333,uid=108): Client sent invalid input for CATEGORY: Category parent 'ssl' changed to 'ssl' (input: CATEGORY ssl-client ssl) Stats listener config: service stats { inet_listener http { port = 9090 ssl = yes } } So far I failed to reliably trigger the error messages and it looks like they appear randomly. Besides the logged errors, everything seems to work correctly. Could this be a possible bug, or configuration error? Kind regards, Patrik

2 2

doveadm backup / purge problems since migration from 2.3 to 2.4
by MK 09 Jul '26

09 Jul '26

Hi everyone, I have a two-server setup where all user data from the actively used server is periodically transferred to the second server using "doveadm backup". For this, I currently use a script that caches a list of all users (containing only the usernames) via "doveadm user '*' " and then executes the command "doveadm backup -u [username] tcp:1.2.3.4" (target host) for each user. I use a similarly structured script for a daily "doveadm purge", where a purge is performed per user instead of a backup. Under version 2.3, I always ran both commands using the "-A" flag (doveadm purge -A and doveadm backup -A tcp:1.2.3.4). Since migrating from Dovecot 2.3 to 2.4, this no longer works. When running the purge, the process always aborts after a certain number of users with the following error message: doveadm(john(a)doe.de): Error: auth-master: userdb list: User listing returned failure It's not the same User allways but after nearly the same time or amount of users the script has processed. Since I couldn't identify the exact cause of the error and suspect it might be related to changes in how the SQL iterate query is integrated in the 2.4 configuration (I use MySQL as the backend) I switched to the script described above. Then since is used the new script I have a non-reproducible issue. After the initial data transfer (when the target is still empty) the amount of data is equal to the source. Then after one of the next transfers the data is twice as high. It is random as to which subsequent transfer triggers this. When comparing the quotas on the source and target server, the output is identical on both. Even running `quota recalc` makes no difference. If I check the user directories, I can see that the `storage` folder contains nearly double the number of files and used disk space per user. My second problem is that when I run the purge script on the second server (target), it sometimes deletes all emails for all users, also non-reproducible. Afterwards, all files under "storage" are gone, and the quota shows 0 emails. I did not have this issue with the exactly same purge script on the first server which is the source for the backup. The version change was during the update from Debian 12 to 13, involving an upgrade of Dovecot from version 2.3.19 to 2.4.1. (both packages from debian repo) We use MySQL as the backend and mdbox as the storage format. I hope some can help me to solve this issue. Greetings, Oliver

2 1

Bug report: doveadm kick does not kick proxy sessions
by Patrick Cernko 06 Jul '26

06 Jul '26

Hi Dovecot Devs, I'm currently setting up Dovecot 2.4 as frontend proxy to our backends. The frontends simply use an LDAP attribute of the user to connect to the assigned IMAP backend server. That works fine so far. According to the documentation <https://doc.dovecot.org/2.4.4/core/man/doveadm-kick.1.html>, I should be able to disconnect a user with doveadm kick USERNAME or all sessions to a specific backend with doveadm kick -h BACKEND_IP or simply ALL sessions with doveadm kick '*' However the command reports the expected amount of connections kicked and exitcode 0, but all sessions stay connected. I also tried 'doveadm proxy kick ...' but as the the corresponding documentation states, this is only an alias for 'doveadm kick ...' and thus shows the same behavior. In the previous Dovecot 2.3 setup 'doveadm proxy kick' is not yet an alias for 'doveadm kick' and works as expected by disconnection the specified proxy sessions. 'doveadm kick' behaves similar to Dovecot 2.4 (not kicking proxy sessions) but that is understandable given that the documentation describes the dedicated kick command for proxy sessions. If this is the intended behavior for 'doveadm kick', how can I disconnect specific *proxy* sessions? If this is a bug, could you please fix it in the next releases or at least provide a patch that I can apply on my own build? I verified the bug exists in the latest dovecot packages for Debian Trixie from repo.dovecot.org. Attached is the doveconf -n output for my test setup. Best regards, -- Patrick Cernko <pcernko(a)mpi-klsb.mpg.de> +49 681 9325 5815 Joint Scientific IT and Technical Service Max-Planck-Institute für Informatik & Softwaresysteme

2 3

The SORT extension in 2.4.4 over imapc never returns any UIDs
by inaugurator＠ya.ru 29 Jun '26

29 Jun '26

Hi guys! This is really annoying. On the command to dovecot over imapc from another one: "UID SEARCH ALL" I get my UIDs: "* SEARCH 1 2 3 4" But when sending: "UID SORT (REVERSE ARRIVAL) US-ASCII NOT DELETED" I get literally nothing: "* SORT" Sorry, but this is a bug. Thank you!

3 7

How to use two databases in two passdb sections
by Евгений 26 Jun '26

26 Jun '26

Hello everyone! In version 2.3.21, I used two databases where each passdb queried its own database. After upgrading to 2.4.4, I cannot figure out how to restore this functionality. Is it no longer possible to use two databases in a single configuration after upgrade? Thank you for the best MDA!

3 2

Issues with syncing of shared mailboxes
by fc26wuqa＠studserv.uni-leipzig.de 26 Jun '26

26 Jun '26

Hello, I have a two users, that have a personal mailbox and a shared mailbox. They have access to the same shared mailbox. Today they notified me, that a mail send to the shared mailbox exists for the one user but not the other. The user also notified me, that some mails are not being delivered. I haven't found anything in my log files and the postmaster has also no delivery failures. I relay my mails through another server I don't have access to though. My /etc/aliases only consists of `postmaster: root`. The relay owners said that I should change postfix' main.cf to `double_bounce_sender = postmaster` a while ago. I am also not sure if I am not getting any delivery failure notifications since then, since I don't have a `postmaster` account, but I thought this is not needed since I have the above line in `/etc/aliases`. I also tried forcing a resync of their shared and non-shared inboxes with: `doveadm force-resync -u user(a)emaildomain.com INBOX` as well as `doveadm force-resync -u user(a)emaildomain.com Shared` (as well as with `Shared\*` - I don't know if that makes a difference tbh). Here is the output of `dovecot -n`: https://bin.disroot.org/?4eac9ea90a72ff08#A2dim9VGqHAjjKcggF4ScFWpbGytePZjt… I am kind of lost where to start from here, because any other person I asked told me their mail worked fine ^^. I would highly appreciate some guidance :) Thank you. Best, Lucienne

1 0

Convert sqlite configuration from 2.3 to 2.4
by Horst B Simon 24 Jun '26

24 Jun '26

Hi, I succesful converted all configurations from dovecot 2.3 to 2.4, except for the sqlite configuration. I googled and all configuration are for mysql/mariadb and not for sqlite. The sqlite database is created with postfixadmin and my current configuration for dovecot 2.3 (dovecot-sql.conf.ext) is: driver = sqlite connect = /var/mail/postfixadmin.db default_pass_scheme = DES-CRYPT password_query = \ SELECT username as user, password, '/var/mail/%d/%n' as userdb_home, \ 'maildir:/var/mail/%n' as userdb_mail, 5000 as userdb_uid, 5000 as userdb_gid \ FROM mailbox WHERE username = '%u' AND active = '1' user_query = \ SELECT '/var/mail/%d/%n' as home, 'maildir:/var/mail/%n' as mail, \ 5000 AS uid, 5000 AS gid, printf('dirsize:storage=', quota) AS quota \ FROM mailbox WHERE username = '%u' AND active = '1' I tried the only converter, but it didn’t do any conversion. Any help appreciated. Thanks and Regards, Horst Hi, I succesful converted all configurations from dovecot 2.3 to 2.4, except for the sqlite configuration. I googled and all configuration are for mysql/mariadb and not for sqlite. The sqlite database is created with postfixadmin and my current configuration for dovecot 2.3 (dovecot-sql.conf.ext) is: driver = sqlite connect = /var/mail/postfixadmin.db default_pass_scheme = DES-CRYPT password_query = \ SELECT username as user, password, '/var/mail/%d/%n' as userdb_home, \ 'maildir:/var/mail/%n' as userdb_mail, 5000 as userdb_uid, 5000 as userdb_gid \ FROM mailbox WHERE username = '%u' AND active = '1' user_query = \ SELECT '/var/mail/%d/%n' as home, 'maildir:/var/mail/%n' as mail, \ 5000 AS uid, 5000 AS gid, printf('dirsize:storage=', quota) AS quota \ FROM mailbox WHERE username = '%u' AND active = '1' I tried the only converter, but it didn't do any conversion. Any help appreciated. Thanks and Regards, Horst

2 2

Incomplete Dovecot Log Entries
by Bryan Simmons 19 Jun '26

19 Jun '26

There are hundreds of dovecot “Disconnected: Connection closed” messages in the log file that do not have a corresponding connect record. Is this normal or are there configuration options that need to be modified? Note the user accounts listed, and other similar records, do not exist on this server. 2026-06-14T02:11:48.843517-04:00 mail dovecot: imap-login: Disconnected: Connection closed (auth failed, 3 attempts in 23 secs): user=<rantanplan_admin(a)nanomail.net>, method=PLAIN, rip=190.181.120.152, lip=10.0.1.211, TLS, session=<T8xvlDBUnNC+tXiY> 2026-06-14T02:12:16.614611-04:00 mail dovecot: imap-login: Disconnected: Connection closed (auth failed, 3 attempts in 24 secs): user=<rantanplan_admin>, method=PLAIN, rip=41.139.10.25, lip=10.0.1.211, TLS, session=<cvoGljBUS+YpiwoZ> 2026-06-14T03:23:55.523146-04:00 mail dovecot: imap-login: Disconnected: Connection closed (auth failed, 3 attempts in 23 secs): user=<rantanplan.info(a)nanomail.net>, method=PLAIN, rip=103.69.9.148, lip=10.0.1.211, TLS, session=<SOBYljFUlsdnRQmU> Thanks, Bryan

1 0

Lazy-Expunge plugin documentation incomplete?
by Randolf Richardson 17 Jun '26

17 Jun '26

One of the Dovecot repository maintainers on GitHub recommended sending an eMail to you regarding the issue I encountered: Documentation for lazy-expunge doesn't work https://github.com/dovecot/documentation/issues/1555 -------- I converted from Dovecot 2.3 to Dovecot 2.4.1, which was not a minor upgrade. Anyway, I can't get the lazy-expunge plugin to work in 2.4.1 now. Here's my configuration file from 2.3 -- how can I get this working in 2.4.1? Thanks. namespace inbox { mailbox EXPUNGED { autoexpunge = 32days autoexpunge_max_mails = 100000 #auto = create } } # Namespace for lazy_expunge plugin namespace { prefix = EXPUNGED/ hidden = yes list = no subscriptions = no separator = / location = maildir:~/Maildir.deleted:INDEX= } mail_plugins = $mail_plugins lazy_expunge acl plugin { # Move expunged messages into the .EXPUNGED namespace lazy_expunge = EXPUNGED/ # Only move to expunged storage if this is the last copy of the message in the user´s account lazy_expunge_only_last_instance = yes # Exclude Drafts from lazy expunging lazy_expunge_exclude = \Drafts # Copy of each message is done with hard links whenever possible maildir_copy_with_hardlinks = yes # Define ACL so that user cannot list the .EXPUNGED mailbox # Example entry: .EXPUNGED owner rwstipekxa acl = vfile:/etc/dovecot/dovecot.acl # dovecot.acl contains one line: EXPUNGED owner ip # Expunged messages most likely don't want to be included in quota: quota_rule = EXPUNGED:ignore } #lazy_expunge_mailbox = EXPUNGED Here's an example of someone else who encountered the same problem: https://www.dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thr ead/25BXSHQWGQQ3ACVZSYF3O3LC4WROTUCI/ Randolf Richardson, CNA - randolf(a)inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Beautiful British Columbia, Canada https://www.inter-corporate.com/

2 2

Announcing nauthilus-director: a Nauthilus-backed mail protocol director
by Christian Rößner 17 Jun '26

17 Jun '26

Hi, I would like to announce `nauthilus-director` for the first time on this list. `nauthilus-director` is an open-source mail protocol director and transparent proxy for Nauthilus-backed mail deployments. It sits in front of stateful mail backends, authenticates frontend sessions through Nauthilus, resolves routing and placement inside the director, selects healthy backend services, keeps active user affinity in Redis, and then proxies the established connection to the selected backend. The current focus is on deployments where backend placement, maintenance, drains, user movement and session affinity need to be explicit, observable and controllable. The director is not a mailbox server and not a general-purpose load balancer; it owns the narrow director responsibilities between clients, Nauthilus and backend mail services. Current capabilities include: - IMAP/IMAPS, POP3/POP3S, LMTP/LMTPS and ManageSieve proxying - Nauthilus-backed authentication over HTTP or gRPC - director-owned routing and backend selection - Redis-backed session affinity and runtime coordination - backend health, maintenance, runtime drains and placement overrides - an OpenAPI-based REST control API and `nauthilus-directorctl` - metrics, structured logging and OpenTelemetry tracing The demo stack includes Dovecot backend shards and exercises real IMAP, LMTP, POP3 and ManageSieve paths, so feedback from Dovecot operators would be especially useful. Related to this, Nauthilus itself has recently been released as version 3.0.0. Nauthilus is the central authentication and policy engine in this setup: it provides centralized authentication and identity handling for mail and web workloads, LDAP-backed or Lua-driven policy decisions, OIDC/SAML IdP functionality, MFA support, and Redis-backed state handling. In the director architecture, Nauthilus remains the authentication and policy authority, while `nauthilus-director` owns concrete backend placement and proxy lifecycle decisions. Project links: - nauthilus-director: https://github.com/croessner/nauthilus-director - Nauthilus: https://github.com/croessner/nauthilus - Documentation / website: https://nauthilus.org The director is still young, so I would be interested in feedback from people running Dovecot-backed infrastructures, especially around operational workflows, backend maintenance, migration scenarios and protocol behavior. The director is still in beta. Best regards, Christian Rößner -- Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.website PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5 Hi, I would like to announce `nauthilus-director` for the first time on this list. `nauthilus-director` is an open-source mail protocol director and transparent proxy for Nauthilus-backed mail deployments. It sits in front of stateful mail backends, authenticates frontend sessions through Nauthilus, resolves routing and placement inside the director, selects healthy backend services, keeps active user affinity in Redis, and then proxies the established connection to the selected backend. The current focus is on deployments where backend placement, maintenance, drains, user movement and session affinity need to be explicit, observable and controllable. The director is not a mailbox server and not a general-purpose load balancer; it owns the narrow director responsibilities between clients, Nauthilus and backend mail services. Current capabilities include: - IMAP/IMAPS, POP3/POP3S, LMTP/LMTPS and ManageSieve proxying - Nauthilus-backed authentication over HTTP or gRPC - director-owned routing and backend selection - Redis-backed session affinity and runtime coordination - backend health, maintenance, runtime drains and placement overrides - an OpenAPI-based REST control API and `nauthilus-directorctl` - metrics, structured logging and OpenTelemetry tracing The demo stack includes Dovecot backend shards and exercises real IMAP, LMTP, POP3 and ManageSieve paths, so feedback from Dovecot operators would be especially useful. Related to this, Nauthilus itself has recently been released as version 3.0.0. Nauthilus is the central authentication and policy engine in this setup: it provides centralized authentication and identity handling for mail and web workloads, LDAP-backed or Lua-driven policy decisions, OIDC/SAML IdP functionality, MFA support, and Redis-backed state handling. In the director architecture, Nauthilus remains the authentication and policy authority, while `nauthilus-director` owns concrete backend placement and proxy lifecycle decisions. Project links: - nauthilus-director: https://github.com/croessner/nauthilus-director - Nauthilus: https://github.com/croessner/nauthilus - Documentation / website: https://nauthilus.org The director is still young, so I would be interested in feedback from people running Dovecot-backed infrastructures, especially around operational workflows, backend maintenance, migration scenarios and protocol behavior. The director is still in beta. Best regards, Christian Roessner -- Roessner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.website PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5

3 3

Announcement: wormhole plugin, replication for Dovecot 2.4
by Patrick Cernko 12 Jun '26

12 Jun '26

Hello List, I am proud to announce my project "wormhole". This is an extension for Dovecot 2.4.1. It allows to continue the use of the replication feature of Dovecot that was removed with the 2.4 release. History: I started this project by forking the replication code of Dovecot 2.3.21.1 and porting it to 2.4. The first result was a patch for Dovecot 2.4.1. While working with the code, I realized that it is possible to provide the feature as a plugin / extension. In the first release of the plugin, I tried to integrate it with the existing dsync commands for doveadm. This required an API for access to the dsync commands, which I proposed to the Dovecot developers in https://github.com/dovecot/core/pull/249 . Unfortunately, my pull request was rejected, though I can understand the reasons for that. Without the required API, I had to switch to another approach: I forked the dsync code from doveadm to provide a new set of commands: "repl" and "repl-server". These commands work similar to "sync" and "dsync-server" but use additional functions required by the replication feature. This approach was released as version 0.3 of the plugin. With version 0.4 I renamed the project to wormhole. Before that it was just called dovecot-replication (see https://codeberg.org/errror/dovecot-replication) I thought that the project should have a more unique name. Currently I'm working on designing a test suite for wormhole. Doing unit tests of the components is not sufficient IMHO. The test suite should check the whole replication feature using two running dovecot instances that replicate the users' mailboxes. Having a sophisticated test suite will help in future development and bug tracking. The code can be found on my codeberg site at: https://codeberg.org/errror/wormhole There is also a web page on my personal homepage at: https://people.mpi-klsb.mpg.de/~pcernko/wormhole.shtml The project is still missing documentation. For the moment, configuration is similar to the existing Dovecot 2.3 documentation. Upgrading from 2.3: When using the included patch for Dovecot, the plugin should be 100% compatible with existing Dovecot 2.3 servers. This compatibility should allow uninterrupted upgrades of the service by replacing Dovecot on one server and then the other one. After the upgrade, the plugin can be reconfigured to work without the patch for Dovecot. Upgrading without the patch is also possible. During the upgrade (aka "while one server still runs 2.3") some aspects of the replication will not work or lack performance. Upgrading is not yet tested very well and missing documentation also. I will work on that soon. I hope to get some feedback, pull requests or bug reports via mail or at codeberg (preferred). -- Patrick Cernko <pcernko(a)mpi-klsb.mpg.de> +49 681 9325 5815 Joint Scientific IT and Technical Service Max-Planck-Institute für Informatik & Softwaresysteme

4 4

New Backup Issue
by Doug Hardie 11 Jun '26

11 Jun '26

I have dovecot using maildir storage on the mail machine. I have an external drive directly connected to use a backup for the mailboxes. Doveadm backup works perfectly for this setup. I also have two external backup servers. Backup to those tends to fail with a variety of errors. I deleted the Maildir directory on the backup servers and created the original backups with doveadm backup. No issues were reported. However, the next backup generates errors: dsync-remote(jeanne)<HV6JE+i/KWo0NwAAq6l46g>: Warning: Deleting mailbox 'INBOX': UID=11166 GUID=1712570780.M604032P10319.mail,S=99689,W=101000 is missing locally dsync-remote(jeanne)<HV6JE+i/KWo0NwAAq6l46g>: Error: Couldn't delete mailbox INBOX: INBOX can't be deleted. dsync-local(jeanne)<HqU9Aei/KWoBMAAAZU03Dg>: Error: Remote command returned error 65: ssh sermons doveadm dsync-server -ujeanne -U dsync-remote(beneke)<eARRAem/KWpdNwAAq6l46g>: Warning: Deleting mailbox 'INBOX': UID=232 GUID=1641564460.M859673P8687.mail,S=5917,W=6035 is missing locally dsync-remote(beneke)<eARRAem/KWpdNwAAq6l46g>: Error: Couldn't delete mailbox INBOX: INBOX can't be deleted. dsync-local(beneke)<mw5bM+i/KWoJMAAAZU03Dg>: Error: Remote command returned error 65: ssh sermons doveadm dsync-server -ubeneke -U dsync-remote(doug)<6gmSJ+m/KWp7NwAAq6l46g>: Warning: Deleting mailbox 'INBOX': UID=92440 GUID=1465118975.V4eI7cfa32M232845.mail is missing locally dsync-remote(doug)<6gmSJ+m/KWp7NwAAq6l46g>: Error: Couldn't delete mailbox INBOX: INBOX can't be deleted. dsync-local(doug)<hwsCH+m/KWoNMAAAZU03Dg>: Error: Remote command returned error 65: ssh sermons doveadm dsync-server -udoug -U There is always one error per user, but they are different between the two backup machine. With the first error, I found the message 1712570780.M604032P10319.mail,S=99689,W=101000 in the mail server cur directory and deleted it. That messge did not exist in the backup server. I ran backup again and no issues. However, the next backup produced the following error: dsync-remote(jeanne)<dNWXGZbUKWoaOgAAq6l46g>: Warning: Deleting mailbox 'INBOX': UID=11167 GUID=1712574432.M425061P11306.mail,S=45149,W=45775 is missing locally dsync-remote(jeanne)<dNWXGZbUKWoaOgAAq6l46g>: Error: Couldn't delete mailbox INBOX: INBOX can't be deleted. dsync-local(jeanne)<Jg3tCZbUKWp5NQAAZU03Dg>: Error: Remote command returned error 65: ssh sermons doveadm dsync-server -ujeanne -U That message is in the cur directory on the mail server. It is not in the backup server. I don't understand the message that those files are missing locally (primary mail server I presume) when they are actually there and missing on the remote server. I don't know why they didn't get copied originally. The first email was recieved on Mon, 8 Apr 2024 so it can't be a timming issue. -- Doug

2 1

Replication performance question and environment variables sanitization
by Jesus Cea 10 Jun '26

10 Jun '26

Hi, there. I am using dovecot 2.3.21.1. I am experimenting with replication, currently doing it manually, using this: doveadm -Dv sync -u jcea ssh email doveadm dsync-server -u prueba_backup; echo $? It works fine so far, but I have a few hundreds of mailboxes in my imap4 account and an "empty" (no changes) sync takes 30 seconds, since apparently it compare every mailbox (according to the debug info printed). I am using "mdbox" storage in both sides. I would expect an event replication, where time is proportional to the volume of changes, not to the total data volume or number of mailboxes. Am I doing anything wrong?. It would be faster to use "replicator" + "mail_replica". Can I improve this in some way? Replication must be both ways, because in one server new emails are arriving and in the other imapserver I am doing my mail work. I want new email appearing in my work imapserver (living my own laptop) and my email processing to be replicated back to the server for backup/disaster recovery (lost laptop, broken HD) and access from a different laptop, phone, etc. Thanks. PS: By default dovecot sanitizes the environment and doesn't allow "SSH_AUTH_SOCK" for ssh-agent. Why?. That is very inconvenient. I am using this environment variable to overcome that: DOVECOT_PRESERVE_ENVS="HOME USER SSH_AUTH_SOCK SSH_AGENT_PID LOG_STDERR_TIMESTAMP TZ CORE_OUTOFMEM CORE_ERROR" Is this the right way to do this? -- Jesús Cea Avión _/_/ _/_/_/ _/_/_/ jcea(a)jcea.es - https://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ Twitter: @jcea _/_/ _/_/ _/_/_/_/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz

2 3

dovecot 2.4 and Outlook
by Jochen Bern 08 Jun '26

08 Jun '26

Since I don't remember seeing *this* mentioned here so far, but *do* remember people asking about Outlook-dovecot compatibility issues every now and then, here's a potential cause for seeing more of those in the immediate future: https://fedoramagazine.org/fedora-43-upgrade-revealed-20-years-old-outlook-… Kind regards, -- Jochen Bern Systemingenieur Binect GmbH

2 3