similar to: Dovecot replication does not replicate subscription in shared mailboxes

It happened now twice that replication created folders and mails in the wrong mailbox :( Here's the architecture we use: - 2 Dovecot (2.2.32) backends in two different datacenters replicating via a VPN connection - Dovecot directors in both datacenters talks to both backends with vhost_count of 100 vs 1 for local vs remote backend - backends use proxy dict via a unix domain socket and socat

Hi Timo, update to 2.2.32 (suggested by Aki) did not change the situation ... Am 18.09.17 um 20:49 schrieb Timo Sirainen: > On 18 Sep 2017, at 20.12, Ralf Becker <rb at egroupware.org > <mailto:rb at egroupware.org>> wrote: >> >> Hi Timo, >> >> Am 18.09.17 um 12:03 schrieb Timo Sirainen: >>> On 18 Sep 2017, at 12.10, Ralf Becker <rb at

We started using Dovecot replication between two nodes and noticed that our configured private flags (INDEXPVT) in public/shared mailboxes are not replicated. We are only replicating INBOX namespace, as we dont want to replicate content of shared mailboxes for every user again. Is there a way to replicate the INDEXPVT or is that not (yet) implemented? Dovecot versions: # 2.2.31 (65cde28):

Am 14.08.18 um 18:51 schrieb Aki Tuomi: > Try > > doveadm mailbox list -u user INBOX/* Hmm, posted that before, it lists all these undeletable mailboxes: root at ka-nfs-mail:~# doveadm mailbox list? -u <username> 'INBOX/*' | grep hbereich INBOX/[Fachbereiche INBOX/Fachbereiche INBOX/hbereiche INBOX/hbereiche/LAGen] INBOX/hbereiche/LAG INBOX/[Fachbereiche

Hi, the thing I'm actually looking for is that whether the sync causes the folder to be restored, so it might be a better idea for you to try and spot this from the logs. I assume that as an SP that you are using mail_log plugin, so that might be useful to spot if this happens. You can also try looking at the UIDVALIDITY value of the folder, it usually corresponds to the creation unixtime.

Try doveadm mailbox list -u user INBOX/* Aki > On 14 August 2018 at 19:20 Ralf Becker <rb at egroupware.org> wrote: > > > Hi Aki, > > Am 14.08.18 um 16:42 schrieb Aki Tuomi: > > Hi, > > > > the thing I'm actually looking for is that whether the sync causes the folder to be restored, so it might be a better idea for you to try and spot this from

At the moment the correct way to use shared folders in a replication pair is to access them with imapc from the other pair. Aki > On 29/10/2020 14:43 Ralf Becker <rb at egroupware.org> wrote: > > > In reference to an earlier mail from me, I'd like to ask: > > Have there been any changes in regard to INDEXPVT and replication or are > there any plans in that

No one any idea? Replication into wrong mailboxes caused by an unavailable proxy dict backend is a serious privacy and/or security problem! Ralf Am 30.10.17 um 10:05 schrieb Ralf Becker: > It happened now twice that replication created folders and mails in the > wrong mailbox :( > > Here's the architecture we use: > - 2 Dovecot (2.2.32) backends in two different datacenters

Hey all, I'm experiencing a weird and annoying issue with my 2-node dovecot replication setup. The setup is based on virtual users in a pgsql database, which is replicated from the master to a slave node. For the mails I rely on the dovecot builtin replication which has been working great for me thus far. However I noticed something was off when looking through my journal yesterday:

Hi, it seams that the lazy_expunge plugin doesn't work for me after the upgrade... 2.2.32 cry's about plugin { lazy_expunge_only_last_instance=no } is most likely handled as 'yes' - remove the setting completely to disable it. If this is intentional, add quotes around the value: lazy_expunge_only_last_instance="no" I changed it to

I have old dovecot server: (# 2.2.33.2 (d6601f4ec): /etc/dovecot/dovecot.conf # Pigeonhole version 0.4.21 (92477967) # OS: Linux 4.14.15-3.el7xen.x86_64 x86_64 CentOS Linux release 7.4.1708 (Core) and new dovecot server: # 2.3.1 (c5a5c0c82): /etc/dovecot/dovecot.conf # Pigeonhole version 0.5.devel (61b47828) # OS: Linux 4.14.47-5.el7xen.x86_64 x86_64 CentOS Linux release 7.5.1804 (Core) I try

Hi Aki, Am 14.08.18 um 16:42 schrieb Aki Tuomi: > Hi, > > the thing I'm actually looking for is that whether the sync causes the folder to be restored, so it might be a better idea for you to try and spot this from the logs. I assume that as an SP that you are using mail_log plugin, so that might be useful to spot if this happens. You can also try looking at the UIDVALIDITY value of

Hi, I have a problem using the master password feature of dovecot. I'm able to login with the password but then dovecot can't select the INBOX. IMAP test: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=SCRAM-SHA-1 AUTH=CRAM-MD5] ITronic Mail Store a login user at itronic.at*admin password a OK

I found a way to reproduce the problem :) Use an arbitrary mailbox (maybe my Dovecot config with mdbox etc. required). Then use Thunderbird (52.9.1 on Mac) to create eg. the following folder (without the quotes!): ??? "[Test / Test]" This is a space, a slash and a space between the Test in square brackets. TB now creates the following two folders: 1. "INBOX/[Test " (not

One more update, I tried renaming that "[Test " folder to just "Test", which creates an also not deletable folder "Test". Good news is, if I delete these folders on both replication nodes from mdbox/mailboxes and mdbox/subscriptions they seem to be really gone. I can event create the folder "Test" again and it behaves normal aka. I can delete it afterwards

In reference to an earlier mail from me, I'd like to ask: Have there been any changes in regard to INDEXPVT and replication or are there any plans in that direction? Thanks :) Ralf On 03.08.20 at 11:20 Ralf Becker wrote: > So far the only thing we noticed: private seen flags on shared user > folders (which were never supported for replication!) seem to be not > functioning any

Hi Aki, Am 18.09.17 um 11:22 schrieb Aki Tuomi: > On 18.09.2017 12:20, Ralf Becker wrote: >> Hi Aki, >> >> Am 18.09.17 um 11:13 schrieb Aki Tuomi: >>> On 18.09.2017 12:10, Ralf Becker wrote: >>>> Am 14.09.17 um 01:07 schrieb Timo Sirainen: >>>>> On 7 Sep 2017, at 17.42, Ralf Becker <rb at egroupware.org> wrote:

I did a debug output of the dsync-server and found out that it queries the userdb parameter but doesn't use it. --- Debug: Loading modules from directory: /usr/lib/dovecot/modules Debug: Module loaded: /usr/lib/dovecot/modules/lib01_acl_plugin.so Debug: Module loaded: /usr/lib/dovecot/modules/lib02_lazy_expunge_plugin.so Debug: Module loaded: /usr/lib/dovecot/modules/lib10_quota_plugin.so

Hello, (my) doveadm is no longer working if I use the -S socket_path. # doveadm quota get -S mbx7:542 -u myaccount doveadm(myaccount): Error: doveadm server disconnected before handshake: EOF doveadm(myaccount): Error: mbx7:542: Command quota get failed for jobsanzl: EOF Quota name Type Value Limit % The server logs: Mar 22 00:29:47 doveadm(134.147.53.150):

Hi Aki, Am 18.09.17 um 11:13 schrieb Aki Tuomi: > On 18.09.2017 12:10, Ralf Becker wrote: >> Am 14.09.17 um 01:07 schrieb Timo Sirainen: >>> On 7 Sep 2017, at 17.42, Ralf Becker <rb at egroupware.org> wrote: >>>> Dovecot 2.2.31 with mailboxes in mdbox format. >>>> >>>> Since a couple of days some mailboxes have the problem, that sieve