- dovecot - dovecot.org

Is this a bug of `doveadm mailbox metadata set` with `-A` and `-s ""`
by Zhang Huangbin 24 Apr '26

24 Apr '26

Dear all, Recently i encountered an issue with `doveadm mailbox metadata set` (and `unset`) with either `-A` or `-F <path>`. When i run `doveadm mailbox metadata set` for single user, it correctly generates content in `dovecot-attributes` file: ``` doveadm mailbox metadata set -u <email> -s "" "/private/vendor/vendor.dovecot/http-notify" "user=all" ``` But if i run with `-A`, or `-F <path>`, Dovecot generates incorrect "path" and unreadable characters in `dovecot-attributes` file: ``` # doveadm mailbox metadata set -A -s "" "/private/vendor/vendor.dovecot/http-notify" "user=all" # for i in $(find . -name 'dovecot-attributes'); do echo $i; cat $i; done priv/4898662293abe1690d9a000063130d18/vendor/vendor.dovecot/pvt/server/?????? user=all priv/90e7b40fc8c1e9690924000063130d18/vendor/vendor.dovecot/pvt/server/vendor/vendor.dovecot/http-notify user=all priv/60ba353790c1e969f923000063130d18/vendor/vendor.dovecot/pvt/server/endor.dovecot/pvt/server/CV?? user=all ``` It's ok if i specify the mailbox in -s, for example: `-s "INBOX"`, `-s "Sent"`, but it's not what i want, because only emails delivered to specified mailbox will be pushed. Is this a bug?

1 1

[Bug Report] anvil panic: anvil-connection.c:727: unreached triggered by duplicate imap-login handshake with pid=-1
by Jeff Aitken 24 Apr '26

24 Apr '26

Environment: FreeBSD 14.4-RELEASE Dovecot 2.4.3 (e278b1e09b) Pigeonhole 2.4.3 (0bf9ee48) Postfix 3.11.1, rspamd 4.0.0 Description: The dovecot anvil process is crashing repeatedly with a panic in anvil-connection.c at line 727. The panic is triggered by i_unreached() in anvil_connection_destroy(). Total of ~18 crashes in the last 24 hours, happens to multiple users. The anvil process restarts successfully and works as expected other than the crashes. No other symptoms that I can see that appear related. Log messages: dovecot[87542]: anvil: Panic: file anvil-connection.c: line 727: unreached dovecot[87542]: anvil: Fatal: master: service(anvil): child 88408 killed with signal 6 (core not dumped) dovecot[87542]: anvil: Error: connect limit: disconnection for unknown (pid=88756, user=<username>, service=imap, ip=X.X.X.X, ...) dovecot[87542]: anvil: Warning: conn unix:anvil (uid=0): Handshake with duplicate service=imap-login pid=-1 - replacing the old connection Analysis (from claude): In anvil_connection_destroy(), when conn->added_to_hash is true, the code asserts that the connection must still be present in anvil_connections_hash. However, when a duplicate handshake is received for the same (service, pid) key, the old connection appears to be evicted from the hash table without clearing its added_to_hash flag. When the old connection is subsequently destroyed, hash_table_lookup_full() fails to find it, triggering i_unreached(). The pid=-1 in the duplicate handshake warning is also notable — this does not appear to be a valid process ID and may indicate that the handshake is being sent before the imap-login process has fully initialized. Workaround: Setting service_restart_request_count = unlimited and service_process_min_avail = 2 on the imap-login service seems to have reduces process turnover and appears to have reduced the frequency of the crash, but I’ve only got a couple of hours since that change so too early to say for sure. Suggested fix: When a duplicate handshake causes an existing connection to be evicted from anvil_connections_hash, the evicted connection's added_to_hash flag should be cleared to prevent the assertion failure in anvil_connection_destroy(). Appreciate any insight, and happy to provide additional info that would be helpful. —Jeff

1 0

Unable to get Dovecot 2.4 to allow unencrypted connection
by David Koski 24 Apr '26

24 Apr '26

Hello, In spite of: ssl = no auth_allow_cleartext = yes ..in a telnet session, I get: * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ STARTTLS LOGINDISABLED AUTH=GSSAPI AUTH=CRAM-MD5] Dovecot (Debian) ready. a1 login ln(a)zample.com <super-secret> * BAD [ALERT] Plaintext authentication not allowed without SSL/TLS, but your client did it anyway. If anyone was listening, the password was exposed. a1 NO [PRIVACYREQUIRED] Plaintext authentication disallowed on non-secure (SSL/TLS) connections. I need to see the network traffic to troubleshoot the way Outlook 2019 handles IMAP folders. Regards, David Koski dkoski(a)sutinen.com

3 9

Re: large mbox files
by Joseph Tam 23 Apr '26

23 Apr '26

On Wed, 22 Apr 2026, Marc wrote: > How are messages deleted from large mbox files, are these files > completely rewritten? I can't really believe that as some are bigger > than the free disk space available. I think it's a little better than that: bytes are shuffled up to fill the deleted message hole. I gather this from noting the difference in operation time from deleting a message from the top vs bottom of a large mailbox. Joseph Tam <jtam.home(a)gmail.com>

1 0

large mbox files
by Marc 23 Apr '26

23 Apr '26

How are messages deleted from large mbox files, are these files completely rewritten? I can't really believe that as some are bigger than the free disk space available.

2 1

doveadm expunge silently ignores multiple -u flags instead of erroring or processing all users
by Robert Kretowicz 21 Apr '26

21 Apr '26

Hello, I would like to report what I believe is a bug in doveadm expunge argument handling. Summary When multiple -u flags are passed to doveadm expunge, for example: doveadm expunge -u user1 -u user2 -u user3 mailbox '*' BEFORE 2015-01-01 the command exits with code 0 (success) but only processes one of the specified users. The remaining users are silently skipped with no warning or error message produced. Why this is a bug This is a silent failure on a destructive, irreversible operation. An administrator has no indication that most users were not processed. Good CLI tools should either: Accept multiple -u flags and process all specified users (consistent with how -F file works), or Reject the command immediately with a clear error such as: Error: -u flag specified multiple times. Use -F <file> for multiple users. Silently accepting invalid input and doing something unpredictable is the worst possible outcome, especially for a mail expunge operation. Environment OS: Debian GNU/Linux 12 (Bookworm) Dovecot version: 2.3.x (from Debian package) doveconf -n output available on request — omitted due to containing internal domain names. Workaround I am currently using bashfor user in user1 user2 user3; do doveadm expunge -u "$user" mailbox '*' BEFORE 2015-01-01 done Thank you for your time. Robert Kretowicz

2 1

undocumented changed behavior of 2.4.3 (possible bug report)
by Patrick Cernko 21 Apr '26

21 Apr '26

Hello Dovecot-Devs, hello list, while upgrading my Dovecot 2.4.2 setup to 2.4.3 I observed two instances of changed behavior. I could not find notes about those issues in the corresponding documentation (https://doc.dovecot.org/2.4.3/installation/upgrade/2.4-to-2.4.x.html) or release notes: 1. I had to change userdb_ldap_iterate_filter = (&(objectClass=posixAccount)%{if(protocol,"eq","pop3","(istIsMemberOf=POP3-users)","")}) to userdb_ldap_iterate_filter = (&(objectClass=posixAccount)%{if(protocol,"eq","pop3","(istIsMemberOf=POP3-users)","")|safe) otherwise the characters '()=' in the "true"-case of the condition got somehow "quoted" with escaped ASCII codes, which led to a broken LDAP filter string. Maybe you could add some documentation (in "Upgrading" as well as "Settings Variables") about that? 2. The behavior of sieve matches using ":matches" has changed: Example email (only the relevant header): List-Id: Dovecot Mailing List <dovecot.dovecot.org> Example Sieve script: if header :matches "List-Id" "*<dovecot*.dovecot.org>" { fileinto "dovecot"; } In 2.4.2 (and earlier) the example email matched the condition and got stored in the dovecot folder, while in 2.4.3 the condition does NOT match. As a workaround I added a '*' at the end of the match ("*<dovecot*.dovecot.org>*") to get my mails stored correctly again. Is this changed behavior for Sieve intentional or a bug? In case of a bug, could you please provide a fix? In case of intentional behavior: * Could you please explain the intention? Why was it necessary? * What would be the correct fix for the sieve example to match a List-Id header that ENDS WITH ".dovecot.org>"? * I assume, that other users on my servers will run into similar problems once I upgrade their servers. Is it possible to detect such problematic matches in Sieve scripts? E.g. "all matches without a trailing '*' are affected", ... This would give me a chance, to inform my users or even fix their scripts in advance. 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 2

Master user login attempted without master passdbs
by horst.simon.aus＠gmail.com 21 Apr '26

21 Apr '26

Hi, I have dovecot version v2.3.21.1 and my users (username(a)domain.name) are in mysql, all can logon to imap and sending mail, but when I am trying to create and enable sieve scripts from an weblient (horde webmail) it fails with authentication errors. It tries to use master user authentication and the logs are showing following: A pr 15 10:34:51 auth: Debug: client in: AUTH 1 PLAIN service=sieve secured session=yTdN4nRPFcF/AAAB lip=127.0.0.1 rip=127.0.0.1 lport=4190 rport=49429 resp=aG9yc3QAaG9yc3RAaGJzaW1vbi5uZXQAYXVnQDYmOXVzdA== (previous base64 data may contain sensitive data) Apr 15 10:34:51 auth: Info: plain(horst(a)hbsimon.net,127.0.0.1,<yTdN4nRPFcF/AAAB>): login user: Master user login attempted without master passdbs Apr 15 10:34:51 auth: Debug: auth(horst(a)hbsimon.net,127.0.0.1,<yTdN4nRPFcF/AAAB>): Auth request finished Apr 15 10:34:51 auth: Debug: auth client connected (pid=1478) Apr 15 10:34:53 auth: Debug: client passdb out: FAIL 1 user=horst(a)hbsimon.net Apr 15 10:34:53 managesieve-login: Info: Disconnected: Connection closed (auth failed, 1 attempts in 2 secs): user=<horst(a)hbsimon.net>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured, session=<yTdN4nRPFcF/AAAB> Apr 15 10:35:06 auth: Debug: client in: AUTH 1 PLAIN service=sieve secured session=VEgr43RPGMF/AAAB lip=127.0.0.1 rip=127.0.0.1 lport=4190 rport=49432 resp=aG9yc3QAaG9yc3RAaGJzaW1vbi5uZXQAYXVnQDYmOXVzdA== (previous base64 data may contain sensitive data) Apr 15 10:35:06 auth: Info: plain(horst(a)hbsimon.net,127.0.0.1,<VEgr43RPGMF/AAAB>): login user: Master user login attempted without master passdbs Apr 15 10:35:06 auth: Debug: auth(horst(a)hbsimon.net,127.0.0.1,<VEgr43RPGMF/AAAB>): Auth request finished Apr 15 10:35:06 auth: Debug: auth client connected (pid=1484) Apr 15 10:35:08 auth: Debug: client passdb out: FAIL 1 user=horst(a)hbsimon.net Apr 15 10:35:08 managesieve-login: Info: Disconnected: Connection closed (auth failed, 1 attempts in 2 secs): user=<horst(a)hbsimon.net>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured, session=<VEgr43RPGMF/AAAB> How can I bypass the master user login and use the assigned user or what should the master user be and how to create it? Thanks and Regards, Horst

4 7

Dovecot 2.4 SETQUOTA, how to allow (admin) users to set quota (and write it back to LDAP)
by Johannes Nohl 20 Apr '26

20 Apr '26

Is it true that Dovecot dismissed the functionality of SETQUOTA with version 2.4.0 - without any replacement? see https://dovecot.org/mailman3/archives/list/dovecot-news@dovecot.org/message… Does this also applies to 2.4.2 and 2.4.3, or does the mechanism of plugin imap_quota returned (manual reads that there are no options to this plugin)? IMAP always replies `c008 NO [NOPERM] Permission denied (0.001 + 0.000 secs).` If you can activate the former `quota_set` option, how to combine it with LDAP? I know that you can read Quota from LDAP with userdb field `quota_storage_size = {ldap:quotaBytes}B`. But how to set it? I also remember an old opinion that writing LDAP is to slow, you should store quota e.g. in a text file and write it back to LDAP time shifted. That would be fine for me - however, how to enable SETQUOTA then? Thank you for help. -- Johannes Nohl postmaster(a)i-t-cloud.de

3 3

Config: Reading value from file for password does not work
by René Neumann 19 Apr '26

19 Apr '26

Hi, I want to read the ldap auth-dn password from a file to avoid having it as part of the configuration (which may be checked into VCS). I specified ldap_auth_dn_password = </some/file where /some/file contains the password without extra whitespace (esp. there is no `\n`, I checked with xxd). But ldap auth does not succeed because of a wrong password. Password itself does work though, as checked with ldapsearch (even using the same file as password provider) `doveconf -x -P` *does* show the correct value. The same issue has been reported back in 2019 [1], without any reply though :-/ Any ideas? Thanks, René [1] https://dovecot.org/list/dovecot/2019-September/117100.html

2 3