MBOX-Line: From mrc at CAC.Washington.EDU  Wed Jun 27 12:01:24 2007
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc@CAC.Washington.EDU>
Date: Fri Jun  8 12:34:40 2018
Subject: [Imap-protocol] Namespace separators
In-Reply-To: <1182966301.3768.383.camel@hurina>
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>
Message-ID: <alpine.OSX.0.99.0706271146200.6426@pangtzu.panda.com>

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.

> I guess this all depends on what kinds of namespaces you have. Having a 
> #news. namespace listed using LIST is bad, but I think having "shared 
> mailboxes" namespace visible with LIST isn't.

It should be visible only if you are listing the shared mailboxes 
namespace.

If you list the shared mailboxes namespace in a list of the default 
namespace, then you do not have a shared mailboxes namespace.  You have 
shared mailboxes in the default namespace.

Either implement a namespace or mash everything into the default 
namespace.  Don't do one and pretend that you are doing the other.

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?

Think about the scaling implications!

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

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

>> This happens with stupid clients that implement NAMESPACE and then proceed
>> to list all of those.  The user complaints are continuous and regular:
>> they want to know how to delete these junk names from their account.
> I've actually no idea how I would implement NAMESPACE support for
> clients in a way you consider good.

The default namespace is the user's own mailboxes.

Using the # convention and/or some well-defined alternative leading 
character breakout (such as UNIX ~ and /), enable access to mailboxes that 
are other than the user's own.

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

