January 2024 - dovecot

doveadm backup has problems with some accounts
by roger.meier＠4synergy.com 29 Apr '24

29 Apr '24

I try to setup for our mailserver (in a dc) a job backup to a secondary server (in our office) with "doveadm backup" via the -R option. (rsync , rsnapshot and so on tooks too long at the moment) For the most user accounts all work as expected, but for three users it always fails First run: /usr/bin/doveadm -Dv backup -Ru user1 tcp:mua01.domain.intra:12345 > Dec 01 08:54:21 doveadm(user1)<70126><qfzHDjyfaWXuEQEAy5X8iQ>: Debug: Mailbox INBOX: Mailbox opened because: copy caching decisions > Dec 01 08:54:22 doveadm(user1)<70126><qfzHDjyfaWXuEQEAy5X8iQ>: Warning: Deleting mailbox 'Archiv.Allgemein unsortiert': UID=1 GUID=1350559209.P2052Q54.lin-mail1.intra is missing locally > Dec 01 08:54:22 doveadm(user1)<70126><qfzHDjyfaWXuEQEAy5X8iQ>: Debug: brain M: Import Archiv.Allgemein unsortiert: Import change type=save GUID=1350559209.P2052Q54.mail1.intra UID=1 > hdr_hash= result=Reverting local change by deleting mailbox - No more local mails found > Dec 01 08:54:22 doveadm(70126): Debug: brain M: Import Archiv.Allgemein unsortiert: Saved UIDs: > Dec 01 08:54:22 doveadm(70126): Debug: auth-master: conn unix:/run/dovecot/auth-userdb (pid=661,uid=0): Disconnected: Connection closed (fd=9) So it aborts on the lines above and a incomplete maildir is on the local server. so the next doveadm try say's that he can't delete INBOX , etc. > Dec 01 09:03:33 doveadm(user1)<70169><TzH+MmKhaWUZEgEAy5X8iQ>: Error: Mailbox INBOX sync: mailbox_delete failed: INBOX can't be deleted. This a very old account on our server which was migrated over different iterations of our dovecot mailserver. The user behind the account uses outlook over years. Is the space here a problem? Another user with a similiar issue has the following error message at the end: > Dec 01 09:22:14 doveadm(user2)<70354><RU12FsWlaWXSEgEAy5X8iQ>: Debug: Mailbox INBOX: Mailbox opened because: copy caching decisions > Dec 01 09:22:56 doveadm(user2)<70354><RU12FsWlaWXSEgEAy5X8iQ>: Error: read(mua01.domain.intra) failed: EOF (last sent=mailbox, last recv=mailbox) > Dec 01 09:22:56 doveadm(70354): Debug: auth-master: conn unix:/run/dovecot/auth-userdb (pid=661,uid=0): Disconnected: Connection closed (fd=9) I see that the user has a very big inbox? when i check in the source server in the "cur" folder of the INBOX it count's around 269372 mails. Is this perhaps the issue for this message? And on the last user it looks like: Dec 01 09:25:19 doveadm(user3)<70376><UoiQAHWmaWXoEgEAy5X8iQ>: Warning: Deleting mailbox 'Entwürfe': UID=1265 GUID=1521832311.M6830P7652.mail-mx1.intra,S=1764,W=1809 is missing locally Dec 01 09:25:19 doveadm(user3)<70376><UoiQAHWmaWXoEgEAy5X8iQ>: Debug: brain M: Import Entwürfe: Import change type=save GUID=1521832311.M6830P7652.mail-mx1.intra,S=1764,W=1809 UID=1265 hdr_hash= result=Reverting local change by deleting mailbox - No more local mails found Dec 01 09:25:19 doveadm(70376): Debug: brain M: Import Entwürfe: Saved UIDs: Dec 01 09:25:19 doveadm(70376): Debug: auth-master: conn unix:/run/dovecot/auth-userdb (pid=661,uid=0): Disconnected: Connection closed (fd=9) The "Entwürfe" folder directly cannot be the issue? On the filesystem the folder has the name ".Entw&APw-rfe" and also other users has similar folders in their mailboxes. The source server has dovecot version 2.2.36 (centos 7.9.2009) and the current destination server dovecot version 2.3.16 (ubuntu 22.04 lts)

2 3

Question about line length limit in lmtp.
by Kamil Jońca 22 Apr '24

22 Apr '24

I have postfix + dovecot server. Mail for local users are saved by dovecot lmtp. Recently I got some messages from postfix: --8<---------------cut here---------------start------------->8--- 4NQ07L4h4LztXXr: breaking line > 998 bytes with <CR><LF>SPAC --8<---------------cut here---------------end--------------->8--- This is because postfix has configured with default value lmtp_line_length_limit (990). I can turn off this limit (set to 0) but I am curious if dovecot lmtp will accept so lengthty lines? Does dovecot lmtp has any line limits? KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

4 6

dsync with vurtial folder leads to mess of msg ID
by Kirill A. Korinsky 21 Apr '24

21 Apr '24

Greetings, I have a setup with two dovecot servers and dsync replication between them. On both of them I have a virtual folders, forexample All with config: mx1# cat /etc/dovecot/virtual/All/dovecot-virtual * -Trash -Trash/* -Junk -Junk/* all All virtual folders are excluded from replication because it leads to broken replication with errors like: virtual.All can't be created. So, I have. replication_dsync_parameters = -d -l 30 -U -x virtual. Unfortently, after a couple of weeks I've noticed that msg id for the same message on the different servers aren't match. For example: mx1# doveadm fetch -u kirill(a)korins.ky 'uid' mailbox virtual.All header Message-ID 'macports/macports-ports/pull/22284/c1901369454(a)github.com' uid: 157786 mx1# doveadm fetch -u kirill(a)korins.ky 'uid' mailbox INBOX header Message-ID 'macports/macports-ports/pull/22284/c1901369454(a)github.com' uid: 5561 mx1# vs mx2# doveadm fetch -u kirill(a)korins.ky 'uid' mailbox virtual.All header Message-ID 'macports/macports-ports/pull/22284/c1901369454(a)github.com' uid: 157766 mx2# doveadm fetch -u kirill(a)korins.ky 'uid' mailbox INBOX header Message-ID 'macports/macports-ports/pull/22284/c1901369454(a)github.com' uid: 5561 mx2# as you may see msgid at INBOX are matched, but it isn't true for virtual.All, here 157786 vs 157766 So, here the question: how can I sync msg id inside virtual folder on this setup? -- wbr, Kirill

2 12

Bug report: invalid \HasNoChildren in response when asterisk is used in the name
by Merijn Schering 18 Apr '24

18 Apr '24

Hi, I'm using dovecot 2.3.4.1 (f79e8e7e4). I have created a folder called "Test with *". Now when I do a command: A3 LIST "" "%" RETURN (CHILDREN STATUS (MESSAGES UNSEEN)) It responds: * STATUS Test with * ( MESSAGES 0 UNSEEN 0 ) * LIST ( \HasNoChildren \UnMarked ) / Spam But it actually has children! This only happens when I use a * character in the name. I hope you can fix this some day. Thanks! Best regards, Merijn Schering Intermesh https://www.group-office.com https://twitter.com/GroupOffice

2 4

doveadm sync - I/O has stalled
by songliny 09 Apr '24

09 Apr '24

Hi All, We are using dovecot 2.3.19.1 We created a account with more than 1000 mail folders in Maildir format to reproduce the issue. After weeks of testing, we have found a logic that may cause dsync to encounter the error - no activity for 900 seconds.... The function, dsync_ibc_stream_input, is the callback function after some data are ready for be read. This is part of what it does. o_stream_cork(ibc->output); ibc->ibc.io_callback(ibc->ibc.io_context); o_stream_uncork(ibc->output); Normally, ibc->ibc.io_callback(ibc->ibc.io_context) reads some data and then processes it. But when dsync connects over tcps, it uses function implementations in lib-ssl-iostream to send and receive data. And this simplified call stack would result in some data are read when calling o_stream_uncork o_stream_uncork => o_stream_flush => o_stream_ssl_flush_buffer => openssl_iostream_bio_sync => openssl_iostream_bio_input If some data arrive after ibc->ibc.io_callback(ibc->ibc.io_context) and before o_stre am_uncork, o_stream_uncork would read the data and then return. After o_stream_uncork returns, dsync then waits for new data to be read or written. But because the data had been read in o_stream_uncork, and there may be no new data to be read, dsync may then wait until timeout is met. It may happen, but it is hard to reproduce. If you also encounter this situation, you may try to use dsync over tcp connection. It does not read data when calling o_stream_uncork. As a result, it may not stuck. Back to the error itself, Maybe openssl-stream should not read data when doing uncork(flush)? Song-Lin Yang

2 4

2.4 ballpark release date?
by Shawn Heisey 05 Apr '24

05 Apr '24

I'm wondering whether there is a ballpark release date for Dovecot 2.4. I know an exact release date is probably not available, but can it at least be narrowed to a specific quarter? Is it likely in 2023? I have seen on previous messages that an Ubuntu repository for 22.04 (jammy) will appear with the 2.4 release. My mail server in AWS is running Ubuntu 20.04 (focal), which I have avoided upgrading for various reasons, including websites that don't work with PHP 8.1. Now the last remaining hurdle is the fact that there is no dovecot repository for jammy. I would prefer the official Dovecot repo over dovecot packages included with Ubuntu, because it's likely to be a newer release, and built from vanilla project code. At the moment jammy includes dovecot 2.3.16, which is even older than the 2.3.20 that I am running on focal from the official dovecot repo. Again, I know that a precise release date won't be possible. I'm just hoping for something like "soon" or "in about six months." Thanks, Shawn

3 5

replication timeout
by Andy Balholm 28 Mar '24

28 Mar '24

I have two Dovecot mail servers that replicate to each other. Sometimes there are delays in the synchronization, and I notice that the mail log has entries like this: Error: dsync(spokane): I/O has stalled, no activity for 600 seconds (last sent=mailbox, last recv=mailbox_state) Five minutes seems like a long time to sit there waiting with nothing happening. Is there a way to reduce this timeout so that I don't have so many replicaton connections just sitting around doing nothing? (Of course, a way to prevent the I/O stalls would be great too, but with my limited upload bandwidth, they may be unavoidable.) Andy

2 9

Crash in dovecot snippet when using imapc
by John van der Kamp 20 Mar '24

20 Mar '24

Hello, I've found a crash in a very specific setup. A dovecot server with imapc connection needs to receive an email with no body contents for the intent of generating a preview/snippet. It crashes somewhere deep in the jungle of istream and snapshots. I've included a script which sets up the systems to reproduce the crash. I've tested this with several versions. 2.3.16 doesn't seem to be affected, but 2.3.20 and 2.3.21 are affect. For me it produces a traceback like this, using the ubuntu version from here: https://packages.ubuntu.com/noble/dovecot-core (gdb) bt #0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=140530132887360) at ./nptl/pthread_kill.c:44 #1 __pthread_kill_internal (signo=6, threadid=140530132887360) at ./nptl/pthread_kill.c:78 #2 __GI___pthread_kill (threadid=140530132887360, signo=signo@entry=6) at ./nptl/pthread_kill.c:89 #3 0x00007fcfb8842476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #4 0x00007fcfb88287f3 in __GI_abort () at ./stdlib/abort.c:79 #5 0x00007fcfb8b37fe5 in default_fatal_finish (status=0, type=LOG_TYPE_PANIC) at ../lib/failures.c:465 #6 fatal_handler_real (ctx=<optimized out>, format=<optimized out>, args=<optimized out>) at ../lib/failures.c:477 #7 0x00007fcfb8be50d7 in i_internal_fatal_handler (ctx=<optimized out>, format=<optimized out>, args=<optimized out>) at ../lib/failures.c:879 #8 0x00007fcfb8b37eea in i_panic (format=0x7fcfb8c29020 "file %s: line %d (%s): assertion failed: (%s)") at ../lib/failures.c:530 #9 0x00007fcfb8b3387b in i_stream_header_filter_snapshot_free (_snapshot=<optimized out>) at ../lib-mail/istream-header-filter.c:663 #10 i_stream_header_filter_snapshot_free (_snapshot=0x55dabe297a60) at ../lib-mail/istream-header-filter.c:655 #11 0x00007fcfb8bf25ac in i_stream_snapshot_free (_snapshot=_snapshot@entry=0x55dabe29b0d0) at ../lib/istream.c:253 #12 0x00007fcfb8bf2654 in i_stream_unref (stream=0x7ffc16cc7fa0) at ../lib/istream.c:66 #13 0x00007fcfb8d96baa in index_mail_write_body_snippet (mail=0x55dabe292058) at index/index-mail.c:1151 #14 0x00007fcfb8d97e48 in index_mail_parse_bodystructure (mail=0x55dabe292058, field=MAIL_CACHE_BODY_SNIPPET) at index/index-mail.c:1551 #15 0x00007fcfb8d97fe2 in index_mail_fetch_body_snippet (value_r=0x7ffc16cc8050, mail=0x55dabe292058) at index/index-mail.c:1602 #16 index_mail_get_special (_mail=0x55dabe292058, field=<optimized out>, value_r=0x7ffc16cc8050) at index/index-mail.c:1730 #17 0x00007fcfb8d16ffe in mail_get_special (mail=mail@entry=0x55dabe292058, field=field@entry=MAIL_FETCH_BODY_SNIPPET, value_r=value_r@entry=0x7ffc16cc8050) at /home/ubuntu/dovecot/new/dovecot-2.3.21+dfsg1/src/lib-storage/mail.c:418 #18 0x000055dabc52645c in fetch_snippet (ctx=0x55dabe26e050, mail=0x55dabe292058, preview=0x55dabe28f1f8) at ./src/imap/imap-fetch-body.c:615 #19 0x000055dabc52b5cc in imap_fetch_more_int (ctx=0x55dabe26e050, cancel=false) at ./src/imap/imap-fetch.c:562 #20 0x000055dabc52b8ad in imap_fetch_more (ctx=0x55dabe26e050, cmd=0x55dabe26de98) at ./src/imap/imap-fetch.c:617 #21 0x000055dabc51fd07 in cmd_fetch (cmd=0x55dabe26de98) at ./src/imap/cmd-fetch.c:382 #22 0x000055dabc528af4 in command_exec (cmd=0x55dabe26de98) at ./src/imap/imap-commands.c:201 #23 0x000055dabc52e9e2 in client_command_input (cmd=<optimized out>) at ./src/imap/imap-client.c:1237 #24 0x000055dabc52ea96 in client_command_input (cmd=<optimized out>) at ./src/imap/imap-client.c:1307 #25 0x000055dabc52eeed in client_handle_next_command (remove_io_r=<synthetic pointer>, client=0x55dabe26d2c8) at ./src/imap/imap-client.c:1349 #26 client_handle_input (client=0x55dabe26d2c8) at ./src/imap/imap-client.c:1363 #27 0x000055dabc52f2c4 in client_input (client=0x55dabe26d2c8) at ./src/imap/imap-client.c:1407 #28 0x00007fcfb8bfe27d in io_loop_call_io (io=0x55dabe26e660) at ../lib/ioloop.c:737 #29 0x00007fcfb8bff81a in io_loop_handler_run_internal (ioloop=0x55dabe243fd0) at ../lib/ioloop-epoll.c:222 #30 0x00007fcfb8bff8d4 in io_loop_handler_run (ioloop=0x55dabe243fd0) at ../lib/ioloop.c:789 #31 0x00007fcfb8bffa90 in io_loop_run (ioloop=0x55dabe243fd0) at ../lib/ioloop.c:762 #32 0x00007fcfb8b6ce57 in master_service_run (service=0x55dabe243e20, callback=callback@entry=0x55dabc533210 <client_connected>) at ../lib-master/master-service.c:878 #33 0x000055dabc51ad37 in main (argc=<optimized out>, argv=<optimized out>) at ./src/imap/main.c:575 John Hello, I've found a crash in a very specific setup. A dovecot server with imapc connection needs to receive an email with no body contents for the intent of generating a preview/snippet. It crashes somewhere deep in the jungle of istream and snapshots. I've included a script which sets up the systems to reproduce the crash. I've tested this with several versions. 2.3.16 doesn't seem to be affected, but 2.3.20 and 2.3.21 are affect. For me it produces a traceback like this, using the ubuntu version from here: https://packages.ubuntu.com/noble/dovecot-core (gdb) bt #0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=140530132887360) at ./nptl/pthread_kill.c:44 #1 __pthread_kill_internal (signo=6, threadid=140530132887360) at ./nptl/ pthread_kill.c:78 #2 __GI___pthread_kill (threadid=140530132887360, signo=signo@entry=6) at ./ nptl/pthread_kill.c:89 #3 0x00007fcfb8842476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/ raise.c:26 #4 0x00007fcfb88287f3 in __GI_abort () at ./stdlib/abort.c:79 #5 0x00007fcfb8b37fe5 in default_fatal_finish (status=0, type=LOG_TYPE_PANIC) at ../lib/failures.c:465 #6 fatal_handler_real (ctx=<optimized out>, format=<optimized out>, args=<optimized out>) at ../lib/failures.c:477 #7 0x00007fcfb8be50d7 in i_internal_fatal_handler (ctx=<optimized out>, format=<optimized out>, args=<optimized out>) at ../lib/failures.c:879 #8 0x00007fcfb8b37eea in i_panic (format=0x7fcfb8c29020 "file %s: line %d (%s): assertion failed: (%s)") at ../lib/failures.c:530 #9 0x00007fcfb8b3387b in i_stream_header_filter_snapshot_free (_snapshot=<optimized out>) at ../lib-mail/istream-header-filter.c:663 #10 i_stream_header_filter_snapshot_free (_snapshot=0x55dabe297a60) at ../lib- mail/istream-header-filter.c:655 #11 0x00007fcfb8bf25ac in i_stream_snapshot_free (_snapshot=_snapshot@entry=0x55dabe29b0d0) at ../lib/istream.c:253 #12 0x00007fcfb8bf2654 in i_stream_unref (stream=0x7ffc16cc7fa0) at ../lib/ istream.c:66 #13 0x00007fcfb8d96baa in index_mail_write_body_snippet (mail=0x55dabe292058) at index/index-mail.c:1151 #14 0x00007fcfb8d97e48 in index_mail_parse_bodystructure (mail=0x55dabe292058, field=MAIL_CACHE_BODY_SNIPPET) at index/index-mail.c:1551 #15 0x00007fcfb8d97fe2 in index_mail_fetch_body_snippet (value_r=0x7ffc16cc8050, mail=0x55dabe292058) at index/index-mail.c:1602 #16 index_mail_get_special (_mail=0x55dabe292058, field=<optimized out>, value_r=0x7ffc16cc8050) at index/index-mail.c:1730 #17 0x00007fcfb8d16ffe in mail_get_special (mail=mail@entry=0x55dabe292058, field=field@entry=MAIL_FETCH_BODY_SNIPPET, value_r=value_r@entry=0x7ffc16cc8050) at /home/ubuntu/dovecot/new/dovecot-2.3.21+dfsg1/src/lib-storage/mail.c:418 #18 0x000055dabc52645c in fetch_snippet (ctx=0x55dabe26e050, mail=0x55dabe292058, preview=0x55dabe28f1f8) at ./src/imap/imap-fetch-body.c: 615 #19 0x000055dabc52b5cc in imap_fetch_more_int (ctx=0x55dabe26e050, cancel=false) at ./src/imap/imap-fetch.c:562 #20 0x000055dabc52b8ad in imap_fetch_more (ctx=0x55dabe26e050, cmd=0x55dabe26de98) at ./src/imap/imap-fetch.c:617 #21 0x000055dabc51fd07 in cmd_fetch (cmd=0x55dabe26de98) at ./src/imap/cmd- fetch.c:382 #22 0x000055dabc528af4 in command_exec (cmd=0x55dabe26de98) at ./src/imap/imap- commands.c:201 #23 0x000055dabc52e9e2 in client_command_input (cmd=<optimized out>) at ./src/ imap/imap-client.c:1237 #24 0x000055dabc52ea96 in client_command_input (cmd=<optimized out>) at ./src/ imap/imap-client.c:1307 #25 0x000055dabc52eeed in client_handle_next_command (remove_io_r=<synthetic pointer>, client=0x55dabe26d2c8) at ./src/imap/imap-client.c:1349 #26 client_handle_input (client=0x55dabe26d2c8) at ./src/imap/imap-client.c: 1363 #27 0x000055dabc52f2c4 in client_input (client=0x55dabe26d2c8) at ./src/imap/ imap-client.c:1407 #28 0x00007fcfb8bfe27d in io_loop_call_io (io=0x55dabe26e660) at ../lib/ ioloop.c:737 #29 0x00007fcfb8bff81a in io_loop_handler_run_internal (ioloop=0x55dabe243fd0) at ../lib/ioloop-epoll.c:222 #30 0x00007fcfb8bff8d4 in io_loop_handler_run (ioloop=0x55dabe243fd0) at ../ lib/ioloop.c:789 #31 0x00007fcfb8bffa90 in io_loop_run (ioloop=0x55dabe243fd0) at ../lib/ ioloop.c:762 #32 0x00007fcfb8b6ce57 in master_service_run (service=0x55dabe243e20, callback=callback@entry=0x55dabc533210 <client_connected>) at ../lib-master/ master-service.c:878 #33 0x000055dabc51ad37 in main (argc=<optimized out>, argv=<optimized out>) at ./src/imap/main.c:575 John

2 6

[Dovecot] doveadm delete folders ?
by Robert Schetterer 19 Feb '24

19 Feb '24

Hi , is there a feature like doveadm expunge savedbefore ... for imap folder delete ? -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria

5 10

Inconsistency in map index with dovecot v2.3.21
by John Alex. 14 Feb '24

14 Feb '24

Hi, since I upgraded dovecot to version 2.3.21 on a FreeBSD 13.2 system, I've been seeing a few occurences of the following warnings daily: Jan 11 13:13:25 dimokritos dovecot[33170]: lmtp(user1)<8209><SId/BlXNn2URIAAA+iYuTQ:T2>: Warning: mdbox /var/vmail/users/user1/mdbox/storage: Inconsistency in map index (5,40 != 5,56) Jan 11 13:13:25 dimokritos dovecot[33170]: lmtp(user1)<8209><SId/BlXNn2URIAAA+iYuTQ:T2>: Warning: fscking index file /var/vmail/users/user1/mdbox/storage/dovecot.map.index Jan 11 13:13:25 dimokritos dovecot[33170]: lmtp(user1)<8209><SId/BlXNn2URIAAA+iYuTQ:T2>: Warning: mdbox /var/vmail/users/user1/mdbox/storage: rebuilding indexes Jan 11 13:13:26 dimokritos dovecot[33170]: lmtp(user1)<8209><SId/BlXNn2URIAAA+iYuTQ:T2>: Warning: fscking index file /var/vmail/users/user1/mdbox/storage/dovecot.map.index The numbers in parentheses seem to always be of the format (x,40 != x,56) or (x,40 != x,72). I also get such errors on some users when purging (doveadm-purge fails with error 75): doveadm(user2): Warning: mdbox /var/vmail/users/user2/mdbox/storage: Inconsistency in map index (5,40 != 5,72) doveadm(user2): Warning: fscking index file /var/vmail/users/user2/mdbox/storage/dovecot.map.index doveadm(user2): Warning: mdbox /var/vmail/users/user2/mdbox/storage: rebuilding indexes doveadm(user2): Error: Purging namespace '' failed: BUG: Unknown internal error If I rerun doveadm purge for this user it completes successfully. Can anyone shed some light on what might be causing these messages? I didn't have these with 2.3.20. Should I be worried about data loss due to these index inconsistencies?

4 4