[Dovecot] Hierarchy separator usage -- and a bijou bug? (was: Prayer, Maildir and Folders whose names begin with ".")

[Mike Brudenell]

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. *