Courier generates new UIDVALIDITY
We just detected, that under some circumstances Courier-IMAP will generate a new UIDVALIDITY for every access to an IMAP-folder, if the folder had been created by a simple "mkdir" and not with maildirmake. Courier doesn't save his uidvalidity-file in this case.
Courier DOES generate a sticky UIDVALIDITY after the first "real" access by a User through the IMAP-SELECT-command. That's why this problem isn't a "real" problem in the world. Courier does NOT create this IMAP-UIDVALIDITY if the user just uses POP3-access, because there the UIDVALIDITY isn't used.
We have a migration scenario where we have many users with POP3-only access (so that they DO have many mails in der INBOX) and an incremental migration trough doveadm/dsync/imapc fails (caused by consequently changing UIDVALIDITYs).
doveadm just uses the IMAP EXAMINE command to open the source IMAP-folder on the Courier's side readonly. Courier DOES handle this access "readonly" and doesn't consequently doesn't generate a UIDVALIDITY-file. Instead Courier uses random UIDVALIDITYS by every access and doveadm always has to copy all mails (and duplicates them if "-1 -R" is used!).
To fix this problem and to make a migration and/or doveadm backup/sync much more reliable Dovecot should open the source folder with a SELECT command instead.
(Maybe one SELECT and then change to EXAMINE, if you think EXAMINE would be more safe.)
Maybe this is also relevant for a real permanent imapc-situation, where Dovecot/imapc is used to fix broken IMAP-implementations from an older backend.
Peer
-- Heinlein Support GmbH Schwedter Str. 8/9b, 10119 Berlin
http://www.heinlein-support.de
Tel: 030 / 405051-42 Fax: 030 / 405051-19
Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht Berlin-Charlottenburg, Geschäftsführer: Peer Heinlein -- Sitz: Berlin
On 01/15/2016 03:34 PM, Peer Heinlein wrote:
We just detected, that under some circumstances Courier-IMAP will generate a new UIDVALIDITY for every access to an IMAP-folder, if the folder had been created by a simple "mkdir" and not with maildirmake. Courier doesn't save his uidvalidity-file in this case.
Courier DOES generate a sticky UIDVALIDITY after the first "real" access by a User through the IMAP-SELECT-command. That's why this problem isn't a "real" problem in the world. Courier does NOT create this IMAP-UIDVALIDITY if the user just uses POP3-access, because there the UIDVALIDITY isn't used.
We have a migration scenario where we have many users with POP3-only access (so that they DO have many mails in der INBOX) and an incremental migration trough doveadm/dsync/imapc fails (caused by consequently changing UIDVALIDITYs).
doveadm just uses the IMAP EXAMINE command to open the source IMAP-folder on the Courier's side readonly. Courier DOES handle this access "readonly" and doesn't consequently doesn't generate a UIDVALIDITY-file. Instead Courier uses random UIDVALIDITYS by every access and doveadm always has to copy all mails (and duplicates them if "-1 -R" is used!).
To fix this problem and to make a migration and/or doveadm backup/sync much more reliable Dovecot should open the source folder with a SELECT command instead.
(Maybe one SELECT and then change to EXAMINE, if you think EXAMINE would be more safe.)
Maybe this is also relevant for a real permanent imapc-situation, where Dovecot/imapc is used to fix broken IMAP-implementations from an older backend.
SELECT drops the \Recent flags, so I don't think this should ever be done by default. But this should help: https://github.com/dovecot/core/commit/df596e34b604e6ac873de9ca92fb5df2a5fed...
participants (2)
-
Peer Heinlein
-
Timo Sirainen