> On Jan 17, 2023, at 2:49 PM, Gerben Wierda <gerben.wie...@rna.nl> wrote:
>
> It might have a noticeable effect on clients.
>
> I encountered (probably triggered by this in some way?) that I was unable to
> het the 'read' bit set in macOS Mail.app. Maybe (as I am doing HA with round
> robin) the Mail.app client got to one dovecot repository on one tcp
> connection and then on the other.
>
> Is there a reason why syncing tis move from new to cur is a bad idea?
>
> 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/>
>
>> On 17 Jan 2023, at 22:41, Gerben Wierda <gerben.wie...@rna.nl
>> <mailto:gerben.wie...@rna.nl>> wrote:
>>
>> I can confirm this in a slightly different setting, but still using two-way
>> sync between two dovecots. On e is 2.3.19.1 running on macOS Monterey, the
>> other is 2.3.20 running in an alpine container on Ubuntu.
>>
>> 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/>
>>
>>> On 15 Jan 2023, at 23:12, Tomaz Kavcic <tomaz.kav...@futurion.si
>>> <mailto:tomaz.kav...@futurion.si>> wrote:
>>>
>>> Hello,
>>>
>>> I have a question in regards to specific dovecot replication behaviour and
>>> I'm just wondering if this is actually an expected/normal behaviour, or
>>> just a version issue.
>>>
>>> I'm using dovecot 2.3.16 which is packed by default with latest Ubuntu
>>> 22.04.1 LTS server release. I setup dovecot replication pair (mx1 - mx2)
>>> which is working ok. MX1 has priority 10, MX2 has priority 20. I use
>>> maildir (postfix + dovecot lmtp).
>>>
>>> The "strange" behaviour is this. When new mail arrives, it's by default
>>> delivered into "new" folder inside user directory. This email is then
>>> replicated to both servers (mx1 and mx2). When I login to mx1 via IMAP
>>> client (roundcube, outlook, etc.) that specific email is moved from "new"
>>> to "cur" folder on server mx1 and it's flagged also with "S", which
>>> probably means read flag. On server mx2, that email filename is also
>>> flagged with "S", but the email stays inside the "new" folder and it's not
>>> moved to "cur". If I want this email to be moved to "cur" on mx2 server, I
>>> have to login to that IMAP server as well, click on that email (which is
>>> already flagged as read), and after click, the email is also moved to "cur"
>>> on server mx2.
>>>
>>> Simply said, all new mails on mx1 server are moved to "cur" when accessed,
>>> but the stay in "new" folder on server mx2 until they're physically
>>> accessed there as well. Is this normal behaviour?
>>>
>>> I tried setup with TCP and SSH replication, and the situation is the same
>>> in all cases. Lastly, I tried TCPS (with SSL) as well, but that option has
>>> issues in 2.3.16, which is probably known already as I found multiple posts
>>> about these issues in this version.
>>>
>>> Thank you in advance for your answer and kind regards, Tomaz Kavcic.
>>>
>>> ---
>>>
>>> As suggested by mr. Timo Sarainen, this should be synced, so I'm posting
>>> doveconf -n as attachment for both servers as well.
>>>
>>> <mx1.txt><mx2.txt>
>>
>
