Greetings,

Is there a mechanism (or relatively small source-code change) which would cause Dovecot to evaluate IMAP prefixes relative to $HOME rather than the configured IMAP root?

Background:

We're currently migrating from a WU-IMAP mailserver configuration which stores user mail in a global NFS-exported $HOME, and we've run into well-known issues handling client-specified IMAP prefixes.

If a user specifies an IMAP prefix, Dovecot evaluates the path given relative to the IMAP root path specified in mail_location, rather than resolving it relative to the user's home directory as our old WU-IMAP installation would do.

(For example: if a user has been keeping their mail in $HOME/foobar, and mail_location's folder path is set to %h/mail, then when that user comes to retrieve their mail with an IMAP prefix set to "~/foobar", then Dovecot will attempt to return the contents of the folder $HOME/mail/~/foobar -- which doesn't exist -- rather than $HOME/foobar.)

At the moment, we have several hidden namespaces set up to support various common user-side variations -- "mail/", "Mail/", "~/Mail/", etc. -- each with a different custom mail_location string.

Whilst this works for these common cases, it's fairly ugly, and results in extra empty directories appearing in users' $HOME.

If there was some mechanism for telling Dovecot to evaluate IMAP prefixes relative to $HOME rather than the mail folder root specified in mail_location, that would provide us with a much neater and general-purpose solution.

(I was hoping that setting full_filesystem_access=yes would do this, but it only relaxes the normal access permissions.)

Cheers, David

David McBride <dwm@tastycake.net>