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 <[EMAIL PROTECTED]>
signature.asc
Description: OpenPGP digital signature
