MBOX-Line: From alexey.melnikov at isode.com  Tue Nov 10 01:46:45 2009
To: imap-protocol@u.washington.edu
From: Alexey Melnikov <alexey.melnikov@isode.com>
Date: Fri Jun  8 12:34:43 2018
Subject: [Imap-protocol] "k" right in IMAP ACLs
In-Reply-To: <2EEFAD8A-EA31-43FE-932D-ADFA5148786E@iki.fi>
References: <alpine.OSX.2.00.0911092020290.72789@hsinghsing.panda.com>
	<2EEFAD8A-EA31-43FE-932D-ADFA5148786E@iki.fi>
Message-ID: <4AF93685.1050801@isode.com>

Timo Sirainen wrote:
> 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 agree.
> 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?
Yes.
> 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.
Right.
> 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.
This is the behaviour prescribed by the RFC.
> 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.
There are several clients supporting read-only ACLs, e.g. Thunderbird.


