dovecot replication - new and cur folders on mx1 and mx2
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.
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.kavcic@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>
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.wierda@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.kavcic@futurion.si <mailto:tomaz.kavcic@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>
On Jan 17, 2023, at 2:49 PM, Gerben Wierda <gerben.wierda@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.wierda@rna.nl <mailto:gerben.wierda@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.kavcic@futurion.si <mailto:tomaz.kavcic@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>
participants (3)
-
Andreas Boschke
-
Gerben Wierda
-
Tomaz Kavcic