July 2023 - dovecot - dovecot.org

[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

Recommended changes for delivery from Exim
by jgh＠exim.org 05 Feb '24

05 Feb '24

Hi, Security changes to Exim have invalidated certain suggested configurations in the Dovecot wiki. As I do not have a Dovecot installation to test, I am not going to write any updates there. It would be good if someone would test these suggestions and then make updates as needed. 1) The use of $local_part and $domain in commands run by the "pipe" transport will be disallowed in the upcoming Exim release. These are currently noted as optional, with the "-m" flag to dovecot-lda. They should be replaced with validated (untainted) versions, commonly $local_part_data and $domain_data, developed via one of the several de-taint methods documented for Exim. The same applies to $original_local_part and $original_domain. 2) The use of $sender_address will likewise be disallowed. This and the "-f" flag can be dropped from the dovecot-lda command line, and the specification of a null "message_prefix" option removed. The defaults for a pipe transport will then prefix the message with a suitable Mbox "From " header line, which dovecot-lda is documented to extract the sender from. Both of these suggestions are back-compatible to the current 4.95 release of Exim, and will be required with the 4.96 release. -- Cheers, Jeremy Refs: - https://wiki.dovecot.org/LDA/Exim - https://doc.dovecot.org/configuration_manual/protocols/lda/

3 3

JMAP support?
by Mark Constable 31 Jan '24

31 Jan '24

On Fri Jan 25 2019 Aki wrote: > There is no JMAP support in any dovecot version yet. Two years on so what is the status of JMAP support in Dovecot now?

7 10

Replication going away?
by Vladimir Mishonov 25 Jan '24

25 Jan '24

Hello everyone. Just saw this commit in the official Github repo: https://github.com/dovecot/core/commit/4c04e4c30fd4817a8b0e11d04d9681173f69… Looking at the commit details, it appears that it completely removes the replication feature. I'm a bit perplexed by this change and am not sure what might be the justification for it. Personally, I find replication to be very useful, as it allows me to maintain a synchronized mirror of all of my mailboxes on my home server, for use as backup in case the primary server goes down for some reason. Perhaps there's some sort of replacement being planned for this feature? Or maybe the relevant code is simply going to be refactored to a plugin or external program, and there's nothing to worry about at all? In any case, I'd greatly appreciate if one of the developers could comment on this change. -- Kind regards, a concerned user of Dovecot (Vladimir)

34 66

replicator: Panic: data stack: Out of memory when allocating 268435496 bytes
by Gerben Wierda 05 Dec '23

05 Dec '23

One step further in my quest to create a replacement mail server. I now have my old mail server (2.3.19.1, macOS + MacPorts) and my new (2.3.20, Alpine Linux, Docker, apk package). When I turn on replication it works, but, after a while I see: Jan 06 00:50:31 replicator: Panic: data stack: Out of memory when allocating 268435496 bytes Jan 06 00:50:32 replicator: Fatal: master: service(replicator): child 133 killed with signal 6 (core dumped) Jan 06 00:50:32 lmtp(pid 195 user sysbh): Warning: replication(sysbh): Sync failure: Jan 06 00:50:32 lmtp(pid 195 user sysbh): Warning: replication(sysbh): Remote sent invalid input: - I've removed synchronous operation for now (found a message on the net suggesting that) but is this known and what does it mean? Gerben Wierda (LinkedIn <https://www.linkedin.com/in/gerbenwierda>) R&A IT Strategy <https://ea.rna.nl/> (main site) Book: Chess and the Art of Enterprise Architecture <https://ea.rna.nl/the-book/> Book: Mastering ArchiMate <https://ea.rna.nl/the-book-edition-iii/>

6 15

Debian package for bookworm
by Claudio Corvino 14 Oct '23

14 Oct '23

Hi guys, I updated to Debian 12 but I can't find repo for bookworm on https://repo.dovecot.org/. When it will be released? Thanks! -- Claudio

8 10

bug report: lmtp fails on root-squashed NFS filesystem
by Anne Bennett 09 Oct '23

09 Oct '23

Hi, all. I'm trying to set up Postfix with dovecot LTMP delivery on a host where the user files (/var/spool/mail as well as home directories) are on NFS filesystems, which are exported root-squashed to the mail server. I definitely don't want to give the mail server root permissions on the user files. LMTP delivery fails with this logged message (e.g.): Nov 16 17:51:36 lust dovecot: lmtp(anne)<16830><mkkzEPg1lGG+QQAAs/mAJw>: msgid=<202111162229.1AGMTfAO024765(a)vindemiatrix.encs.concordia.ca>: save failed to INBOX: Read-only mbox I found this posting where someone else had a similar problem and traced it in some detail back in 2019: https://dovecot.org/list/dovecot/2019-February/114611.html but apparently no one answered the fellow. In order to check that this is indeed the same problem, I temporarily changed the INBOX definition to make it write into /var/tmp/ (on a local filesystem), and delivery worked. I then temporarily changed the INBOX definition to make it write into an NFS filesystem with root NOT squashed, and again it worked (after I chmodded the directory to 1777 to allow any user to create a file). I believe that the person who wrote the above posting is correct: at some point, file access is (incorrectly) checked as root instead of as the target user. This is a bit of a showstopper for me. Any plans to address this? I attach the output of "dovecot -n", fwiw, but I don't think that this is a configuration problem... Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne(a)encs.concordia.ca +1 514 848-2424 x2285

2 4

Compression: all or nothing?
by Alex King 02 Oct '23

02 Oct '23

Using 2.3.13 (89f716dc2) (debian package), with mdbox storage. I considering adding the zlib plugin. I understand that reading mail can cope with either compressed or uncompressed mailboxes. I'm wondering if I can leave the main storage uncompressed, while having the alternate storage compressed. There does not seem to be a way to configure this, from https://doc.dovecot.org/settings/plugin/zlib-plugin/ it seems compression (on saving emails) is an all-or-nothing option? Can I leave zlib_save unset in my main configuration, and have doveadm use some alternate configuration with zlib_save set? It doesn't look hopeful because I don't see the ability to use a different config at https://wiki.dovecot.org/Tools/Doveadm/Altmove. Perhaps I would need multiple copies of the daemon running? Or is it better just to compress everything? I plan to store older mails (perhaps 3months+) in the alternative storage, and was thinking it would be nice to have those compressed, while I don't need to compress the main store. Any feedback welcome. Thanks, Alex

2 2

auth: Panic: file oauth2-request.c assertion failed
by Urban Loesch 05 Sep '23

05 Sep '23

Hi, I'm running a postfix smtp relay server on which users are getting authenticated trough sasl via the dovecot authentication service. This works without problems. Recently I extended my configuration to authenticate users with the PLAIN mechanism against Azure AD B2C with oauth2 in the future. Important to mention is that currently no users are stored in Azure B2C. I only prepared the hole configuration and authentiucation falls back to mysql database. Now sometimes I get the error below in my logs (not permanently): ... Dec 7 11:36:49 relay-out1 dovecot: auth: Panic: file oauth2-request.c: line 201 (oauth2_request_start): assertion failed: (oauth2_valid_token(input->token)) Dec 7 11:36:49 relay-out1 dovecot: auth: Error: Raw backtrace: /usr/lib/dovecot/libdovecot.so.0(backtrace_append+0x3d) [0x7f399402e62d] -> /usr/lib/dovecot/libdovecot.so.0(backtrace_get+0x1e) [0x7f399402e74e] -> /usr/lib/dovecot/libdovecot.so.0(+0x1006eb) [0x7f399403b6eb] -> /usr/lib/dovecot/libdovecot.so.0(+0x100781) [0x7f399403b781] -> /usr/lib/dovecot/libdovecot.so.0(+0x54b7c) [0x7f3993f8fb7c] -> /usr/lib/dovecot/libdovecot.so.0(+0x4605a) [0x7f3993f8105a] -> /usr/lib/dovecot/libdovecot.so.0(oauth2_passwd_grant_start+0xfa) [0x7f3993f9870a] -> dovecot/auth(db_oauth2_lookup+0x2ca) [0x560d0804368a] -> dovecot/auth(auth_request_default_verify_plain_continue+0x2d6) [0x560d08026436] -> dovecot/auth(auth_policy_check+0x2b) [0x560d0802071b] -> dovecot/auth(+0x29f72) [0x560d0802ff72] -> dovecot/auth(auth_request_handler_auth_continue+0xf7) [0x560d0802a197] -> dovecot/auth(+0x16c62) [0x560d0801cc62] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x69) [0x7f3994051c29] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x131) [0x7f3994053251] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0x4c) [0x7f3994051ccc] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_run+0x40) [0x7f3994051e50] -> /usr/lib/dovecot/libdovecot.so.0(master_service_run+0x13) [0x7f3993fc4df3] -> dovecot/auth(main+0x415) [0x560d0801abf5] -> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f3993cee09b] -> dovecot/auth(_start+0x2a) [0x560d0801ad8a] ... After the error above postfix says the connection to the authentication server was lost: ... Dec 7 11:36:49 relay-out1 rolrelayout1/smtpd[1655601]: warning: domain.com[12.12.12.12]: SASL LOGIN authentication failed: Connection lost to authentication server ... I was able to make a core dump. ... # gdb /usr/lib/dovecot/auth core.auth.1654357.1670409409 GNU gdb (Debian 8.2.1-2+b3) 8.2.1 ... For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/lib/dovecot/auth...Reading symbols from /usr/lib/debug/.build-id/bc/f14ed9cc2dda3ee9565fbd7ccd835460008438.debug...done. done. [New LWP 1654357] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `dovecot/auth'. Program terminated with signal SIGABRT, Aborted. #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht gefunden. (gdb) bt full #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 set = {__val = {0, 1415, 1416, 94613970086496, 10, 139885273538955, 155, 139885273347109, 140724590457408, 118, 206158430224, 140724590457744, 140724590457536, 16888407779496842752, 94613970086472, 139885273131758}} pid = <optimized out> tid = <optimized out> ret = <optimized out> #1 0x00007f3993cec535 in __GI_abort () at abort.c:79 save_stage = 1 act = {__sigaction_handler = {sa_handler = 0x73f, sa_sigaction = 0x73f}, sa_mask = {__val = {1024, 18446744073709551615, 94613971926672, 94613971631792, 139885273108347, 94613970084312, 139885273090236, 94613970084312, 16888407779496842752, 94613970084288, 139885273346402, 140724590457744, 94613970084312, 140724590457744, 139885273346761, 94613970084312}}, sa_flags = -1811749030, sa_restorer = 0x5} sigs = {__val = {32, 0 <repeats 15 times>}} #2 0x00007f3993f8feaf in default_fatal_finish (status=0, type=LOG_TYPE_PANIC) at failures.c:465 backtrace = 0x560d0813e220 "/usr/lib/dovecot/libdovecot.so.0(backtrace_append+0x3d) [0x7f399402e62d] -> /usr/lib/dovecot/libdovecot.so.0(backtrace_get+0x1e) [0x7f399402e74e] -> /usr/lib/dovecot/libdovecot.so.0(+0x1006eb) [0x7f39"... backtrace = <optimized out> recursed = 0 #3 fatal_handler_real (ctx=<optimized out>, format=<optimized out>, args=<optimized out>) at failures.c:477 status = 0 #4 0x00007f399403b781 in i_internal_fatal_handler (ctx=<optimized out>, format=<optimized out>, args=<optimized out>) at failures.c:879 No locals. #5 0x00007f3993f8fb7c in i_panic (format=format@entry=0x7f399407a0e8 "file %s: line %d (%s): assertion failed: (%s)") at failures.c:530 ctx = {type = LOG_TYPE_PANIC, exit_status = 0, timestamp = 0x0, timestamp_usecs = 0, log_prefix = 0x0, log_prefix_type_pos = 0} args = {{gp_offset = 40, fp_offset = 48, overflow_arg_area = 0x7ffcff39b4e0, reg_save_area = 0x7ffcff39b420}} #6 0x00007f3993f8105a in oauth2_request_start (set=0x560d08176150, input=0x7ffcff39b5d0, callback=0x560d08042b50 <db_oauth2_lookup_passwd_grant>, context=0x560d082ffe90, p=0x560d082b7eb0, method=0x7f399407a2c6 "POST", url=0x560d08178480 "https://xxx.b2clogin.com/xxx.onmicrosoft.com/B2C_1_ropc/oauth2/v2.0/token?s…", payload=0x560d082b7ed8, add_auth_bearer=false) at oauth2-request.c:201 __func__ = "oauth2_request_start" pool = <optimized out> req = <optimized out> #7 0x00007f3993f9870a in oauth2_passwd_grant_start (set=set@entry=0x560d08176150, input=input@entry=0x7ffcff39b5d0, username=0x560d082ffe38 "user.name", password=0x560d082ffe48 "", callback=callback@entry=0x560d08042b50 <db_oauth2_lookup_passwd_grant>, context=context@entry=0x560d082ffe90) at oauth2-request.c:351 pool = 0x560d082b7eb0 payload = 0x560d082b7ed8 #8 0x0000560d0804368a in db_oauth2_lookup (db=0x560d08176060, req=0x560d082ffe90, token=<optimized out>, request=0x560d082ffba8, callback=0x560d080370b0 <oauth2_verify_plain_continue>, context=0x560d082ffba8) at db-oauth2.c:862 input = {token = 0x560d082ffe48 "", service = 0x560d082ffe20 "smtp", local_ip = {family = 2, u = {ip6 = {__in6_u = {__u6_addr8 = "\303\376\374\322", '\000' <repeats 11 times>, __u6_addr16 = {65219, 54012, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {3539795651, 0, 0, 0}}}, ip4 = {s_addr = 3539795651}}}, real_local_ip = {family = 2, u = {ip6 = {__in6_u = {__u6_addr8 = "\303\376\374\322", '\000' <repeats 11 times>, __u6_addr16 = {65219, 54012, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {3539795651, 0, 0, 0}}}, ip4 = {s_addr = 3539795651}}}, remote_ip = {family = 2, u = {ip6 = {__in6_u = {__u6_addr8 = "*\300\070\226", '\000' <repeats 11 times>, __u6_addr16 = {49194, 38456, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {2520301610, 0, 0, 0}}}, ip4 = {s_addr = 2520301610}}}, real_remote_ip = {family = 2, u = {ip6 = {__in6_u = {__u6_addr8 = "*\300\070\226", '\000' <repeats 11 times>, __u6_addr16 = { 49194, 38456, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {2520301610, 0, 0, 0}}}, ip4 = {s_addr = 2520301610}}}, local_port = 0, real_local_port = 0, remote_port = 0, real_remote_port = 0} __func__ = "db_oauth2_lookup" #9 0x0000560d08026436 in auth_request_default_verify_plain_continue (request=0x560d082ffba8, callback=0x560d0803e6f0 <plain_verify_callback>) at auth-request.c:1123 passdb = 0x560d0814da40 result = 22029 cache_key = <optimized out> error = 0x560d082ffe38 "user.name" password = 0x560d082ffe48 "" __func__ = "auth_request_default_verify_plain_continue" #10 0x0000560d0802071b in auth_policy_check (request=<optimized out>, password=<optimized out>, cb=<optimized out>, context=<optimized out>) at auth-policy.c:575 pool = <optimized out> ctx = <optimized out> #11 0x0000560d0802ff72 in mech_plain_auth_continue (request=0x560d082ffba8, data=0x560d0813d368 "user.name", data_size=30) at mech-plain.c:58 authid = <optimized out> authenid = 0x560d0813d377 "user.name" error = 0x560d0813d320 "h\323\023\b\rV" pass = 0x560d0813d388 "" i = <optimized out> len = <optimized out> count = 2 #12 0x0000560d0802a197 in auth_request_handler_auth_continue (handler=0x560d082d1ae8, args=args@entry=0x560d08268e96 "21\tdGhvbWFzLmZlcnJhcmkAdGhvbWFzLmZlcnJhcmkA") at auth-request-handler.c:738 request = 0x560d082ffba8 data = 0x560d08268e99 "dGhvbWFzLmZlcnJhcmkAdGhvbWFzLmZlcnJhcmkA" data_len = 40 buf = 0x560d0813d320 id = 21 #13 0x0000560d0801cc62 in auth_client_handle_line (line=0x560d08268e91 "CONT\t21\tdGhvbWFzLmZlcnJhcmkAdGhvbWFzLmZlcnJhcmkA", conn=0x560d08276d30) at auth-client-connection.c:228 No locals. #14 auth_client_input (conn=<optimized out>) at auth-client-connection.c:311 _data_stack_cur_id = 3 line = <optimized out> ret = <optimized out> #15 0x00007f3994051c29 in io_loop_call_io (io=0x560d0826f240) at ioloop.c:737 ioloop = 0x560d08145f80 t_id = 2 __func__ = "io_loop_call_io" #16 0x00007f3994053251 in io_loop_handler_run_internal (ioloop=ioloop@entry=0x560d08145f80) at ioloop-epoll.c:222 ctx = 0x560d08148600 events = <optimized out> event = 0x560d08148680 list = 0x560d082ae620 io = <optimized out> tv = {tv_sec = 0, tv_usec = 315566} events_count = <optimized out> msecs = <optimized out> ret = <optimized out> i = 0 j = <optimized out> call = <optimized out> __func__ = "io_loop_handler_run_internal" #17 0x00007f3994051ccc in io_loop_handler_run (ioloop=0x560d08145f80) at ioloop.c:789 __func__ = "io_loop_handler_run" #18 0x00007f3994051e50 in io_loop_run (ioloop=0x560d08145f80) at ioloop.c:762 __func__ = "io_loop_run" #19 0x00007f3993fc4df3 in master_service_run (service=0x560d08145dd0, callback=<optimized out>) at master-service.c:869 No locals. #20 0x0000560d0801abf5 in main (argc=<optimized out>, argv=<optimized out>) at main.c:393 c = <optimized out> ... And "doveconf -n": ... # 2.3.19.1 (9b53102964): /etc/dovecot/dovecot.conf # OS: Linux 5.10.0-18-amd64 x86_64 Debian 10.13 # Hostname: relay-out1.domain.com auth_cache_negative_ttl = 0 auth_cache_size = 40 M auth_cache_ttl = 30 days auth_mechanisms = plain login auth_username_chars = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_%@ auth_username_translation = %@ auth_verbose = yes auth_verbose_passwords = plain auth_worker_max_count = 100 disable_plaintext_auth = no namespace inbox { inbox = yes location = mailbox Drafts { special_use = \Drafts } mailbox Junk { special_use = \Junk } mailbox Sent { special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } mailbox Trash { special_use = \Trash } prefix = } passdb { args = /etc/dovecot/dovecot-oauth2.plain.conf.ext driver = oauth2 mechanisms = plain login } passdb { args = /etc/dovecot/dovecot-sql-account.conf driver = sql } service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } } userdb { args = /etc/dovecot/dovecot-sql-account.conf driver = sql } ... System OS is Debian 10, Dovecot installed from dovecot repository. Many thanks Urban

1 1

Bug - doveadm backup out-of-memory kill/crash when no separators set
by James Harrison 26 Aug '23

26 Aug '23

Hi, I hit a fun issue with doveadm when migrating from dovecot 2.2.36 (1f10bfa63) to 2.3.19.1 (9b53102964) (CentOS 7 to Debian 12). When running doveadm -v -D backup -R -u "user@name" tcp:localhost:1234, I found that the first sync would always work, but subsequent runs of the command would cause doveadm to reach a subfolder (Archives/2008 in the example below) and then silently mmap() increasing powers of 2 before the OOM killer finally got it. Deleting the source folder caused it to remain stuck on the same folder, but for the deletion event. I switched memory overcommit off to force a crash, and got a gdb backtrace: #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x00007ffff786bd9f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78 #2 0x00007ffff781cf32 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007ffff7807472 in __GI_abort () at ./stdlib/abort.c:79 #4 0x00007ffff7b4ffae in default_fatal_finish (status=0, type=LOG_TYPE_PANIC) at ../lib/failures.c:465 #5 fatal_handler_real (ctx=<optimized out>, format=<optimized out>, args=<optimized out>) at ../lib/failures.c:477 #6 0x00007ffff7bfa081 in default_fatal_handler (ctx=<optimized out>, format=<optimized out>, args=<optimized out>) at ../lib/failures.c:485 #7 0x00007ffff7b5017c in i_panic (format=0x7ffff7c5d748 "data stack: Out of memory when allocating %zu bytes") at ../lib/failures.c:530 #8 0x00007ffff7b4f67f in mem_block_alloc (min_size=min_size@entry=16) at ../lib/data-stack.c:386 #9 0x00007ffff7bf8b60 in t_malloc_real (size=<optimized out>, permanent=<optimized out>) at ../lib/data-stack.c:492 #10 0x00007ffff7c348f1 in t_strdup_until (start=start@entry=0x55555565f440, end=end@entry=0x55555565f448) at ../lib/strfuncs.c:270 #11 0x00005555555adc62 in convert_name_to_remote_sep (name=0x55555565f440 "Archives/2008", tree=0x55555564e188) at dsync/dsync-mailbox-tree.c:270 #12 dsync_mailbox_tree_build_name128_remotesep_hash (tree=0x55555564e188) at dsync/dsync-mailbox-tree.c:315 #13 dsync_mailbox_tree_find_delete (tree=0x55555564e188, del=0x5555556469f0) at dsync/dsync-mailbox-tree.c:405 #14 0x00005555555a4195 in dsync_brain_mailbox_tree_add_delete (tree=0x55555564e188, other_tree=0x55555564f5f8, other_del=0x5555556469f0, node_r=0x7fffffffe350, status_r=0x7fffffffe348) at dsync/dsync-brain-mailbox-tree.c:504 #15 0x00005555555a44cd in dsync_brain_recv_mailbox_tree_deletes (brain=0x55555564b2d8) at dsync/dsync-brain-mailbox-tree.c:590 #16 0x00005555555a5365 in dsync_brain_run_real (brain=brain@entry=0x55555564b2d8, changed_r=changed_r@entry=0x7fffffffe453) at dsync/dsync-brain.c:709 #17 0x00005555555a59f9 in dsync_brain_run (changed_r=0x7fffffffe453, brain=0x55555564b2d8) at dsync/dsync-brain.c:752 #18 dsync_brain_run (changed_r=0x7fffffffe453, brain=0x55555564b2d8) at dsync/dsync-brain.c:740 #19 dsync_brain_run_io (context=<optimized out>) at dsync/dsync-brain.c:113 #20 dsync_brain_run_io (context=0x55555564b2d8) at dsync/dsync-brain.c:100 #21 0x00005555555b23df in dsync_ibc_stream_input (ibc=0x555555646720) at dsync/dsync-ibc-stream.c:232 #22 0x00007ffff7c11cd9 in io_loop_call_io (io=0x5555556418f0) at ../lib/ioloop.c:737 #23 0x00007ffff7c13aa2 in io_loop_handler_run_internal (ioloop=ioloop@entry=0x55555560bf40) at ../lib/ioloop-epoll.c:222 #24 0x00007ffff7c13b50 in io_loop_handler_run (ioloop=ioloop@entry=0x55555560bf40) at ../lib/ioloop.c:789 #25 0x00007ffff7c13d10 in io_loop_run (ioloop=0x55555560bf40) at ../lib/ioloop.c:762 #26 0x000055555558b22e in cmd_dsync_run_remote (user=0x555555637248) at ./src/doveadm/doveadm-dsync.c:543 #27 cmd_dsync_run (_ctx=0x55555561f288, user=0x555555637248) at ./src/doveadm/doveadm-dsync.c:750 #28 0x000055555558bd12 in doveadm_mail_next_user (ctx=0x55555561f288, error_r=0x7fffffffe818) at ./src/doveadm/doveadm-mail.c:464 #29 0x000055555558cf45 in doveadm_mail_cmd_exec (wildcard_user=0x0, ctx=0x55555561f288) at ./src/doveadm/doveadm-mail.c:659 #30 doveadm_cmd_ver2_to_mail_cmd_wrapper (cctx=0x7fffffffe970) at ./src/doveadm/doveadm-mail.c:988 #31 0x0000555555597622 in doveadm_cmd_run_ver2 (argc=5, argv=0x55555560ba38, cctx=cctx@entry=0x7fffffffe970) at ./src/doveadm/doveadm-cmd.c:465 #32 0x0000555555597697 in doveadm_cmd_try_run_ver2 (cmd_name=<optimized out>, argc=<optimized out>, argv=<optimized out>, cctx=0x7fffffffe970) at ./src/doveadm/doveadm-cmd.c:363 #33 0x000055555557919a in main (argc=<optimized out>, argv=<optimized out>) at ./src/doveadm/doveadm.c:361 Neither server had a separator set in the inbox namespace. Having identified the convert_name_to_remote_sep function as the likely trigger point I set the separator to / on both ends, and doveadm backup now runs without issue. Can provide config if helpful but I think probably irrelevant to this one - the namespace config is the default other than the separator item. May be worth mentioning that having the separator set can avoid this condition in the doveadm backup docs - this took me a while to figure out! -- Cheers, James Harrison

2 1