mailing list archives

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?

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

Oh yeah, and what other rights are valid for the place that holds the ACL 
used to determine create of top-level mailboxes?  Is it just "a" and "k"?

Last but not least...

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

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

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.

> [1] If a mailbox is top-level in the hierarchy (co-equal with INBOX),
>    where is the "k" right to be found?

I think by definition this has to be up to the implementation. There is
no parent, so the server has to apply its own policy here.

This is loosely analogous to dereferencing "/.." in UNIX. There's nowhere
to go, so either you self destruct or you make something up (mapping "/.." 
to "/." in the UNIX case).

--lyndon

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

Show of hands: how many currently shipping clients support IMAP ACL?

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.

Alexey Melnikov writes:
> Timo Sirainen wrote:
>> On Nov 9, 2009, at 11:47 PM, Mark Crispin wrote:
>>> 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.

My impression (just from reading server logs) is that read-only is far 
from unheard. One of the webmail thingies is the only I can recall that 
does read-write.

Makes sense, too: It's easy to send a MYRIGHTS command and use the 
result to enable/disable e.g. a "create mailbox" button or menu entry, 
and much harder to write an edit dialog.

Now that I think about it, if a client does that, it may never run into 
the corner case that started the thread.

Arnt