- dovecot - dovecot.org

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

06 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 6

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

06 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 11

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

06 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 4

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

31 Jul '26

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

1 0

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

27 Jul '26

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

2 2

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

25 Jul '26

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

5 12

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

24 Jul '26

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

2 1

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

21 Jul '26

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

2 4

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

21 Jul '26

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

1 0

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

20 Jul '26

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

2 3