We're currently in the process of organising a migration from mbox to maildir mail storage on our server, and are hoping to phase this in gradually using dovecot's capabilities. Procmail has already been configured to deliver mail to either the existing mbox or to a new maildir for the user based on the (non)existence of a .converted file in their home directory. Where we are having problems is the pop3 retrieval side of things. Basically, we're chasing a setup where dovecot will first check to see if /mail/<first letter of username>/username exists (indicating that the account has had the .converted file created and new mail has since been delivered to that user in the new maildir format). If this directory does not exist, it should fallback to retrieving mail from the as-yet unconverted mbox, /var/mail/username. We've tried different combinations of namespaces and default_mail_env values to achieve this without success. One attempt which has come particularly close was:
- Leaving /etc/dovecot.conf almost entirely default. The auto-detection ability of dovecot performs the following (output to /var/log/maillog):
Feb 28 14:57:45 mouse dovecot: pop3(joe): maildir: access(/home/joe/Maildir, rwx): failed: No such file or directory Feb 28 14:57:45 mouse dovecot: pop3(joe): maildir: couldn't find root dir Feb 28 14:57:45 mouse dovecot: pop3(joe): mbox: root exists (/home/joe/mail) Feb 28 14:57:45 mouse dovecot: pop3(joe): mbox: INBOX exists (/var/mail/joe) Feb 28 14:57:45 mouse dovecot: pop3(joe): mbox: root=/home/joe/mail, index=/home/joe/mail, inbox=/var/mail/joe Feb 28 14:57:45 mouse dovecot: pop3-login: Login: user=<joe>, method=PLAIN, rip=192.168.6.20, lip=192.168.6.2 Feb 28 14:57:45 mouse dovecot: pop3(joe): Logout. top=0/0, retr=0/ del=0/0, size=0
This is almost exactly what we're chasing, except the new Maildir is not going to be created in the user's home dir, it will be in /mail/<first letter of username>/username. All attempts to make this last adjustment have ultimately modified the behaviour of dovecot so that it only checks the one source explicity given, and then simply fails if it does not exist, unlike the unconfigured behaviour illustrated above where it is able to fallback to a secondary source. A '2nd_default_mail_env' is the type of variable I'm looking to define, if that makes it any clearer.
Any advice much appreciated, I've already searched most of the archives for this list without finding anything similar.