November 2022 - dovecot

Re: SSL error
by Joseph Tam 10 Nov '22

10 Nov '22

Ruben Safir <ruben(a)mrbrklyn.com> wrote: > > This got nothing to with LE or own CA. Bottom line is, you need to > > add your own CA to the cert tore (ideally) > > what is a cert tore? Someone has probably already replied to this, but it's a typo: the OP wanted to say "store". The certificate you created was used to sign itself ("self signed") and thus, asserts its own validity. If you need *other* people to trust your SSL service, you should sign your certificate using a third party authority (e.g. LetsEncrypt) to sign it. Most internet users will have these third party signing authority's certificates in their certificate store to validate your service certificate. If this is for your own personal use (i.e. you don't care about trust since you know it's your own certificate), you have to add your self-signed certificate into *your* system's certificate authority store so that your mail reader does not complain about an untrusted certificate. Clear? Joseph Tam <jtam.home(a)gmail.com>

1 0

doveadm backup|sync works for every folder but INBOX
by Ralf Becker 09 Nov '22

09 Nov '22

I'm trying to migrate an old Cyrus 2.5 server to Dovecot 2.3.19 using doveadm backup -R, which works for all folders but the INBOX itself, which always stays empty. The Cyrus side uses altnamespace:no and unixhierarchysep:no, it's used as imapc: remote in doveadm backup -R with imapc_list_prefix=INBOX Dovecot uses the following namespace to migrate into: namespace inboxes { inbox = yes location = mailbox Sent { auto = subscribe special_use = \Sent } ### some more folders omitted ### prefix = INBOX/ separator = / subscriptions = no } I use the following command line for the migration: doveadm -o imapc_features='rfc822.size fetch-headers' -o mail_prefetch_count=20 -o namespace/subs/location=mbox:/var/dovecot/subs -o imapc_user='someuser' -o imapc_password='secret' -o imapc_host=<cyrus-ip> -o imapc_list_prefix=INBOX -D backup -f -n INBOX/ -R -u someuser@somedomain imapc: The debug output contains the following lines: Nov 02 10:16:01 dsync(someuser@somedomain): Debug: brain S: Namespace INBOX/ has location imapc: Nov 02 10:16:01 dsync(someuser@somedomain): Debug: brain M: Local mailbox tree: INBOX guid=d8d5a3122bce5f63ef9101001ebfc848 uid_validity=1667223083 uid_next=1 subs=no last_change=0 last_subs=0 Nov 02 10:16:01 dsync(someuser@somedomain): Debug: brain S: Local mailbox tree: INBOX guid=c92f64f79f0d1ed01e6d5b314f04886c uid_validity=1577952633 uid_next=32691 subs=no last_change=0 last_subs=0 Nov 02 10:16:28 dsync(someuser@somedomain): Warning: Mailbox changes caused a desync. You may want to run dsync again: Remote lost mailbox GUID c92f64f79f0d1ed01e6d5b314f04886c (maybe it was just deleted?) The Cyrus server is solely used for the migration, no access from anywhere else! doveadm mailbox status -u someuser@somedomain all INBOX reports: INBOX messages=0 recent=0 uidnext=1 uidvalidity=1667223083 unseen=0 highestmodseq=1 vsize=0 guid=d8d5a3122bce5f63ef9101001ebfc848 firstsaved=never As all other folders seem ok, I blamed the failure with the INBOX on the imapc_list_prefix and altnamespace:no and tried, adding the INBOX content with an other doveadm sync run: doveadm -o imapc_features='rfc822.size fetch-headers' -o mail_prefetch_count=20 -o namespace/subs/location=mbox:/var/dovecot/subs -o imapc_user='someuser' -o imapc_password='secret' -o imapc_host=<cyrus-ip> -D sync -1 -f -m INBOX -n INBOX/ -R -u someuser@somedomain imapc: That gives the following output: Nov 02 10:55:45 dsync(someuser@somedomain): Debug: brain S: Namespace INBOX/ has location imapc: Nov 02 10:55:45 dsync(someuser@somedomain): Debug: brain M: Local mailbox tree: INBOX guid=d8d5a3122bce5f63ef9101001ebfc848 uid_validity=1667223083 uid_next=1 subs=no last_change=0 last_subs=0 Nov 02 10:55:45 dsync(someuser@somedomain): Debug: brain S: Local mailbox tree: INBOX guid=c92f64f79f0d1ed01e6d5b314f04886c uid_validity=1577952633 uid_next=32691 subs=no last_change=0 last_subs=0 Nov 02 10:55:45 dsync(someuser@somedomain): Debug: brain M: Remote mailbox tree: INBOX guid=c92f64f79f0d1ed01e6d5b314f04886c uid_validity=1577952633 uid_next=32691 subs=no last_change=0 last_subs=0 Nov 02 10:55:45 dsync(someuser@somedomain): Debug: brain S: Remote mailbox tree: INBOX guid=d8d5a3122bce5f63ef9101001ebfc848 uid_validity=1667223083 uid_next=1 subs=no last_change=0 last_subs=0 Nov 02 10:55:45 dsync(someuser@somedomain): Debug: brain M: Mailbox INBOX: local=d8d5a3122bce5f63ef9101001ebfc848/0/1, remote=c92f64f79f0d1ed01e6d5b314f04886c/0/1: GUIDs conflict - will be merged later Nov 02 10:55:45 dsync(someuser@somedomain): Debug: Mailbox INBOX: Mailbox opened Nov 02 10:55:45 dsync(someuser@somedomain): Debug: brain M: Changing mailbox INBOX GUID d8d5a3122bce5f63ef9101001ebfc848 -> c92f64f79f0d1ed01e6d5b314f04886c Nov 02 10:55:45 dsync(someuser@somedomain): Debug: dict(file): Waiting for dict to finish pending operations Nov 02 10:55:45 dsync(someuser@somedomain): Debug: brain S: Remote mailbox tree deletion: guid=c8882c0029ce5f63a9aa0000ca9feb0b type=mailbox timestamp=1667223081 name= local update=not found Nov 02 10:55:45 dsync(someuser@somedomain): Debug: brain S: Mailbox INBOX: local=c92f64f79f0d1ed01e6d5b314f04886c/0/1, remote=d8d5a3122bce5f63ef9101001ebfc848/0/1: GUIDs conflict - will be merged later Nov 02 10:55:45 dsync(someuser@somedomain): Debug: Mailbox INBOX: Mailbox opened Nov 02 10:55:45 dsync(someuser@somedomain): Debug: brain S: Ignore nonexistent mailbox GUID c92f64f79f0d1ed01e6d5b314f04886c with -1 sync Nov 02 10:55:45 dsync(someuser@somedomain): Debug: brain S: We don't have mailbox c92f64f79f0d1ed01e6d5b314f04886c Nov 02 10:55:45 dsync(someuser@somedomain): Debug: brain M: Ignoring missing remote box GUID c92f64f79f0d1ed01e6d5b314f04886c Nov 02 10:55:45 dsync(someuser@somedomain): Debug: dict(file): Waiting for dict to finish pending operations Nov 02 10:55:45 dsync(someuser@somedomain): Debug: dict(file): dict destroyed Nov 02 10:55:45 dsync(someuser@somedomain): Debug: dict(file): Waiting for dict to finish pending operations Nov 02 10:55:45 dsync(someuser@somedomain): Debug: dict(file): dict destroyed Nov 02 10:55:45 dsync(someuser@somedomain): Debug: imapc(10.44.88.3:143): Disconnected Nov 02 10:55:45 dsync(someuser@somedomain): Debug: User session is finished Nov 02 10:55:45 dsync(someuser@somedomain): Debug: dict(file): dict destroyed Nov 02 10:55:45 dsync(someuser@somedomain): Debug: dict(file): Waiting for dict to finish pending operations Nov 02 10:55:45 dsync(someuser@somedomain): Debug: dict(file): dict destroyed Nov 02 10:55:45 doveadm(40708): Debug: auth-master: conn unix:/run/dovecot/auth-userdb (pid=1,uid=0): Disconnected: Connection closed (fd=9) doveadm mailbox status -u someuser@somedomain all INBOX INBOX messages=0 recent=0 uidnext=1 uidvalidity=1667223083 unseen=0 highestmodseq=1 vsize=0 guid=c92f64f79f0d1ed01e6d5b314f04886c firstsaved=never The interesting part is that INBOX somehow seems to have two different GUIDs, depending on how I sync it (compare the two doveadm mailbox status outputs). In a tcpdump of the IMAP trafic I can see a STATUS "INBOX" (UIDNEXT UIDVALIDITY) but no EXAMINE "INBOX" or something else I would expect from the sync. I can provide the full output of doveadm backup/sync and a pcap of the IMAP trafic, but not to the public list. Any idea what's wrong with the sync of the INBOX or other suggestions / imapc parameters to use? Ralf -- Ralf Becker EGroupware GmbH [www.egroupware.org] Handelsregister HRB Kaiserslautern 3587 Geschäftsführer Birgit und Ralf Becker Leibnizstr. 17, 67663 Kaiserslautern, Germany Telefon +49 631 31657-0

3 17

"Mailbox isn't a valid MBOX file" Error
by Elise 06 Nov '22

06 Nov '22

Running currently two local mailclients: Outlook 2021 and Thunderbird 102.4.2 When using TB and remove a message on my main account, I get this error: [CANNOT] Mailbox isn't a valid mailbox On any other TB configured email accounts I can remove messages without any problems. First I thought that Outlook might block removal on messages, but the issue appears as well if I close that mail client. Can you tell what is causing this problem? Best regards, Jos Chrispijn

5 4

Any update on lazy load SNI?
by Pierre Allétru 03 Nov '22

03 Nov '22

Hi folks, We need to use SNI with Dovecot at a relatively large scale and I was wondering if there's any update on the ability to: 1 - Lazy load SNI certificates when they are needed instead of loading them all at once during startup/reload, thus taking a lot of memory and being very slow. 2 - Not having to reload Dovecot every time a new domain cert is added in conf. 3 - Or at least have Dovecot keep processing clients while the slow reload happens. This has been asked already in a 2016 thread: https://www.dovecot.org/pipermail/dovecot/2016-November/106075.html. Regarding point 3 there's a reply from Aki saying it was in the internal tasklist ( https://www.dovecot.org/pipermail/dovecot/2016-November/106089.html) Anybody knows if some progress has been made on these subjects? I can't anything in the docs or any recent information anywhere else. Thanks, -- Pierre Allétru 06 70 55 08 35 pierre.alletru(a)gmail.com

2 2

how to limit a global disk quota
by linuxguy＠gmx.net 03 Nov '22

03 Nov '22

1 0

The end of Dovecot Director?
by Steff Majeur 02 Nov '22

02 Nov '22

I recently stumbled upon the following commit on the Dovecot core Github repository: https://github.com/dovecot/core/commit/4a187116dc2311804be22724007d35732300… Apparently, Dovecot Director is going to be removed in the next major version of Dovecot and the commercial Dovecot cluster architecture will be its successor: https://github.com/dovecot/documentation/blob/a85b742ec4fc2744db30a6943b3c2… This would be a huge blow for many organizations around the world that are currently using Dovecot with Director in a shared storage environment. Can anyone of the Dovecot developers maybe enlighten us about the future of Dovecot? - Will there still be the Director feature in the next community release of Dovecot? - If not, will there be a community feature that is on par with the current Director feature? - For how long will Dovecot version 2.3 still be supported (security fixes, bug fixes)? Is there any EOL plan? Thanks for any clarification! Steff

31 56