[Dovecot] IMAP to Maildir Migration preserving UIDs?

[Gedalya]

On 01/26/2012 08:00 PM, Timo Sirainen wrote:
> On 27.1.2012, at 2.57, Gedalya wrote:
>
>>>> # doveadm -o imapc_user=jedi1 at example.com -o imapc_password=***** import -u jedi1 at example.com imapc: "" all
>>>> doveadm(jedi1 at example.com): Error: Copying box=INBOX uid=1 failed: Message GUID not available in this server (guid)
>>> Fixed: http://hg.dovecot.org/dovecot-2.1/rev/f3e000992f61
>>>
>>> But doveadm import doesn't preserve UIDs.
>> OK - I got a different error from running doveadm backup on a non-broken account - see my other email :)
> The GUID error is the same. The crash is probably the result of it. Try if upgrading fixes it.
>
This is what I ended up doing. I have the production machine acting as a 
dovecot imap server, and as a proxy for accounts not yet migrated. 
Running dovecot 2.0.15, with directly attached 6 TB of storage.

Per Timo's instructions, I set up a quick VM running debian wheezy and 
the latest dovecot 2.1, and copied the config from the production server 
with tiny modifications, and connected it to the same mysql user 
database. I gave this machine the same hostname as the production 
machine, just so that the maildir filenames end up looking neat. I don't 
know if this has anything more than psychological value :-)

I mounted the storage from the production machine (sshfs surprisingly 
didn't seem slower than NFS) and set up dovecot 2.1 to find the 
mailboxes under there, then things like

doveadm -o imapc_user=jedi1 at example.com -o imapc_password=****** backup 
-u jedi1 at example.com -R imapc:/tmp/imapc

started doing the job. No output, no problems.

So far the only glitch I noticed is that I have dovecot autocreate a 
Spam folder and when starting a Windows Live Mail which was reading a 
proxied account, after it was migrated and served by dovecot, it doesn't 
find the Spam folder until I click "Download all folders". We have 
thousands of mailboxes being read from every conceivable client, so 
there will be more tiny issues like this. Can't wait to test a blackberry.

Other than that, things work as intended - UID and UIDVALIDITY seem to 
be preserved, the clients don't seem to notice the migration or react to 
it in any way.

What's left is to wrap around this a proper process to lock the mailbox, 
essentially put the right things in the database in the beginning and in 
the end of the process. Looks beautiful.