MBOX-Line: From tss at iki.fi  Mon Nov  9 21:09:45 2009
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:43 2018
Subject: [Imap-protocol] "k" right in IMAP ACLs
In-Reply-To: <alpine.OSX.2.00.0911092020290.72789@hsinghsing.panda.com>
References: <alpine.OSX.2.00.0911092020290.72789@hsinghsing.panda.com>
Message-ID: <2EEFAD8A-EA31-43FE-932D-ADFA5148786E@iki.fi>

On Nov 9, 2009, at 11:47 PM, Mark Crispin wrote:

> RFC 4314 is silent on many important details of the "k" right.  For  
> example:
>
> [1] If a mailbox is top-level in the hierarchy (co-equal with INBOX),
>    where is the "k" right to be found?

I'd say this is implementation-specific. I use a default ACL file that  
can't be modified via IMAP, at least not currently. I suppose in  
theory it could be made modifiable by accessing it via the shared user  
prefix. For example if all other users' mails were under "users/foo@bar.org 
" then that would be the root hierarchy. But that would mainly work  
for changing other users' root ACL, not that well your own..

> [2] What if the parent name doesn't have an ACL?  For example,  
> consider
>    a hierarchical namespace in which the heirarchy delimiter is simply
>    a character in the name.  Thus, a CREATE of a/b/c/d in no way
>    necessitates that a, a/b, and/or a/b/c exist; these are not only
>    \NoSelect names, they simply do not exist in any physical sense.   
> Is
>    it supposed to search up the hierarchy, first trying a/b/c, then
>    a/b, then a, and finally the who-knows-where location of top-level
>    ACL in order to determine if there is a "k" right?

I think the way you should be thinking this is how would the server  
work if it didn't support non-existing mailboxes. Then it would first  
have to create a/b, which would take its ACL from a, then a/b/c which  
would now take its ACL from a/b, etc. So yeah, basically go up until  
you find an existing mailboxes.

Actually I don't remember the RFC specifying what should happen when  
you create a child mailbox, but the best behavior I've figured so far  
is to just copy the parent's ACLs to the child. The bad thing about  
that is that if you want to change one you usually then have to change  
both of them. I should some day add support for ACLs that affect  
children directly, but then again that might make it more confusing to  
modify them via IMAP.

> I assume that the purpose of the "k" right is to allow a designated  
> administrator to create new mailboxes in a non-user shared location.  
> However, this lack of specificity of where the necessary ACL is to  
> be found for top-level names is a weakness.

My thinking was that "k" is mainly useful in public namespaces, or  
perhaps emulating that by creating shared mailboxes under some  
specific user's "shared" mailbox. In both of those cases there would  
be a parent mailbox.

> What do clients that implement IMAP ACL expect from the "k" right?

I'm not aware of any other clients than Mulberry that really supports  
ACLs. I don't know what it expects.

