- dovecot - dovecot.org

Corrupt index.cache file causes looping and out of memory errors
by Evan Booyens 09 Sep '26

09 Sep '26

Dovecot -n and systems report are attached Log file extries: Sep 9 14:29:32 www23.jnb2.host-h.net dovecot: imap(*****@*******): Error: Mailbox INBOX.Client Correspondence: read() failed with file /usr/www/dovecot_indexes/********.co.za/orders/.Client Correspondence/dovecot.index.cache: Cannot allocate memory Sep 9 14:29:32 www23.jnb2.host-h.net dovecot: imap(*****(a)*******.co.za): Error: mremap_anon(/usr/www/dovecot_indexes/********.co.za/orders/.Client Correspondence/dovecot.index.cache, 967524352) failed: Cannot allocate memory Sep 9 14:29:32 www23.jnb2.host-h.net dovecot: imap(*****@*******): Error: mremap_anon(/usr/www/dovecot_indexes/********.co.za/orders/.Client Correspondence/dovecot.index.cache, 967524352) failed: Cannot allocate memory Sep 9 14:29:32 www23.jnb2.host-h.net dovecot: imap(*****@*******): Error: Mailbox INBOX.Client Correspondence: read() failed with file /usr/www/dovecot_indexes/********.co.za/orders/.Client Correspondence/dovecot.index.cache: Cannot allocate memory Sep 9 14:29:32 www23.jnb2.host-h.net dovecot: imap(*****@*******): Error: mremap_anon(/usr/www/dovecot_indexes/********.co.za/orders/.Client Correspondence/dovecot.index.cache, 967524352) failed: Cannot allocate memory Sep 9 14:29:32 www23.jnb2.host-h.net dovecot: imap(*****(a)*******.co.za): Error: mremap_anon(/usr/www/dovecot_indexes/********.co.za/orders/.Client Correspondence/dovecot.index.cache, 967524352) failed: Cannot allocate memory Sep 9 14:29:32 www23.jnb2.host-h.net dovecot: imap(*****(a)*******.co.za): Error: Mailbox INBOX.Client Correspondence: read() failed with file /usr/www/dovecot_indexes/********.co.za/orders/.Client Correspondence/dovecot.index.cache: Cannot allocate memory Evan Booyens Linux Platform Engineer xneelo (Pty) Ltd SA Contact Centre: 0861 0861 08 International: +27 21 970 2000 Disclaimer: xneelo.co.za/email-disclaimer Formerly known as Hetzner SA Dovecot -n and systems report are attached Log file extries: Sep 9 14:29:32 [1]www23.jnb2.host-h.net dovecot: imap(*****@*******): Error: Mailbox INBOX.Client Correspondence: read() failed with file /usr/www/dovecot_indexes/********.[2]co.za/orders/.Client Correspondence/dovecot.index.cache: Cannot allocate memory Sep 9 14:29:32 [3]www23.jnb2.host-h.net dovecot: imap(*****(a)*******.[4]co.za): Error: mremap_anon(/usr/www/dovecot_indexes/********.[5]co.za/orders/.Client Correspondence/dovecot.index.cache, 967524352) failed: Cannot allocate memory Sep 9 14:29:32 [6]www23.jnb2.host-h.net dovecot: imap(*****@*******): Error: mremap_anon(/usr/www/dovecot_indexes/********.[7]co.za/orders/.Client Correspondence/dovecot.index.cache, 967524352) failed: Cannot allocate memory Sep 9 14:29:32 [8]www23.jnb2.host-h.net dovecot: imap(*****@*******): Error: Mailbox INBOX.Client Correspondence: read() failed with file /usr/www/dovecot_indexes/********.[9]co.za/orders/.Client Correspondence/dovecot.index.cache: Cannot allocate memory Sep 9 14:29:32 [10]www23.jnb2.host-h.net dovecot: imap(*****@*******): Error: mremap_anon(/usr/www/dovecot_indexes/********.[11]co.za/orders/.Client Correspondence/dovecot.index.cache, 967524352) failed: Cannot allocate memory Sep 9 14:29:32 [12]www23.jnb2.host-h.net dovecot: imap(*****(a)*******.[13]co.za): Error: mremap_anon(/usr/www/dovecot_indexes/********.[14]co.za/orders/.Client Correspondence/dovecot.index.cache, 967524352) failed: Cannot allocate memory Sep 9 14:29:32 [15]www23.jnb2.host-h.net dovecot: imap(*****(a)*******.[16]co.za): Error: Mailbox INBOX.Client Correspondence: read() failed with file /usr/www/dovecot_indexes/********.[17]co.za/orders/.Client Correspondence/dovecot.index.cache: Cannot allocate memory Evan Booyens Linux Platform Engineer xneelo (Pty) Ltd SA Contact Centre: 0861 0861 08 International: +27 21 970 2000 Disclaimer: [18]xneelo.co.za/email-disclaimer Formerly known as Hetzner SA References Visible links 1. http://www23.jnb2.host-h.net/ 2. http://co.za/orders/.Client 3. http://www23.jnb2.host-h.net/ 4. http://co.za/ 5. http://co.za/orders/.Client 6. http://www23.jnb2.host-h.net/ 7. http://co.za/orders/.Client 8. http://www23.jnb2.host-h.net/ 9. http://co.za/orders/.Client 10. http://www23.jnb2.host-h.net/ 11. http://co.za/orders/.Client 12. http://www23.jnb2.host-h.net/ 13. http://co.za/ 14. http://co.za/orders/.Client 15. http://www23.jnb2.host-h.net/ 16. http://co.za/ 17. http://co.za/orders/.Client 18. http://xneelo.co.za/email-disclaimer

1 0

iOS email client / imap push
by Jorge Bastos 08 Sep '26

08 Sep '26

Howdy, Does anyway had an issue with latest iOS's, where the native email client put the messages as seen, when the only thing that is done is just "refresh", the message wasn't open, i tested myself. Anyone/is it known, if yes any workarround or wait for apple to solve it? Howdy, Does anyway had an issue with latest iOS's, where the native email client put the messages as seen, when the only thing that is done is just "refresh", the message wasn't open, i tested myself. Anyone/is it known, if yes any workarround or wait for apple to solve it?

1 0

Re: Help with sieve
by Jorge Bastos 08 Sep '26

08 Sep '26

António, Oh, i'm so sorry for the question and the time of you all. Yes, i'm missing the stop on the 1st rule, sieve executes them from top to bottom. Solved, and thank you all for the time, On 2026-09-06 22:14, Antonio Oliveira via dovecot wrote: > On 9/6/2026 9:48 PM, Jorge Bastos via dovecot wrote: > >> Hi all, >> >> Well, my issue is not exacly what you descrived, >> >> I have an account, that i want to forward all incoming emails, so far >> so >> good. >> Before the emails are forward, i want to delete some, based on the >> sender >> domain. >> >> Thing is, i think managesieve roundcube plugin is producing the script >> wrong, here's what i have, i have 1 rule for the delete some senders, >> ok, >> and the 2nd for the redirect >> >> # rule:[blocks] >> if anyof (header :contains "from" "clubefashion.com", header :contains >> "from" "nutribody.pt", header :contains "from" "mcdonalds.pt") >> { >> discard; >> redirect "jorge(a)domain.pt"; >> } >> # rule:[redir] >> if true >> { >> redirect "jorge(a)domain.pt"; >> } > > Hello, > > if you want to forward all of the emails, regardless of the sender > domain and then "delete" them from the original inbox I would do > (option 1): > > # rule:[blocks] > if anyof (header :contains "from" "clubefashion.com", header :contains > "from" "nutribody.pt", header :contains "from" "mcdonalds.pt") > { > redirect "jorge(a)domain.pt"; > discard; > stop; > } > # rule:[redir] > if true > { > redirect "jorge(a)domain.pt"; > stop; > } > > If, on the other hand you do not want do forward them and also do not > want to keep them then simply do (option 2): > > # rule:[blocks] > if anyof (header :contains "from" "clubefashion.com", header :contains > "from" "nutribody.pt", header :contains "from" "mcdonalds.pt") > { > discard; > stop; > } > # rule:[redir] > if true > { > redirect "jorge(a)domain.pt"; > stop; > } > > option 1 - Email is redirected, discarded and rule processing stops > (which inhibits the implicit "keep" from running, so the email is > redirected to the other mailbox but not kept on the original one). > > option 2 - Email from those domains is discarded and rule processing > stops, again inhibiting the implicit keep. For the other domains, email > is redirected and "implicilty" kept on the original mailbox. > > if you're using roundcube you should have an action when creating the > rule to "stop evaluating rules" or something else to that effect when > creating the rule, that will add the "stop;" line on each rule. > you just need to add it in the correct order to make it work. > > In your first message you stated that you wanted to avoid having those > blocked domain emails from being stored in the original mailbox, so > option 2 should work correctly for that. The rules you have in this > message will redirect both the "blocked" and all other emails to being > redirected to the other mailbox, which is what option 1 gives you. With > the rules you sent you would get *two* emails from the "blocked" > domains being redirected to "jorge(a)domain.pt" since both rules would > match. > > Hope this clarifies and helps you achieve the desired outcome. Both are > entirely possible with roundcube generated sieve rules, you just need > to decide on which of the two you want. > > Regards, > >> On 2026-09-06 10:15, Toth Attila via dovecot wrote: >> >> I'm using a filter that moves the mail to another directory. The >> original message disappeared only from the initial location if >> imapsieve_expunge_discarded = yes was set. A duplicate remained >> otherwise. I suggest to take a look at on this configuration option >> depending on the purpose of the filter. >> >> On 2026.09.06 02:30, Stephan Bosch via dovecot wrote: >> >> Op 2-9-2026 om 16:00 schreef Antonio Oliveira via dovecot: >> >> Hello, >> >> You can try to add "stop;" after "discard;", so that rule processing >> stops after the discard and doesn't trickle down to the other rule. >> >> Yes, this will help. Why? The discard action command only cancels the >> implicit keep; nothing else. It means that if and only if no other >> explicit action delivers or preserves (keeps!) the message somehow, it >> is discarded. So, if subsequently redirect is triggered, the message >> is redirected, thereby making the discard action ineffective. Stopping >> the script right after discard will make sure no other actions can be >> triggered, thereby making sure the message is discarded (provided no >> earlier actions already triggered some sort of delivery either). >> Without discard or any other action command that cancels the implicit >> keep (such as redirect, fileinto, and ... keep), the default action is >> to "keep" the message, e.g. file it to INBOX. >> >> Regards, >> >> Stephan. >> >> On 9/2/2026 1:05 PM, Jorge Bastos via dovecot wrote: >> >> Hi guys, >> >> Small help with a sieve script, I have the script below in a >> useraccount, >> in this exact order. >> The redirect works, but the discard doesn't. >> A message that comes from the domain "clubefashing.com" or >> "nutribody.pt", >> is always redirected. >> >> Any idea what is wrong here? >> >> # rule:[blocks] >> if anyof (header :contains "from" "clubefashion.com", header >> :contains >> "from" "nutribody.pt") >> { >> discard; >> } >> # rule:[redir] >> if true >> { >> redirect "[1]jorge(a)decimal.pt"; >> } >> >> _______________________________________________ >> dovecot mailing list -- [2]dovecot(a)dovecot.org >> To unsubscribe send an email to [3]dovecot-leave(a)dovecot.org >> >> _______________________________________________ >> dovecot mailing list -- [4]dovecot(a)dovecot.org >> To unsubscribe send an email to [5]dovecot-leave(a)dovecot.org >> >> References >> >> Visible links >> 1. mailto:jorge@decimal.pt >> 2. mailto:dovecot@dovecot.org >> 3. mailto:dovecot-leave@dovecot.org >> 4. mailto:dovecot@dovecot.org >> 5. mailto:dovecot-leave@dovecot.org >> >> _______________________________________________ >> dovecot mailing list -- dovecot(a)dovecot.org >> To unsubscribe send an email to dovecot-leave(a)dovecot.org Antonio, Oh, i'm so sorry for the question and the time of you all. Yes, i'm missing the stop on the 1st rule, sieve executes them from top to bottom. Solved, and thank you all for the time, On 2026-09-06 22:14, Antonio Oliveira via dovecot wrote: On 9/6/2026 9:48 PM, Jorge Bastos via dovecot wrote: Hi all, Well, my issue is not exacly what you descrived, I have an account, that i want to forward all incoming emails, so far so good. Before the emails are forward, i want to delete some, based on the sender domain. Thing is, i think managesieve roundcube plugin is producing the script wrong, here's what i have, i have 1 rule for the delete some senders, ok, and the 2nd for the redirect # rule:[blocks] if anyof (header :contains "from" "clubefashion.com", header :contains "from" "nutribody.pt", header :contains "from" "mcdonalds.pt") { discard; redirect "[1]jorge(a)domain.pt"; } # rule:[redir] if true { redirect "[2]jorge(a)domain.pt"; } Hello, if you want to forward all of the emails, regardless of the sender domain and then "delete" them from the original inbox I would do (option 1): # rule:[blocks] if anyof (header :contains "from" "clubefashion.com", header :contains "from" "nutribody.pt", header :contains "from" "mcdonalds.pt") { redirect "[3]jorge(a)domain.pt"; discard; stop; } # rule:[redir] if true { redirect "[4]jorge(a)domain.pt"; stop; } If, on the other hand you do not want do forward them and also do not want to keep them then simply do (option 2): # rule:[blocks] if anyof (header :contains "from" "clubefashion.com", header :contains "from" "nutribody.pt", header :contains "from" "mcdonalds.pt") { discard; stop; } # rule:[redir] if true { redirect "[5]jorge(a)domain.pt"; stop; } option 1 - Email is redirected, discarded and rule processing stops (which inhibits the implicit "keep" from running, so the email is redirected to the other mailbox but not kept on the original one). option 2 - Email from those domains is discarded and rule processing stops, again inhibiting the implicit keep. For the other domains, email is redirected and "implicilty" kept on the original mailbox. if you're using roundcube you should have an action when creating the rule to "stop evaluating rules" or something else to that effect when creating the rule, that will add the "stop;" line on each rule. you just need to add it in the correct order to make it work. In your first message you stated that you wanted to avoid having those blocked domain emails from being stored in the original mailbox, so option 2 should work correctly for that. The rules you have in this message will redirect both the "blocked" and all other emails to being redirected to the other mailbox, which is what option 1 gives you. With the rules you sent you would get *two* emails from the "blocked" domains being redirected to "[6]jorge(a)domain.pt" since both rules would match. Hope this clarifies and helps you achieve the desired outcome. Both are entirely possible with roundcube generated sieve rules, you just need to decide on which of the two you want. Regards, On 2026-09-06 10:15, Toth Attila via dovecot wrote: I'm using a filter that moves the mail to another directory. The original message disappeared only from the initial location if imapsieve_expunge_discarded = yes was set. A duplicate remained otherwise. I suggest to take a look at on this configuration option depending on the purpose of the filter. On 2026.09.06 02:30, Stephan Bosch via dovecot wrote: Op 2-9-2026 om 16:00 schreef Antonio Oliveira via dovecot: Hello, You can try to add "stop;" after "discard;", so that rule processing stops after the discard and doesn't trickle down to the other rule. Yes, this will help. Why? The discard action command only cancels the implicit keep; nothing else. It means that if and only if no other explicit action delivers or preserves (keeps!) the message somehow, it is discarded. So, if subsequently redirect is triggered, the message is redirected, thereby making the discard action ineffective. Stopping the script right after discard will make sure no other actions can be triggered, thereby making sure the message is discarded (provided no earlier actions already triggered some sort of delivery either). Without discard or any other action command that cancels the implicit keep (such as redirect, fileinto, and ... keep), the default action is to "keep" the message, e.g. file it to INBOX. Regards, Stephan. On 9/2/2026 1:05 PM, Jorge Bastos via dovecot wrote: Hi guys, Small help with a sieve script, I have the script below in a useraccount, in this exact order. The redirect works, but the discard doesn't. A message that comes from the domain "clubefashing.com" or "nutribody.pt", is always redirected. Any idea what is wrong here? # rule:[blocks] if anyof (header :contains "from" "clubefashion.com", header :contains "from" "nutribody.pt") { discard; } # rule:[redir] if true { redirect "[1][7]jorge(a)decimal.pt"; } _______________________________________________ dovecot mailing list -- [2][8]dovecot(a)dovecot.org To unsubscribe send an email to [3][9]dovecot-leave(a)dovecot.org _______________________________________________ dovecot mailing list -- [4][10]dovecot(a)dovecot.org To unsubscribe send an email to [5][11]dovecot-leave(a)dovecot.org References Visible links 1. mailto:[12]jorge@decimal.pt 2. mailto:[13]dovecot@dovecot.org 3. mailto:[14]dovecot-leave@dovecot.org 4. mailto:[15]dovecot@dovecot.org 5. mailto:[16]dovecot-leave@dovecot.org _______________________________________________ dovecot mailing list -- [17]dovecot(a)dovecot.org To unsubscribe send an email to [18]dovecot-leave(a)dovecot.org References Visible links 1. mailto:jorge@domain.pt 2. mailto:jorge@domain.pt 3. mailto:jorge@domain.pt 4. mailto:jorge@domain.pt 5. mailto:jorge@domain.pt 6. mailto:jorge@domain.pt 7. mailto:jorge@decimal.pt 8. mailto:dovecot@dovecot.org 9. mailto:dovecot-leave@dovecot.org 10. mailto:dovecot@dovecot.org 11. mailto:dovecot-leave@dovecot.org 12. mailto:jorge@decimal.pt 13. mailto:dovecot@dovecot.org 14. mailto:dovecot-leave@dovecot.org 15. mailto:dovecot@dovecot.org 16. mailto:dovecot-leave@dovecot.org 17. mailto:dovecot@dovecot.org 18. mailto:dovecot-leave@dovecot.org

1 0

Problem email client iPhone ios18.2
by andrzej.milewski＠gmail.com 08 Sep '26

08 Sep '26

Hello, I have a fairly new installation of the Dovecot server version 2.3.19.1 on Debian 12.8. In general, the server works correctly. It sends and receives emails without issues. The clients primarily use Thunderbird on desktops and Gmail on Android. However, some clients are using iPhones with various hardware versions. Those with iOS below version 18 work correctly without any issues. Those who have updated their phones to version 18 and now even 18.2 are experiencing problems with mailbox synchronization. On version 18.2, the issue appears as follows: When you open the app, you can read several messages. They load correctly, but, for instance, attachments do not. If I wait for some time, the attachment eventually loads. During this time, I observe the server logs, and it shows that a certain session on the Dovecot server has ended. Dec 17 13:13:01 iredmail0 dovecot[408]: imap(xxx(a)xxx.com)<44785><1QGZCHcp/+3AqM2O>: Disconnected: Connection closed (UID SEARCH finished 92.295 secs ago) in=2972 out=6076956 deleted=0 expunged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=36 body_bytes=6059064 Dec 18 08:40:41 iredmail0 dovecot[408]: imap(xxx(a)xxx.com)<177412>: Disconnected: Connection closed (UID FETCH finished 90.079 secs ago) in=5126 out=1304237 deleted=0 expunged=0 trashed=0 hdr_count=94 hdr_bytes=289688 body_count=89 body_bytes=969615 Dec 18 08:42:19 iredmail0 dovecot[408]: imap(xxx(a)xxx.com)<177410><D5mqU4cpZ+nAqM2O>: Disconnected: Connection closed (UID FETCH finished 95.051 secs ago) in=4475 out=1162785 deleted=0 expunged=0 trashed=0 hdr_count=95 hdr_bytes=281674 body_count=61 body_bytes=839545 Dec 18 08:44:17 iredmail0 dovecot[408]: imap(edyta.kowalewska(a)laktopol.com.pl)<177918>: Disconnected: Connection closed (UID FETCH finished 92.132 secs ago) in=29399 out=30266644 deleted=0 expunged=0 trashed=0 hdr_count=565 hdr_bytes=1726228 body_count=628 body_bytes=28109455 After the session is closed, the attachment loads immediately. From the logs and router analysis, it appears that the download happens in another previously opened session. After this incident, I go to another message with an attachment, and the situation repeats. There are also situations where the email body does not load, and the app waits for the server until the session closes and the content is fetched in another session. It does not matter whether I connect to the server via the internet or through a local network. On an iPhone 7 with iOS 15.8.3, everything works smoothly. Attachments open without issues. On iOS 18.1.1, attachments do not load, and the session does not close on its own. It takes forever unless the app is closed. In the Gmail app, everything works correctly without any issues. This is clearly a problem with the mail client on iPhone. However, is there anything I can adjust in my server settings to mitigate this issue for users? My dovecot configuration https://pastebin.com/UPNQ5dZz

26 60

mail-crypt: user key generated with crypt_user_key_password still usable without it
by Twinsen＠die-optimisten.net 07 Sep '26

07 Sep '26

Hi, I please need help. Dovecot 2.4.1-4 (docker-mailserver 16.0.1), Maildir, passwd-file for both passdb and userdb. Config: mail_plugins = mail_crypt mail_attribute { dict file { path = %{home}/Maildir/dovecot-attributes } } crypt_user_key_curve = secp521r1 crypt_user_key_require_encrypted = yes I also added a second passdb in Lua that returns the login password as a sha256 hex string: passdb passdb-default { result_success = continue-ok } passdb lua { lua_file = /etc/dovecot/lua/crypt.lua skip = unauthenticated use_worker = yes } The Lua script returns PASSDB_RESULT_OK with: { noauthenticate = "yes", userdb_crypt_user_key_password = <sha256 hex> } What I have verified so far: doveadm auth login lists crypt_user_key_password under "userdb extra fields", so the field reaches userdb. With crypt_user_key_require_encrypted = no and the attributes file removed, an IMAP login auto-creates a user key. That key is unencrypted. With crypt_user_key_require_encrypted = yes and the attributes file removed, no key is created. IMAP logs: dict(file): stat(.../Maildir/dovecot-attributes) failed: No such file or directory So I generated the key manually: doveadm -o crypt_user_key_password=<sha256 hex> \ mailbox cryptokey generate -u user(a)example.com -Uf This succeeded. The new key is active, the old one shows as inactive, and the attributes file grew from 2280 to 3147 bytes. Now incoming mail is stored encrypted, the files start with CRYPTED. However, this still returns the headers in clear text, without any password and without error: doveadm fetch -u user(a)example.com hdr mailbox INBOX So the key appears to be usable without the password at all. My main question is: Does -o crypt_user_key_password actually encrypt the user key when it is generated, or is it only used to unlock an already encrypted key? Related to that: Can an old inactive user key still be used for decryption in this setup? Is there any marker that indicates in the attributes dict whether a user key is password-encrypted? With passwd-file as userdb (no prefetch), should an extra field from a passdb reach the IMAP process that creates or loads the key? Any pointers apreciated. Best regards, Twinsen

1 0

[2.4.5] LDAPS Panic: file ldap-utils.c: line 66: unreached
by inaugurator＠ya.ru 07 Sep '26

07 Sep '26

Hello, LDAP in passdb with 389 port works pretty well. But when I change port to 636 and use ldaps:// I get the error: ``` auth: Panic: file ldap-utils.c: line 66: unreached auth: Error: Raw backtrace: #0 default_fatal_finish[0x7a7e387b9ef4] -> #1 fatal_handler_real[0x7a7e387b9fb2] -> #2 i_internal_fatal_handler[0x7a7e387bb36d] -> #3 i_panic[0x7a7e387ba1ec] -> #4 i_unreached[0x7a7e387bb867] -> #5 ldap_set_opt_str[0x7a7e3763ad84] -> #6 ldap_set_tls_options[0x7a7e3763af3d] -> #7 ldap_set_options[0x7a7e3763200d] -> #8 db_ldap_init_ld[0x7a7e3763230f] -> #9 db_ldap_init[0x7a7e37633efb] -> #10 passdb_ldap_preinit[0x7a7e37635d22] -> #11 passdb_preinit[0x55cc948e7eb9] -> #12 auth_passdb_preinit[0x55cc948c0193] -> #13 auth_preinit[0x55cc948c0a87] -> #14 auths_preinit[0x55cc948c16de] -> #15 main_preinit[0x55cc948bf3e2] -> #16 main[0x55cc948bfae2] -> #17 __libc_init_first[0x7a7e383671d0] -> #18 __libc_start_main[0x7a7e38367280] -> #19 _start[0x55cc948bee20] master: Error: service(auth): command startup failed, throttling for 16.000 secs auth: Fatal: master: service(auth): child 344291 killed with signal 6 (core dumps disabled - https://dovecot.org/bugreport.html#coredumps) ```

1 0

Help with sieve
by Jorge Bastos 06 Sep '26

06 Sep '26

Hi guys, Small help with a sieve script, I have the script below in a useraccount, in this exact order. The redirect works, but the discard doesn't. A message that comes from the domain "clubefashing.com" or "nutribody.pt", is always redirected. Any idea what is wrong here? # rule:[blocks] if anyof (header :contains "from" "clubefashion.com", header :contains "from" "nutribody.pt") { discard; } # rule:[redir] if true { redirect "jorge(a)decimal.pt"; } Hi guys, Small help with a sieve script, I have the script below in a useraccount, in this exact order. The redirect works, but the discard doesn't. A message that comes from the domain "clubefashing.com" or "nutribody.pt", is always redirected. Any idea what is wrong here? # rule:[blocks] if anyof (header :contains "from" "clubefashion.com", header :contains "from" "nutribody.pt") { discard; } # rule:[redir] if true { redirect "jorge(a)decimal.pt"; }

4 6

Process destroy
by Christian H. Kuhn 06 Sep '26

06 Sep '26

Hi all, i have a user who cannot log in anymore with thunderbird. The problem arose after my updating to ubuntu 26.04. It is only that one user with his three accounts who has the problem. If i read the log right, he uses the correct credentials and could log in, if there wasn't a read problem with /proc/self/io and ad Process destroy. Here are the relevant data: root@bywater ~ # lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 26.04.1 LTS Release: 26.04 Codename: resolute root@bywater ~ # dovecot --version 2.4.2 (0962ed2104) /var/log/dovecot/dovecot.debug: 2026-09-06T08:51:08.583060+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6 Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: sasl(plain): Set authid 'user(a)sglasker.de' 2026-09-06T08:51:08.583084+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6 Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: sasl(plain): Performing plain passdb verification 2026-09-06T08:51:08.583108+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6 Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: sql: Performing passdb lookup 2026-09-06T08:51:08.583178+02:00 bywater dovecot: auth-worker(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8)<339340><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: request [11]: Debug: sql: Performing passdb lookup 2026-09-06T08:51:08.583210+02:00 bywater dovecot: auth-worker(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8)<339340><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: request [11]: Debug: sql: query: SELECT email AS user, password FROM user WHERE email = 'user(a)sglasker.de' 2026-09-06T08:51:08.583374+02:00 bywater dovecot: auth-worker: Debug: mysql(127.0.0.1): Finished query 'SELECT email AS user, password FROM user WHERE email = 'user(a)sglasker.de'' in 0 msecs 2026-09-06T08:51:08.585565+02:00 bywater dovecot: auth-worker(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8)<339340><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: request [11]: Debug: sql: Finished passdb lookup 2026-09-06T08:51:08.585652+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: sql: Finished passdb lookup 2026-09-06T08:51:08.585677+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: sasl(plain): Finished plain passdb verification (status=ok) 2026-09-06T08:51:08.585704+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: sasl(plain): Interaction succeeded 2026-09-06T08:51:08.585738+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: Auth request finished 2026-09-06T08:51:08.585769+02:00 bywater dovecot: auth: Debug: conn unix:login (pid=339464,uid=111) [501]: client passdb out: OK#0111#011user=user(a)sglasker.de 2026-09-06T08:51:08.591149+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: static: Performing userdb lookup 2026-09-06T08:51:08.591186+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: static: Finished userdb lookup 2026-09-06T08:51:08.591209+02:00 bywater dovecot: auth: Debug: master userdb out: USER#011622723073#011user@sglasker.de#011uid=5000#011gid=5000#011home=/var/mail/vhosts/sglasker.de/user#011auth_mech=PLAIN#011auth_token=581264423b972f752ffa367319e23d10630ec484#011local_name=IMAP.qno.de 2026-09-06T08:51:08.591236+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8)<G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: sasl(plain): Request destroy 2026-09-06T08:51:08.591513+02:00 bywater dovecot: imap(user(a)sglasker.de)<339465><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: Effective uid=5000, gid=5000, home=/var/mail/vhosts/sglasker.de/user 2026-09-06T08:51:08.591603+02:00 bywater dovecot: imap(user(a)sglasker.de)<339465><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: open(/proc/self/io) failed: Permission denied (euid=5000(vmail) egid=5000(vmail) missing +r perm: /proc/self/io) 2026-09-06T08:51:08.591811+02:00 bywater dovecot: imap(user(a)sglasker.de)<339465><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: Namespace inbox: type=private, prefix=, sep=, inbox=yes, hidden=no, list=yes, subscriptions=yes 2026-09-06T08:51:08.591868+02:00 bywater dovecot: imap(user(a)sglasker.de)<339465><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: maildir++: root=/var/mail/vhosts/sglasker.de/user/Maildir, index=, indexpvt=, control=, inbox=/var/mail/vhosts/sglasker.de/user/Maildir, alt= 2026-09-06T08:51:08.981986+02:00 bywater dovecot: imap(user(a)sglasker.de)<339465><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: Mailbox INBOX: Mailbox opened Any hints? TIA QNo

1 0

Process destroy
by Christian H. Kuhn 06 Sep '26

06 Sep '26

Hi all, i have a user who cannot log in anymore with thunderbird. The problem arose after my updating to ubuntu 26.04. It is only that one user with his three accounts who has the problem. If i read the log right, he uses the correct credentials and could log in, if there wasn't a read problem with /proc/self/io and ad Process destroy. Here are the relevant data: root@bywater ~ # lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 26.04.1 LTS Release: 26.04 Codename: resolute root@bywater ~ # dovecot --version 2.4.2 (0962ed2104) /var/log/dovecot/dovecot.debug: 2026-09-06T08:51:08.583060+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6 Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: sasl(plain): Set authid 'user(a)sglasker.de' 2026-09-06T08:51:08.583084+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6 Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: sasl(plain): Performing plain passdb verification 2026-09-06T08:51:08.583108+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6 Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: sql: Performing passdb lookup 2026-09-06T08:51:08.583178+02:00 bywater dovecot: auth-worker(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8)<339340><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: request [11]: Debug: sql: Performing passdb lookup 2026-09-06T08:51:08.583210+02:00 bywater dovecot: auth-worker(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8)<339340><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: request [11]: Debug: sql: query: SELECT email AS user, password FROM user WHERE email = 'user(a)sglasker.de' 2026-09-06T08:51:08.583374+02:00 bywater dovecot: auth-worker: Debug: mysql(127.0.0.1): Finished query 'SELECT email AS user, password FROM user WHERE email = 'user(a)sglasker.de'' in 0 msecs 2026-09-06T08:51:08.585565+02:00 bywater dovecot: auth-worker(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8)<339340><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: request [11]: Debug: sql: Finished passdb lookup 2026-09-06T08:51:08.585652+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: sql: Finished passdb lookup 2026-09-06T08:51:08.585677+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: sasl(plain): Finished plain passdb verification (status=ok) 2026-09-06T08:51:08.585704+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: sasl(plain): Interaction succeeded 2026-09-06T08:51:08.585738+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: Auth request finished 2026-09-06T08:51:08.585769+02:00 bywater dovecot: auth: Debug: conn unix:login (pid=339464,uid=111) [501]: client passdb out: OK#0111#011user=user(a)sglasker.de 2026-09-06T08:51:08.591149+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: static: Performing userdb lookup 2026-09-06T08:51:08.591186+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8,sasl:plain)<G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: static: Finished userdb lookup 2026-09-06T08:51:08.591209+02:00 bywater dovecot: auth: Debug: master userdb out: USER#011622723073#011user@sglasker.de#011uid=5000#011gid=5000#011home=/var/mail/vhosts/sglasker.de/user#011auth_mech=PLAIN#011auth_token=581264423b972f752ffa367319e23d10630ec484#011local_name=IMAP.qno.de 2026-09-06T08:51:08.591236+02:00 bywater dovecot: auth(user@sglasker.de,2a00:fbc:ec47:a4b1:c484:16a7:366c:c4a8)<G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: sasl(plain): Request destroy 2026-09-06T08:51:08.591513+02:00 bywater dovecot: imap(user(a)sglasker.de)<339465><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: Effective uid=5000, gid=5000, home=/var/mail/vhosts/sglasker.de/user 2026-09-06T08:51:08.591603+02:00 bywater dovecot: imap(user(a)sglasker.de)<339465><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: open(/proc/self/io) failed: Permission denied (euid=5000(vmail) egid=5000(vmail) missing +r perm: /proc/self/io) 2026-09-06T08:51:08.591811+02:00 bywater dovecot: imap(user(a)sglasker.de)<339465><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: Namespace inbox: type=private, prefix=, sep=, inbox=yes, hidden=no, list=yes, subscriptions=yes 2026-09-06T08:51:08.591868+02:00 bywater dovecot: imap(user(a)sglasker.de)<339465><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: maildir++: root=/var/mail/vhosts/sglasker.de/user/Maildir, index=, indexpvt=, control=, inbox=/var/mail/vhosts/sglasker.de/user/Maildir, alt= 2026-09-06T08:51:08.981986+02:00 bywater dovecot: imap(user(a)sglasker.de)<339465><G6Ad7cpaOMIqAA+87EekscSEFqc2bMSo>: Debug: Mailbox INBOX: Mailbox opened Any hints? TIA QNo

1 0

History Assignment Writing Help – Expert Assistance
by Theo Wilson 04 Sep '26

04 Sep '26

Struggling with your history assignments? Our History Assignment Writing Help service offers expert guidance to help you craft well-researched, structured, and original assignments. Fill out this form to get personalized support from experienced writers and improve your grades with ease. https://www.newassignmenthelp.co.uk/history-assignment-help

2 1

Pay Someone to Take My Online Course?
by xotawa2329＠hapincy.com 04 Sep '26

04 Sep '26

Pay Someone to Take My Online Course? Different understudies who battle with reworking school, work, and family obligations select online class tutors to assist them with finishing their tests and complete their coursework. In any case, some solicitation the ethicality of this planning. While <a href="https://onlineclassservices.com/nurs-fpx-4040-assessment-4-attempt-1-inform…">NURS FPX 4040 Assessment 4</a>  has every one of the reserves of being enticing, it goes with two or three serious dangers. This article will examine a piece of the things you ought to remember going before enlisting an online class help association. It's clearly a fact that online classes can be truly troublesome, particularly for working professionals who have a clamoring plan. Oftentimes they are searching for someone to take a whole course or individual tasks for them, to assist with managing their grades and moderate their strain. Nonetheless, be wary of affiliations that guarantee too wonderful to be authentic. They could charge you enormous totals for their associations and end up not conveying. The best technique for guaranteeing that you are getting anything that would be fair is to use an online class tutor who offers an inadequate responsibility. Additionally, review that different schools consider paying someone to take an online class to swindle. Therefore, whenever got, you could go facing silly outcomes like besieging the course, scholarly suspension or even send off. To this end picking a fair relationship with a showed history is crucial. The association is clear: present your mentioning and survey offers from qualified educated authorities. Then enlist the one that is reasonable for yourself and store maintains in <a href="https://onlineclassservices.com/nurs-fpx-4050-assessment-1-attempt-3-prelim…">NURS FPX 4050 Assessment 1</a>  scrow until your assignment is finished. Online classes are eminent among understudies who need to save time on education and spotlight more on work or other private issues. These merge understudies who are taking courses while working and attempting to change family and profession responsibilities, military understudies on sending, and understudies with genuine inadequacies or sickness that make it pursuing for them to go to classes. Unfortunately, there are many tricks that confirmation to take online courses for you. These affiliations charge ridiculous totals and don't complete their obligations. They may also hand you over to your school. Tolerating that they do, you could be killed from your underwriting project or even suspended or removed from school. This isn't the very thing that you truly need for your business and future. Therefore, you genuinely need to track down serious areas of strength for a that offers a fair cost and mind blowing results. To this end you ought to search for a <a href="https://onlineclassservices.com/nurs-fpx-4050-assessment-2-attempt-1-ethica…">NURS FPX 4050 Assessment 2</a>  affiliation that has an inadequate responsibility and splendid customer association. Various individuals decide to use a professional to take their online class since they need the opportunity to go to it very close. They could be working the whole day, supervising family issues, or fighting disease and disappointments that log jam their review tendencies. These professionals can assist you with fulfilling time necessities, stay away from imaginative theft, and set free your nights to zero in on work or other unwinding works out. They may comparatively have the decision to help you with beating any learning handicaps you have. Copyright infringement suggests utilizing someone else's words and thoughts without their endorsement. It is viewed as a kind of cheating and can accomplish a delicate grade or even send off from school. It is difficult to ensure that a used professional won't phony. This is on the grounds that educational foundations don't have <a href="https://onlineclassservices.com/nurs-fpx-4900-assessment-1-assessing-the-pr…">NURS FPX 4900 Assessment 1 Assessing the Problem</a>  assets for check whether understudies are authentic or not. This truly expects that tolerant you are gotten, you will probably lose the cash you paid to have someone take your class. There's no veritable strategy for remaining caution assuming the solitary you enroll to take your online course will tell the truth and dependable. They probably won't be in a tantamount state as you. Moreover, they apparently won't be as dedicated to finishing the class for you as you are. They may very well be doing the base extent of work expected to get reviewed and a brief time frame later vanish. MORE <a href="https://dev.gajim.org/gajim/website/-/issues/35#note_211778">Facebook is a powerful tool for business</a> <a href="https://xtremepape.rs/members/horridhenry7860.397211/about">Mobile Application Development Services</a> <a href="https://xtremepape.rs/members/samfarrid4563.397213/about">best digital marketing agencies</a>

6 6

Lazy-Expunge plugin documentation incomplete?
by Randolf Richardson 04 Sep '26

04 Sep '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 4

Config parser bug?
by Pat Suwalski 03 Sep '26

03 Sep '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

3 10

discussion about "Remove doveadm_allowed_commands setting"
by Patrick Cernko 03 Sep '26

03 Sep '26

Hi Timo, hi list, I saw this commit (https://github.com/dovecot/core/commit/2b0947986ccb72e2f5ce13f8bd4b300e94e3…) on Dovecot's github repo: > doveadm: Remove doveadm_allowed_commands setting > The setting only compared the first command name against a list, which > gave a false sense of security. Anyone who is allowed to connect to the > doveadm server can already do practically anything with the commands > that were typically allowed: most commands take a -u/-A user parameter, > and commands like sync, backup and import take parameters that access > arbitrary paths. Restricting the command name doesn't change that, so > doveadm access must be given only to trusted clients regardless. I tried to understand the detailed reasoning but I don't get it. As far as I can follow the code not only the *first command name* is checked but every command send (in the list of commands via HTTP API). From our point of view, this setting has a clear security benefit like this: > # security: we only allow specific doveadm commands via doveadm-server and some more when coming from localhost > doveadm_allowed_commands = user,who > local 127.0.0.1/8 { > doveadm_allowed_commands = user,who,"sieve list","sieve get","sieve put","sieve activate" > } It limits the allowed commands in general to who and user which are read-only. Only if the connection is comming from localhost, we additionally grant some sieve commands for our web interface to manage and test sieve rulesets (https://gitlab.mpi-klsb.mpg.de/pcernko/sieveweb) All other commands are not allowed at all, e.g. it is not possible to delete mails or use dsync via the HTTP API. This policy matches our general security policy to only grant what's needed. So, Timo, I would like to ask, why this setting has to get removed (I assume in the next release) or if it can be restored again in the main branch? Is there anyone else using this setting besides me? What do the other users think about the removal of the setting? 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 1

Minor freebsd issue on dovecot 2.4.5
by Lucas Holt 02 Sep '26

02 Sep '26

On FreeBSD and MidnightBSD, Dovecot's net_getunixcred() relies on getpeereid(), which lacks PID info, causing every imap-login connection to register with anvil as pid=-1 and collide in its per-process hash. Here's an example fix for the problem. Note this was AI generated with claude fable and I don't know what your AI policy is. --- src/lib/net.c.orig 2026-08-28 00:00:00 UTC +++ src/lib/net.c @@ -9,6 +9,9 @@ #include <fcntl.h> #include <ctype.h> #include <sys/un.h> +#ifdef __FreeBSD__ +# include <sys/ucred.h> +#endif #include <netinet/tcp.h> #if defined(HAVE_UCRED_H) # include <ucred.h> /* for getpeerucred() */ @@ -832,6 +835,26 @@ cred_r->gid = ucred.unp_egid; cred_r->pid = ucred.unp_pid; return 0; +#elif defined(LOCAL_PEERCRED) && defined(__FreeBSD__) && __FreeBSD__ >= 13 + /* FreeBSD 13+ / MidnightBSD 4+ (getpeereid() exists too, but struct + xucred also carries the peer pid, which anvil needs) */ + struct xucred ucred; + socklen_t len = sizeof(ucred); + + if (getsockopt(fd, 0, LOCAL_PEERCRED, &ucred, &len) < 0) { + i_error("getsockopt(LOCAL_PEERCRED) failed: %m"); + return -1; + } + + if (ucred.cr_version != XUCRED_VERSION) { + errno = EINVAL; + return -1; + } + + cred_r->uid = ucred.cr_uid; + cred_r->gid = ucred.cr_gid; + cred_r->pid = ucred.cr_pid; + return 0; #elif defined(HAVE_GETPEEREID) /* OSX 10.4+, FreeBSD 4.6+, OpenBSD 3.0+, NetBSD 5.0+ */ if (getpeereid(fd, &cred_r->uid, &cred_r->gid) < 0) {

4 8

Problem with setup of 2.4
by Doug Hardie 02 Sep '26

02 Sep '26

I have a production 2.3 server on the machine named "mail". I have installed 2.4 on the server named "test". I used the configuration converter to convert the production configuration to the new configuration structure. I did add a "log_debug = category=auth" line at the end for debug info. If I use the command to the production server: master# openssl s_client -connect 10.0.1.230:imap -starttls imap -quiet Connecting to 10.0.1.230 Can't use SSL_get_servername depth=3 C=US, O=Internet Security Research Group, CN=ISRG Root X2 verify return:1 depth=2 C=US, O=ISRG, CN=Root YE verify return:1 depth=1 C=US, O=Let's Encrypt, CN=YE2 verify return:1 depth=0 CN=mail.sermon-archive.info verify return:1 . OK Pre-login capabilities listed, post-login capabilities have more. At that point I can login and view mail. However, if i use the same command on the test server: master# openssl s_client -connect 10.0.1.235:993 -starttls imap Connecting to 10.0.1.235 CONNECTED(00000003) At this point is sits there accepting no input. The log shows: Aug 31 13:56:22 test dovecot[85915]: auth: Debug: conn unix:login (uid=144) [6]: Server accepted connection (fd=21) Aug 31 13:56:22 test dovecot[85915]: auth: Debug: conn unix:login (uid=144) [6]: auth client connected (pid=86045) There appears to be an SSL issue. The same certificates are used on both servers. Both servers are running FreeBSD 15.1. dovecot.conf is: test# cat dovecot.conf # Conversion performed at 2026-08-23 05:06:46.587238 dovecot_config_version = 2.4.2 dovecot_storage_version = 2.4.0 auth_mechanisms = plain cram-md5 auth_verbose_passwords = no base_dir = /var/run/home_mail/ first_valid_gid = 0 imap_capability = SASL-IR LOGIN-REFERRALS ID ENABLE LITERAL+ STARTTLS LOGINDISABLED AUTH=CRAM-MD5 lda_mailbox_autocreate = yes login_log_format_elements = user=<%{user}> method=%{mechanism} rip=%{remote_ip} lip=%{local_ip} mpid=%{mail_pid} %{secured} %{ssl_security} session=<%{session}> port=%{local_port} mail_driver = maildir mail_gid = 2222 mail_home = /var/mail/home_mail/%{user | username} mail_log_events = delete undelete expunge copy mailbox_delete mailbox_rename mail_log_fields = uid box msgid size from mail_log_prefix = %{protocol}(%{user})[%{remote_ip}]<%{session}>: mail_path = Maildir mail_temp_scan_interval = 0 mail_uid = 2222 postmaster_address = doug(a)sermon-archive.info protocols = imap syslog_facility = local1 verbose_proctitle = yes namespace inbox { inbox = yes mailbox Drafts { autoexpunge = 5 days special_use = \Drafts } mailbox Junk { autoexpunge = 5 days special_use = \Junk } mailbox Trash { autoexpunge = 50 days special_use = \Trash } mailbox Sent { autoexpunge = 30 days special_use = \Sent } mailbox "Sent Messages" { autoexpunge = 30 days special_use = \Sent } } passdb passwd-file { auth_username_format = %{user | username} default_password_scheme = CRYPT driver = passwd-file passwd_file_path = /usr/local/etc/dovecot/users } userdb static { driver = static fields { allow_all_users = yes home = /var/mail/home_mail/%d/%n } } service imap-login { inet_listener imap { port = 143 } inet_listener imaps { port = 993 ssl = yes } inet_listener imaps2 { port = 998 ssl = yes } } service auth { unix_listener auth-userdb { group = vmail mode = 0666 user = vmail } unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } } service stats { unix_listener stats-reader { group = vmail mode = 0660 user = vmail } unix_listener stats-writer { group = vmail mode = 0660 user = vmail } } ssl_server { cert_file = /www/certs/mail.pem dh_file = /usr/local/etc/dovecot/dh.pem key_file = # hidden, use -P to show it } protocol lda { mail_plugins { sieve = yes } } protocol imap { imap_metadata = yes mail_plugins { mail_log = yes notify = yes } } protocol pop3 { mail_plugins { mail_log = yes notify = yes } } #sieve_script personal { # active_path = /var/mail/home_mail/%{user | username}/.dovecot.sieve # driver = file # path = /var/mail/home_mail/%{user | username}/sieve #} mail_attribute { dict file { path = %{home}/Maildir/dovecot-attributes } } # Warnings during conversion: # - <memory>:8: dropping removed setting 'auth_stats' # - <memory>:50: mail_plugins uses $SET:mail_plugins but adds nothing # - <memory>:180: no converter for 'plugin/@1/stats_refresh' # - <memory>:181: no converter for 'plugin/@1/stats_track_cmds' # - pruned default: inbox prefix = '' log_debug = category=auth -- Doug

2 4

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

02 Sep '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

3 6

Problem with setup of 2.4
by Doug Hardie 31 Aug '26

31 Aug '26

I have a production 2.3 server on the machine named "mail". I have installed 2.4 on the server named "test". I used the configuration converter to convert the production configuration to the new configuration structure. I did add a "log_debug = category=auth" line at the end for debug info. If I use the command to the production server: master# openssl s_client -connect 10.0.1.230:imap -starttls imap -quiet Connecting to 10.0.1.230 Can't use SSL_get_servername depth=3 C=US, O=Internet Security Research Group, CN=ISRG Root X2 verify return:1 depth=2 C=US, O=ISRG, CN=Root YE verify return:1 depth=1 C=US, O=Let's Encrypt, CN=YE2 verify return:1 depth=0 CN=mail.sermon-archive.info verify return:1 . OK Pre-login capabilities listed, post-login capabilities have more. At that point I can login and view mail. However, if i use the same command on the test server: master# openssl s_client -connect 10.0.1.235:993 -starttls imap Connecting to 10.0.1.235 CONNECTED(00000003) At this point is sits there accepting no input. The log shows: Aug 31 13:56:22 test dovecot[85915]: auth: Debug: conn unix:login (uid=144) [6]: Server accepted connection (fd=21) Aug 31 13:56:22 test dovecot[85915]: auth: Debug: conn unix:login (uid=144) [6]: auth client connected (pid=86045) There appears to be an SSL issue. The same certificates are used on both servers. Both servers are running FreeBSD 15.1. dovecot.conf is: test# cat dovecot.conf # Conversion performed at 2026-08-23 05:06:46.587238 dovecot_config_version = 2.4.2 dovecot_storage_version = 2.4.0 auth_mechanisms = plain cram-md5 auth_verbose_passwords = no base_dir = /var/run/home_mail/ first_valid_gid = 0 imap_capability = SASL-IR LOGIN-REFERRALS ID ENABLE LITERAL+ STARTTLS LOGINDISABLED AUTH=CRAM-MD5 lda_mailbox_autocreate = yes login_log_format_elements = user=<%{user}> method=%{mechanism} rip=%{remote_ip} lip=%{local_ip} mpid=%{mail_pid} %{secured} %{ssl_security} session=<%{session}> port=%{local_port} mail_driver = maildir mail_gid = 2222 mail_home = /var/mail/home_mail/%{user | username} mail_log_events = delete undelete expunge copy mailbox_delete mailbox_rename mail_log_fields = uid box msgid size from mail_log_prefix = %{protocol}(%{user})[%{remote_ip}]<%{session}>: mail_path = Maildir mail_temp_scan_interval = 0 mail_uid = 2222 postmaster_address = doug(a)sermon-archive.info protocols = imap syslog_facility = local1 verbose_proctitle = yes namespace inbox { inbox = yes mailbox Drafts { autoexpunge = 5 days special_use = \Drafts } mailbox Junk { autoexpunge = 5 days special_use = \Junk } mailbox Trash { autoexpunge = 50 days special_use = \Trash } mailbox Sent { autoexpunge = 30 days special_use = \Sent } mailbox "Sent Messages" { autoexpunge = 30 days special_use = \Sent } } passdb passwd-file { auth_username_format = %{user | username} default_password_scheme = CRYPT driver = passwd-file passwd_file_path = /usr/local/etc/dovecot/users } userdb static { driver = static fields { allow_all_users = yes home = /var/mail/home_mail/%d/%n } } service imap-login { inet_listener imap { port = 143 } inet_listener imaps { port = 993 ssl = yes } inet_listener imaps2 { port = 998 ssl = yes } } service auth { unix_listener auth-userdb { group = vmail mode = 0666 user = vmail } unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } } service stats { unix_listener stats-reader { group = vmail mode = 0660 user = vmail } unix_listener stats-writer { group = vmail mode = 0660 user = vmail } } ssl_server { cert_file = /www/certs/mail.pem dh_file = /usr/local/etc/dovecot/dh.pem key_file = # hidden, use -P to show it } protocol lda { mail_plugins { sieve = yes } } protocol imap { imap_metadata = yes mail_plugins { mail_log = yes notify = yes } } protocol pop3 { mail_plugins { mail_log = yes notify = yes } } #sieve_script personal { # active_path = /var/mail/home_mail/%{user | username}/.dovecot.sieve # driver = file # path = /var/mail/home_mail/%{user | username}/sieve #} mail_attribute { dict file { path = %{home}/Maildir/dovecot-attributes } } # Warnings during conversion: # - <memory>:8: dropping removed setting 'auth_stats' # - <memory>:50: mail_plugins uses $SET:mail_plugins but adds nothing # - <memory>:180: no converter for 'plugin/@1/stats_refresh' # - <memory>:181: no converter for 'plugin/@1/stats_track_cmds' # - pruned default: inbox prefix = '' log_debug = category=auth -- Doug -- Doug

1 0

global ACL file with Dovecot >=2.4.3
by Markus Schönhaber 31 Aug '26

31 Aug '26

Hi, https://doc.dovecot.org/2.4.5/core/plugins/acl.html#acl_global_path says that the acl_global_path config setting was removed with Dovecot 2.4.3 and one should use acl instead. But it does not explain how the new config setting should look like. The documentation further down on the page didn't help me to get the idea. While here https://doc.dovecot.org/2.4.5/core/plugins/acl.html#global-acl-file it is said that the > Global ACL file path is specified as a parameter to vfile driver in > |acl > <https://doc.dovecot.org/2.4.5/core/summaries/settings.html#acl>|, > |/etc/dovecot/dovecot-acl| in the above example. I don't see what the "above example" exactly refers to. In fact, the string "|/etc/dovecot/dovecot-acl" doesn't appear a second time on this page. Can someone give an example, how to configure a global ACL file for Dovecot >=2.4.3? -- Regards mks |

2 4

Dovecot 2.4.1 on DietPi/ARM64: Cannot move/delete any folders via IMAP, and three specific folders are unreadable (but other folders work)
by rdorau＠gmx.de 31 Aug '26

31 Aug '26

Hello, I'm running Dovecot 2.4.1 on a Raspberry Pi 4 with DietPi (Debian 13, ARM64) and had to migrate from another OS with Dovecot 2.3. My maildir is at /var/mail/mailuser. It contains many dot‑prefixed subfolders, e.g. .Archiv, .Archiv.Reisen, .Sozio. Relevant parts from doveconf -n: text dovecot_config_version = 2.4.0 auth_mechanisms = plain login dovecot_storage_version = 2.4.0 listen = * login_trusted_networks = 192.168.178.0/24 mail_driver = maildir mail_home = /var/mail/%u mail_path = /var/mail/%u protocols = imap ssl = no passdb pam { driver = pam } userdb passwd { driver = passwd } namespace inbox { inbox = yes prefix = separator = . } Problem 1: Cannot move, delete, or rename any folder via IMAP. In Thunderbird, I can move individual messages between folders, but I cannot move, rename, or delete any folder itself. This affects all folders, not just specific ones. Right‑clicking a folder and choosing “Delete”, “Rename”, or dragging a folder to another location does nothing – no error, just no effect. I have checked permissions on the maildir; mailuser owns the directories and files, and dovecot is in the mailuser group. Problem 2: Three specific folders cannot be opened (message body not loaded). Most of my archive works fine. But exactly these three folders fail: .Archiv.merk.Versicherungen.Axa (Reiserücktritt) .Archiv.merk.Versicherungen.Bavaria_Haftpflicht .Archiv.merk.Versicherungen.LVM_Auslandsreisekrankenversicherung In Thunderbird, I see the message headers, but when I try to open a message, the body stays empty. On the server, the files are intact – head shows the full header, and the messages are readable as plain files. Other folders with similar special characters (e.g. &APw-, &AOQ-, &ANY-) work without problems. So I don't think the special characters are the cause. Problem 3: doveadm mailbox list shows only INBOX and Trash. Even though the maildir contains many dot‑prefixed subfolders, doveadm mailbox list -u mailuser returns only: text Trash INBOX In Thunderbird, the subfolders appear inside INBOX (e.g. INBOX.Archiv, INBOX.Archiv.Reisen), which is basically correct. But doveadm does not list them as separate mailboxes. What I have already tried (without success): Renaming the three problematic folders to simple names (e.g. Axa_Reiseruecktritt) and creating new folders with the copied mails. Deleting Dovecot index files (dovecot.index*, dovecot-uidlist, subscriptions) and restarting Dovecot. Changing namespace separator and prefix settings. Adding dovecot to mailuser group and adjusting permissions (chmod 750). Forcing Thunderbird to re‑synchronize by deleting local .msf files – after that, the three folders sometimes disappear or become empty in Thunderbird, but the mail files remain on disk. None of this made doveadm mailbox list show the subfolders, and the three folders remain unreadable. My questions: Why does doveadm mailbox list not show the subfolders, even though they exist as dot‑prefixed directories and Thunderbird displays them? What do I need to change so that Dovecot lists them properly? Why can I not move, delete, or rename any folder via IMAP, even though moving messages works? Is this a configuration issue (e.g. missing ACL, wrong permissions, or something with the namespace)? How can I make the three unreadable folders readable again? What is the safest way to rebuild their indexes or re‑create them so that Thunderbird can open the messages? If the folder names are problematic (e.g., due to length or special characters), what is the correct way to rename them in the maildir structure so that Dovecot and Thunderbird can handle them normally? I need a method that preserves the existing mails and the folder hierarchy. I would be very grateful for any hints, because I'm stuck and have already spent many hours on this. Thank you in advance.

3 4

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

29 Aug '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 12

IMAP access problem with iOS Mail app
by Reg Barclay 28 Aug '26

28 Aug '26

Hi, We've been running Dovecot 2.3.x as IMAPS server for quite some years. It works with Thunderbird (our primary mail client), MS Outlook, K9 Mail (Android) and some iPhones / iOS Mail. But we cannot get new iPhones / new iOS to *initially* connect to the server. On the contrary, when the mail account was created in iOS years ago, it continues to work even with modern software versions on iOS. But we cannot set up the mail server on brandnew iPhones. It either loads/waits for minutes without anything happening. Or it gives some error message that an SSL connection could not be established. I've found several reports about similar problems on the web, particularly after iOS 18. Did someone of you have the same problem and managed to solve it? We have a trusted certificate from an "official" CA, so no self-signed certificate or something like that. We have many users working with the server successfully every day, even modern iPhones where the mail account was set up years ago on an older version. So it's not broken in general. The only problem is with new iPhones and the integrated iOS Mail app. Yours, Reg

2 1

Pigeonhole v2.4.5 tarball reuploaded
by Aki Tuomi 28 Aug '26

28 Aug '26

Hi! Due to logistics mistake, the pigeonhole tarball was reuploaded now to include man pages that had dropped out by mistake. No code changes or git changes sneaked in. Sorry for the inconvenience. Aki

1 0

Dovecot Security Advisory 3/2026
by Aki Tuomi 28 Aug '26

28 Aug '26

Hi! We're sharing our latest advisory with you and like to thank everyone who contributed in finding and solving those vulnerabilities. This advisory will also be published at https://documentation.open-xchange.com/dovecot/security/advisories/html/202… --- Classification: TLP:GREEN Internal reference: DOV-8476 Type: CWE-403 (Exposure of File Descriptor to Unintended Control Sphere ('File Descriptor Leak')) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2025-11-25 Solution date: 2026-08-26 Disclosure date: 2026-08-26 CVE: CVE-2026-33263 CVSS: 4.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L) Details: submission-login: Panic when mail_max_userip_connections is reached: Panic: epoll_ctl(del, 8) failed: Bad file descriptor. When mail_max_userip_connections is set (defaul t 10) and reached, submission-login can crash with epoll() panic caused by file descriptor handling issues. Risk: If running in high-security mode (default for community releases), only the new submission connection gets terminated. If running in high-performance mode (default for Pr o releases), all connections handled by the submission-login process will be terminated. The crashes can cause failure for user to send a message, or it can cause duplica te messages to be sent. If TLS is not used (in the backend server processing the submission), duplicate deliveries cannot happen, because the crash can only happen at AUT H stage. No publicly available exploits are known. Solution: Limit the number of connections handled by single submission-login process. This has a performance impact though. Update to non-vulnerable version. --- Internal reference: DOV-8874 Type: CWE-400 (Uncontrolled Resource Consumption) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-03-11 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: ylwango613@yeswehack CVE: CVE-2026-33607 CVSS: 4.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L) Details: Dovecot IMAP LIST match_sub() Exponential Backtracking — CPU Denial of Service. An attacker that has valid credentials can use IMAP LIST command to consume CPU. Risk: This can cause degradation or denial of service for IMAP. No publicly available exploits are known. Solution: Monitor system for abnormal CPU usage and kill the offending process and lock account. Alternatively install fixed version. --- Internal reference: DOV-8884 Type: CWE-400 (Uncontrolled Resource Consumption) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-03-13 Solution date: 2026-08-26 Disclosure date: 2026-08-26 CVE: CVE-2026-27852 CVSS: 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) Details: DoS by sending mail with bad header. An attacker that can send mail to a user can craft a message whose headers contain a very large number of email addresses or MIME par ameters, which causes excessive memory usage when the message is later parsed. Risk: The message is still delivered, but reading it over IMAP can exhaust the memory limit of the process and terminate it, causing denial of service for the affected user. No publicly available exploits are known. Solution: Update to non-vulnerable version. --- Internal reference: DOV-8941 Type: CWE-93 (Improper Neutralization of CRLF Sequences ('CRLF Injection')) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-03-24 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: thanos_haruki@yeswehack CVE: CVE-2026-33606 CVSS: 4.8 (CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:H/A:N) Details: dsync: Mail content can cause dsync protocol injection. Mail content stored by a user can be crafted so that it is interpreted as dsync protocol commands when an administ rator later runs dsync with the stream protocol, for example during a migration. Risk: Injected commands can modify mailbox state on the destination during migration or replication, including internal mailbox attributes that a user should not be able to set directly. It can also cause dsync errors. No publicly available exploits are known. Solution: Avoid running dsync with the stream protocol on mailboxes with untrusted content. Update to non-vulnerable version. --- Internal reference: DOV-8947 Type: CWE-655 (Insufficient Psychological Acceptability) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-03-24 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: heckintosh@yeswehack CVE: CVE-2026-33604 CVSS: 5.9 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N) Details: SMTP Smuggling via Missing Dot-Stuffing After Bare Carriage Return. An attacker that can get Dovecot to relay a message, for example through Sieve redirect or submission relay, can use a crafted line ending in the message body to bypass the outbound protection that prevents message content from being interpreted as SMTP commands. Risk: A downstream mail server that hasn't yet fixed the SMTP smuggling vulnerability can be tricked into treating part of the message body as new SMTP commands, allowing injec tion of spoofed email. This is the same vulnerability class as CVE-2023-51764 and CVE-2023-51766. No publicly available exploits are known. Solution: Where you control the receiving mail servers, ensure they reject bare carriage returns in message data. Update to non-vulnerable version. --- Internal reference: DOV-8949 Type: CWE-400 (Uncontrolled Resource Consumption) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-03-24 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: djvirus@yeswehack CVE: CVE-2026-40014 CVSS: 6.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H) Details: IMAP THREAD REFERENCES O(N²) CPU DoS via Crafted References Header (index-thread-links.c). An attacker that can send mail to a user can craft a message header that makes the IMAP THREAD command consume CPU disproportionate to the size of the message. Risk: When a mail client issues a THREAD command on the affected mailbox, this can cause degradation or denial of service for IMAP. No publicly available exploits are known. Solution: Monitor system for abnormal CPU usage, kill the offending process and remove the offending message from the affected mailbox. Update to non-vulnerable version. --- Internal reference: DOV-8991 Type: CWE-124 (Buffer Underwrite ('Buffer Underflow')) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-04-02 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: ilyar@yeswehack CVE: CVE-2026-40013 CVSS: 4.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L) Details: pigeonhole: Stack Buffer Underflow in Pigeonhole ManageSieve CHECKSCRIPT/PUTSCRIPT. An attacker that has valid credentials can submit a Sieve script containing an extreme numeric literal, which causes an out-of-bounds write when the ManageSieve service compiles the script. Risk: This causes memory corruption and an observed crash of the ManageSieve process, resulting in denial of service for script management. This might be able to be used for re mote code execution. No publicly available exploits are known. Solution: Disable the ManageSieve service if users do not need remote Sieve script management. Update to non-vulnerable version. --- Internal reference: DOV-8994 Type: CWE-400 (Uncontrolled Resource Consumption) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-04-02 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: ilyar@yeswehack CVE: CVE-2026-33605 CVSS: 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) Details: managesieve-login: Pre-auth crash. An unauthenticated attacker can crash the ManageSieve login process by sending a small malformed command before authenticating. Risk: If running in high-security mode (default for community releases), only the attacker's own connection is terminated. If running in high-performance mode (default for Pro releases), all connections handled by the same managesieve-login process are terminated. Repeating the attack can cause denial of service for Sieve script management. No publicly available exploits are known. Solution: Restrict network access to the ManageSieve service to trusted clients. Update to non-vulnerable version. --- Internal reference: DOV-9039 Type: CWE-89 (Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-04-08 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: tipsennn@yeswehack CVE: CVE-2026-40018 CVSS: 7.4 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) Details: MySQL multi-byte escaping wrong. None Risk: None No publicly available exploits are known. Solution: None --- Internal reference: DOV-9041 Type: CWE-400 (Uncontrolled Resource Consumption) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot CE core >=2.4.3 <2.4.5 First fixed revision: OX Dovecot CE core 2.4.5 Discovery date: 2026-04-08 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: ilyar@yeswehack CVE: CVE-2026-40019 CVSS: 5.9 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) Details: v2.4.3 regression: managesieve-login pre-auth infinite loop. An unauthenticated attacker can send a truncated quoted argument to the ManageSieve login process, which make s it spin in an infinite loop consuming CPU. Risk: This can cause degradation or denial of service for Sieve script management, and repeated connections can consume all available CPU on the server. No publicly available e xploits are known. Solution: Monitor system for abnormal CPU usage and kill the offending process. Restrict network access to the ManageSieve service to trusted clients. Update to non-vulnerable vers ion. --- Internal reference: DOV-9046 Type: CWE-125 (Out-of-bounds Read) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-04-08 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: tipsennn@yeswehack CVE: CVE-2026-40015 CVSS: 4.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L) Details: imap-hibernate can be crashed. An attacker that has valid credentials can open many connections to the imap-hibernate service and send invalid commands, which can intermi ttently cause an out-of-bounds read and crash the process. Risk: The crash interrupts hibernated IMAP sessions handled by the affected process, which can cause degradation of service for IMAP. No publicly available exploits are known. Solution: Disable IMAP hibernation. Update to non-vulnerable version. --- Internal reference: DOV-9047 Type: CWE-400 (Uncontrolled Resource Consumption) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-04-08 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: djvirus@yeswehack CVE: CVE-2026-40017 CVSS: 6.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H) Details: IMAP THREAD O(M³) CPU DoS via CRC32 Hash Collision in strmap (mail-index-strmap.c / hash2.c). An attacker that can send mail to a user can craft a message header whose va lues are chosen to collide in an internal hash table, which makes the IMAP THREAD command consume CPU disproportionate to the size of the message. This is a separate issu e from CVE-2026-40014 and is not addressed by that fix. Risk: Whenever a mail client issues a THREAD command on the affected mailbox, this can cause degradation or denial of service for IMAP. No publicly available exploits are known . Solution: Monitor system for abnormal CPU usage, kill the offending process and remove the offending message from the affected mailbox. Update to non-vulnerable version. --- Internal reference: DOV-9066 Type: CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-04-12 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: ilhamaf@yeswehack CVE: CVE-2026-40203 CVSS: 3.7 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N) Details: IMAP Compression Can Reveal Whether a Small Synced Email Body Matches Sender-Chosen Text. When IMAP compression is enabled, the same compression state is reused across re sponses in a session, so response sizes depend on both attacker-supplied mail and other mail in the same mailbox. Risk: An attacker that can send mail to a user and can also observe the sizes of that user's IMAP traffic can confirm whether the body of a small message matches a guessed text . Recovery of arbitrary unknown content was not demonstrated, but the attack can disclose whether a secret-like message body matches a candidate. No publicly available ex ploits are known. Solution: Disable IMAP compression. Update to non-vulnerable version. --- Internal reference: DOV-9070 Type: CWE-416 (Use After Free) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-04-14 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: ilyar@yeswehack CVE: CVE-2026-42007 CVSS: 9.1 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:H) Details: Sieve editheader RCE. An attacker that has valid credentials can use a Sieve script with the editheader extension to trigger a use-after-free in the mail editing code, an d to write memory contents beyond the intended buffer into the delivered mail. Risk: This causes memory leak and opportunity to do memory corruption during mail delivery, which can crash the delivery process and may allow execution of arbitrary code in th e context of that process. No publicly available exploits are known. Solution: Disable the Sieve editheader extension. Update to non-vulnerable version. --- Internal reference: DOV-9099 Type: CWE-284 (Improper Access Control) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-04-22 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: ilhamaf@yeswehack CVE: CVE-2026-40204 CVSS: 3.1 (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N) Details: acl: lda_mailbox_autocreate can bypass acl restrictions. None Risk: None No publicly available exploits are known. Solution: None --- Internal reference: DOV-9106 Type: CWE-287 (Improper Authentication) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.11.2 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.11.2 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-04-23 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: Noobosaurus@yeswehack CVE: CVE-2026-40205 CVSS: 5.9 (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:H/A:N) Details: OAuth2 passdb scope enforcement bypass via OR semantics in remote validation path. An attacker that holds an OAuth2 token granting only part of the required scopes can au thenticate, because when more than one scope is required in the configuration, the remote token validation paths accept a token that carries only one of them, while the l ocal token validation path correctly requires all of them. Risk: The configured authorization policy is not enforced, so a token that was granted only part of the required permissions is accepted where it should have been rejected. No publicly available exploits are known. Solution: Use local token validation where tokens can be validated locally. Update to non-vulnerable version. --- Internal reference: DOV-9109 Type: CWE-287 (Improper Authentication) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.4 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.4 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-04-23 Solution date: 2026-08-26 Disclosure date: 2026-08-26 CVE: CVE-2026-42008 CVSS: 4.3 (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N) Details: XCLIENT FORWARD= bare token not namespaced, allows nopassword injection via trusted proxy. Forwarding information received from a host listed as a trusted proxy is not ke pt separate from Dovecot's own authentication fields, so a value sent by that host can be injected as an internal authentication field. Risk: Any host permitted to act as a trusted proxy can authenticate as any user without knowing that user's password. This affects deployments whose password database honours a field that permits authentication without a password. Deployments that do not configure trusted proxies are not affected. No publicly available exploits are known. Solution: Restrict the list of trusted proxy networks to hosts that are fully under your control. Update to non-vulnerable version. --- Internal reference: DOV-9142 Type: CWE-400 (Uncontrolled Resource Consumption) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-04-27 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: ilhamaf@yeswehack CVE: CVE-2026-42395 CVSS: 4.3 (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) Details: Single NUL-Byte XCLIENT FORWARD Payload Crashes. A host listed as a trusted proxy can send forwarding information containing a NUL byte, which crashes the login process o n the following login attempt. Risk: The login process is terminated, which can cause degradation or denial of service for logins. Deployments that do not configure trusted proxies are not affected. No publi cly available exploits are known. Solution: Restrict the list of trusted proxy networks to hosts that are fully under your control. Update to non-vulnerable version. --- Internal reference: DOV-9148 Type: CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-04-27 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: D4RKCYPH3R@yeswehack CVE: CVE-2026-42393 CVSS: 3.1 (CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N) Details: doveadm_password or api key length can still be leaked with timing comparisons. The comparison used for the doveadm password and API key is not fully timing safe and can reveal the length of the configured secret. Risk: An attacker with access to the same network as the doveadm service, able to make repeated requests and measure response timing accurately, can learn the length of the sec ret, which reduces the effort needed to guess it. The secret value itself is not disclosed. No publicly available exploits are known. Solution: Restrict network access to the doveadm service to trusted clients. Update to non-vulnerable version. --- Internal reference: DOV-9223 Type: CWE-1050 (Excessive Platform Resource Consumption within a Loop) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.15 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.15 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-05-05 Solution date: 2026-08-26 Disclosure date: 2026-08-26 CVE: CVE-2026-52681 CVSS: 3.1 (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L) Details: Sieve resource usage tracking lost when active script changes. Sieve CPU resource usage is tracked in the compiled script, so an attacker that has valid credentials can r eset the accounting by repeatedly changing the active script. Compiled script files are also not removed when a script is deleted or renamed. Risk: The configured Sieve CPU limit can be bypassed, allowing sustained CPU consumption, and the leftover files increase disk consumption. Both can cause degradation of servic e for mail delivery. No publicly available exploits are known. Solution: Monitor system for abnormal CPU usage and disk consumption. Update to non-vulnerable version. --- Internal reference: DOV-9230 Type: CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-05-06 Solution date: 2026-08-26 Disclosure date: 2026-08-26 Researcher credits: djvirus@yeswehack CVE: CVE-2026-42392 CVSS: 4.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) Details: imap-urlauth leaks memory into user-visible error messages. An attacker that has valid credentials can send an invalid IMAP URLFETCH command, which causes uninitialized m emory to be included in the error response returned to the client. Risk: Process memory contents can be disclosed to the client, which may include sensitive data. No publicly available exploits are known. Solution: Disable the IMAP URLAUTH functionality. Update to non-vulnerable version. --- Internal reference: DOV-9309 Type: CWE-287 (Improper Authentication) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.13 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.13 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-05-28 Solution date: 2026-08-26 Disclosure date: 2026-08-26 CVE: CVE-2026-73208 CVSS: 7.4 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) Details: auth: db-oauth2: aud claim used as fallback for missing scope claim. An attacker that holds a token intended for a different purpose can authenticate, because when an OAu th2 token response does not contain a scope claim, the audience claim is used in its place and checked against the configured required scopes. These are different concept s, and the audience claim does not describe what a token is allowed to do. Risk: A token that grants no relevant permissions can be accepted because its intended recipient value happens to match a configured scope name, granting access that should hav e been denied. It also hides an identity provider misconfiguration where scopes are not being issued at all. No publicly available exploits are known. Solution: Ensure the identity provider issues a scope claim for all tokens used with Dovecot, and that configured scope names do not match audience values. Update to non-vulnerable version. --- Internal reference: DOV-9401 Type: CWE-674 (Uncontrolled Recursion) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-06-10 Solution date: 2026-08-26 Disclosure date: 2026-08-26 CVE: CVE-2026-73209 CVSS: 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) Details: imap-login crash: Self-recursion on zero-output decompress chunks. An attacker that has valid credentials can send crafted compressed data that causes the affected proces s to exhaust its stack and crash. Risk: The affected process is terminated, which can cause degradation or denial of service for IMAP. No publicly available exploits are known. Solution: Update to non-vulnerable version. --- Internal reference: DOV-9529 Type: CWE-400 (Uncontrolled Resource Consumption) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.0 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.0 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-07-04 Solution date: 2026-08-26 Disclosure date: 2026-08-26 CVE: CVE-2026-42391 CVSS: 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) Details: imap: Pre-login memory/CPU growth with ID command. An unauthenticated attacker can send an IMAP ID command with a very large number of parameters before logging in, which causes memory and CPU usage to grow disproportionately. Risk: The login process can be terminated by the out-of-memory handling, which also terminates all other connections handled by the same process. This can cause degradation or denial of service for IMAP logins. No publicly available exploits are known. Solution: Limit the number of connections handled by a single imap-login process. This has a performance impact though. Update to non-vulnerable version. --- Internal reference: DOV-9530 Type: CWE-400 (Uncontrolled Resource Consumption) Component: core Report confidence: Confirmed Solution status: Fixed by vendor Affected versions: OX Dovecot Pro core >=2.3.11 <2.3.22.2, OX Dovecot Pro core >=3.0.0 <3.0.7, OX Dovecot Pro core >=3.1.0 <3.1.6, OX Dovecot CE core >=2.3.11 <2.4.5 First fixed revision: OX Dovecot Pro core 3.0.7, OX Dovecot Pro core 2.3.22.2, OX Dovecot Pro core 3.1.6, OX Dovecot CE core 2.4.5 Discovery date: 2026-07-04 Solution date: 2026-08-26 Disclosure date: 2026-08-26 CVE: CVE-2026-52687 CVSS: 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) Details: IMAP: COMPRESS ZSTD can cause excessive memory usage. An attacker that has valid credentials can select a compression algorithm for the IMAP connection whose decompressio n state requires a large amount of memory, and open several such connections. Risk: The memory limit of the process is reached with only a few connections, terminating the process and all connections it handles, which can cause degradation or denial of s ervice for IMAP. No publicly available exploits are known. Solution: Disable IMAP compression. Alternatively limit the number of connections handled by a single imap-login process, though this has a performance impact. Update to non-vulner able version.

1 0

Dovecot 2.4.2 auth unix socket rejects Postfix 3.10.6 handshake with EACCES
by root 27 Aug '26

27 Aug '26

Environment: Ubuntu 26.04 (resolute), kernel 7.0.0-30-generic, Postfix 3.10.6-4ubuntu2.1, Dovecot 2.4.2+dfsg1-3ubuntu2.1. Problem: Postfix smtpd (submission) connects to /var/spool/postfix/private/auth but write(VERSION...CPID...) returns EACCES. Log: "warning: SASL: Couldn't send handshake: Permission denied", then "fatal: no SASL authentication mechanisms". Socket permissions are correct (postfix:postfix 0660). Writing to the same socket as user postfix from python works. AppArmor in complain mode and removed profile - no change. Running postfix master manually (not via systemd) still fails. Only real smtpd process fails, python with same uid/gid succeeds. Workaround: inet listener on 127.0.0.1:3456 for auth works, AUTH succeeds.

3 2

POP3 and IMAP proxy for url filtering missmatch links and virus
by Jorge Bastos 27 Aug '26

27 Aug '26

Howdy, This is not quite dovecot related, but maybe can help me, I'm looking for a pop3/imap proxy for url check for missmatch links, and virus check of the links, Anyone knows a good tool for that? Thanks, Jorge, Howdy, This is not quite dovecot related, but maybe can help me, I'm looking for a pop3/imap proxy for url check for missmatch links, and virus check of the links, Anyone knows a good tool for that? Thanks, Jorge,

2 1

Re: Crash in imapd
by Benjamin NIVOIS 27 Aug '26

27 Aug '26

hello. perhaps not related but relevant. the root cause was a "2 bytes" empty message in the box "e-commerce" directory when Evolution starts a FETCH : >#21 0x000055d629ab5f8e in cmd_fetch (cmd=0x55d669274958) at ./src/imap/cmd-fetch.c:382 client = <optimized out> ctx = 0x55d669274ba8 args = 0x55d66927d200 next_arg = <optimized out> list_arg = 0x0 search_args = 0x0 qresync_args = {qresync_sample_seqset = 0x55d6692426d0, qresync_sample_uidset = 0x55d66929be60} messageset = 0x55d66927d370 "4764:4766,4409,2912:2917,103" send_vanished = <optimized out> ret = <optimized out> faulting message UID 2912 : no headers, 2 byes size (gdb) p mail->mail.mail.uid $2 = 2912 (gdb) p mail->mail.mail.box->vname $3 = 0x55d6692981f0 "e-commerce" doveadm fetch -u <user>"hdr" mailbox e-commerce uid 2912 hdr: doveadm fetch -u <user> "uid guid flags date.received size.physical" mailbox e-commerce uid 2912 uid: 2912 guid: d41d8cd98f00b204e9800998ecf8427e flags: Old date.received: 2020-07-17 00:05:34 size.physical: 2 basically, deleting the faulting message solved the issue. I've got the dovecot-sysreport available if needed -- Regards hello. perhaps not related but relevant. the root cause was a "2 bytes" empty message in the box "e-commerce" directory when Evolution starts a FETCH : >#21 0x000055d629ab5f8e in cmd_fetch (cmd=0x55d669274958) at ./src/imap/cmd-fetch.c:382 client = <optimized out> ctx = 0x55d669274ba8 args = 0x55d66927d200 next_arg = <optimized out> list_arg = 0x0 search_args = 0x0 qresync_args = {qresync_sample_seqset = 0x55d6692426d0, qresync_sample_uidset = 0x55d66929be60} messageset = 0x55d66927d370 "4764:4766,4409,2912:2917,103" send_vanished = <optimized out> ret = <optimized out> faulting message UID 2912 : no headers, 2 byes size (gdb) p mail->mail.mail.uid $2 = 2912 (gdb) p mail->mail.mail.box->vname $3 = 0x55d6692981f0 "e-commerce" doveadm fetch -u <user>"hdr" mailbox e-commerce uid 2912 hdr: doveadm fetch -u <user> "uid guid flags date.received size.physical" mailbox e-commerce uid 2912 uid: 2912 guid: d41d8cd98f00b204e9800998ecf8427e flags: Old date.received: 2020-07-17 00:05:34 size.physical: 2 basically, deleting the faulting message solved the issue. I've got the dovecot-sysreport available if needed -- Regards

1 1

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 21 Aug '26

21 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

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

[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 30 Jul '26

30 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