[Dovecot] Hierarchy separator usage -- and a bijou bug? (was: Prayer, Maildir and Folders whose names begin with ".")
Mike Brudenell
pmb1 at york.ac.uk
Fri Mar 9 21:13:12 EET 2007
Greetings -
On 9 Mar 2007, at 17:54, Chris Wakelin wrote:
> I actually wanted "dotfiles" to be allowed to be visible (i.e. decided
> by the client), and at one time had a patch do allow this (when
> Dovecot
> hid all dotfiles to prevent access to ".imap"). I guess you're worried
> that a user will delete the folder? There are rare cases where
> access to
> client configs stored in folders has been useful, e.g. things like
> copying and pasting address books.
Our users seem to be adept at mangling things, so I was hoping to
avoid giving them the chance! :-)
> In any case, Timo's suggestion of a global ACL, together with renaming
> the folder "prayer.config" or something sounds good!
I tried using a folder name of "prayer.config" and this seems to have
shown up what I believe may be a bug in Dovecot's use of the
hierarchy separator character. More below...
So then I tried using a folder name of "!prayer" and setting the ACLs
to disallow the "l" option and that works fine.
Q. Does anyone know how much of a performance hit ACLs add? For
example the cranked-up debug logging I had turned on started moaning
that there wasn't a dovecot-acl file in each folder's directory,
implying (naturally enough) Dovecot is having to stat() each in turn
for this file when compiling the list of folders to return.
But back to the (possible?) bugs regarding hierarchy separator
character usage...
In dovecot.conf I set the hierarchy separator character for IMAP to
be "/", in line with what we are used to using here:
namespace private {
separator = /
prefix =
inbox = yes
}
In dovecot.conf I have IMAP set to use "/" as the hierarchy separator
character for mailbox names as this is what we already use with the
UW server and I was hoping to keep changeover totally transparent to
users, but now it's looking like I'm not going to be able to. (sigh)
Problem 1
---------
However creating a folder called "prayer.conf" does NOT do so.
Instead it creates a folder called "prayer" and within that a folder
called "conf".
This is going to confuse the heck out of users here who try to create
a folder such as "M.Brudenell" like they're used to and up with one
called "M" containing a sub-folder called "Brudenell". (Cleverer
conversion scripts and user education may be needed, I fear. :-(
Another example: it appears that "SELECT M.Brudenell" and "SELECT M/
Brudenell" are equivalent, even though my hierarchy separator is set
to "/"
So it appears that using hierarchy separator:
1. Enables the chosen character to be used to separate name components
on the way TO Dovecot *IN ADDITION TO* the still-operating
standard "."
and
2. Translates mailbox names coming OUT from Dovecot (in most cases: see
Problem 2 below) to use the chosen character instead of "."
and
3. Doesn't magically :-) let you use "." in folder names as you've
changed
the hierarchy separator to "/"
I guess that changing MAILDIR_FS_SEP and MAILDIR_FS_SEP_S would be
the way forward to allow "." to be present in folder names? But with
the downside that the folder structure is not truly Maildir++ compliant?
Temptation, temptation... what should I do?? Aaargghh!!
Problem 2 (possibly just cosmetic? possibly not?)
---------
When I use LIST to get a lit of mail folder they come back with "/"
used to separate name components:
a04 list "" "*"
...
* LIST (\HasNoChildren) "/" "ML/SupportCalls/00146832"
* LIST (\HasNoChildren) "/" "ML/SupportCalls/00154161"
* LIST (\HasNoChildren) "/" "ML/SupportCalls/00167267"
* LIST (\HasNoChildren) "/" "ML/SupportCalls/00167794"
* LIST (\HasNoChildren) "/" "ML/SupportCalls/00170460"
...
a04 OK List completed.
However what I use GETQUOTAROOT it instead returns the mailbox name
with a "." separating the components instead of "/"
a06 GETQUOTAROOT "ML/SupportCalls/00146832"
* QUOTAROOT "ML.SupportCalls.00146832" "pmb1"
* QUOTA "pmb1" (STORAGE 197224 512000)
a06 OK Getquotaroot completed.
Conceivably the IMAP client might try to match up the folder name in
the response with that in its request and get confused.
Basically here it appears that whilst LIST is translating the name-
components and using my chosen hierarchy separator character,
GETQUOTAROOT isn't. Looks like whatever code should re-map the
returned mailbox names to use the user-selected hierarchy separator
character isn't being called?
Cheers,
Mike B-)
--
The Computing Service, University of York, Heslington, York Yo10 5DD, UK
Tel:+44-1904-433811 FAX:+44-1904-433740
* Unsolicited commercial e-mail is NOT welcome at this e-mail address. *
More information about the dovecot
mailing list