MBOX-Line: From tss at iki.fi  Mon Jul  2 10:23:26 2007
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:40 2018
Subject: [Imap-protocol] Namespace separators
In-Reply-To: <alpine.OSX.0.99.0706271146200.6426@pangtzu.panda.com>
References: <1182783681.3768.187.camel@hurina>
	<alpine.OSX.0.99.0706250816170.1955@pangtzu.panda.com>
	<1182787190.3768.198.camel@hurina>
	<alpine.OSX.0.99.0706250913080.1955@pangtzu.panda.com>
	<1182953618.3768.338.camel@hurina>
	<alpine.OSX.0.99.0706270844570.6426@pangtzu.panda.com>
	<1182966301.3768.383.camel@hurina>
	<alpine.OSX.0.99.0706271146200.6426@pangtzu.panda.com>
Message-ID: <1183397006.3768.686.camel@hurina>

On Wed, 2007-06-27 at 12:01 -0700, Mark Crispin wrote:
> On Wed, 27 Jun 2007, Timo Sirainen wrote:
> >> Any server that automatically lists all other users' mailboxes by default
> >> has huge privacy problem.
> > Not by default. I meant it lists all mailboxes where the mailbox owner
> > has given permission with ACLs (so filesystem permissions won't be
> > enough).
> 
> That isn't enough.  Most organizations consider it to be a privacy and 
> security violation to reveal the identities of other users.  There isn't 
> any ACL that applies to the userid space.

Only those users are visible to me who have shared a mailbox to me with
a +l ACL right.

> What's more, you're presuming that "shared mailboxes" is a small enough 
> set of names that is reasonable to list by default.  Suppose this is a 
> university, and every class list is in shared mailboxes.  What if your 
> client is accessed over wireless, or from a third world country in which 
> the user pays by the KB?

How's it any different from having a client show all of a separate
shared mailboxes namespace? Bad clients behave badly no matter what. :)

> > Actually it looks like Cyrus is doing exactly what I was going to:
> >
> > 1 namespace
> > * NAMESPACE (("" "/")) (("Other Users/" "/")) (("Shared Folders/" "/"))
> > 1 OK Completed
> > 2 list "" *
> > * LIST (\Noinferiors) "/" "INBOX"
> > * LIST (\HasNoChildren) "/" "Other Users/foo/support"
> > 2 OK Completed (0.000 secs 10 calls)
> 
> That is a design misfeature in Cyrus.  A server which does that doesn't 
> have namespaces.  It's apparently just using the NAMESPACE extension to 
> give a clue as to how to access those mailboxes in the default namespace.

Unfortunately this is the only way that works with all clients.

> > There you have a LIST that lists multiple namespaces. Do you consider
> > this bad as well?
> 
> Yes, this is bad; although not as bad as mashing multiple namespaces with 
> different hierarchy semantics together which is what you were talking 
> about earlier.
> 
> The bad thing is that it means that I, as the user, can not create a 
> personal hierarchy called "Other Users" or "Shared Folders" that have 
> entirely different purposes.  For some reason, undisclosed to my client 
> that does not do NAMESPACE, these name are stolen from me, and I as the 
> user will be surprised when bad things happen.

What if instead of calling it "Shared Folders" it was called "#shared"
but still listed with LIST?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20070702/06829562/attachment.sig>
