MBOX-Line: From mrc+imap at panda.com  Sat May 29 15:58:27 2010
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc+imap@panda.com>
Date: Fri Jun  8 12:34:43 2018
Subject: [Imap-protocol] NAMESPACE and LIST
In-Reply-To: <2082015573.1325.1275171163091.JavaMail.root@dogfood.zimbra.com>
References: <2082015573.1325.1275171163091.JavaMail.root@dogfood.zimbra.com>
Message-ID: <alpine.OSX.2.00.1005291527050.77397@hsinghsing.panda.com>

On Sat, 29 May 2010, Dan Karp wrote:
> If NAMESPACE returns
>    * NAMESPACE (("" "/")) (("/home/" "/")) NIL
> and the client issues
>    A001 LIST "/home/user4/INBOX" ""
> then should the untagged LIST reply be
>    * LIST (\NoSelect) "/" ""

Yes.

What you have in this example is a typical UNIX filesystem type export in
which other users are in the default namespace with "/home/" as the prefix
instead of the more common "~".  Since /home/ is in the default namespace,
the pattern matches it first.

This ambiguity is why you should do other-user access though "~":

 	0 namespace
 	* NAMESPACE (("" "/")) (("~" "/")) NIL
 	0 OK NAMESPACE completed
 	1 list ~user4/test ""
 	* LIST (\NoSelect \HasChildren) "/" ~user4/
 	1 OK LIST completed

or preferably (especially if you don't have to export a UNIX filesystem
hierarchy!) a separate namespace since otherwise you have to consider "~"
to be like a namespace:

 	0 namespace
 	* NAMESPACE (("" "/")) (("#user." "/")) NIL
 	0 OK NAMESPACE completed
 	1 list #user.user4/test ""
 	* LIST (\NoSelect \HasChildren) "/" #user.user4
 	1 OK LIST completed

Another design issue that you have to deal with is that certain clients
(e.g., from a convicted monopolist) can't access mailboxes in anything
other than the default namespace; and other clients will attempt to
download the complete contents of anything they find in the default
namespace.  This creates a Scylla and Charybdis problem that leads to lots
of hair pulling.  You have to consider the semantics of the default
namespace quite carefully.

For example, in my new server, the default namespace is a chimera of names
from:
  [1] user's private mailboxes (#mail/ namespace)
  [2] user's quarantine (#qt/ namespace)
  [3] a "Public Folders" (sigh on "folders", I lost that battle) pseudo
      directory that points to the user's published mailboxes in the
      #public namespace.
  [4] (future) public names published to all users, mechanism to be
      determined.

The user must have a namespace capable client to access #public mailboxes
that were not published to his default namespace, as well as other user's
private mailboxes (#user/ namespace) and (if the user is privileged) the
global quarantine.

The interesting thing here is that the default namespace is a superset of
the user's private space.  This chimera made things much easier, since it
avoided arguing about what is in the user's private space.  Also, since
the chimera is implemented by software instead of the storage layout, it's
possible to make substantial updates (and even have adminstrator
configuration) without impacting the storage.  A big benefit; since in my
experience admins make decisions without fully understanding the impact,
and the ability to change things gently is quite useful.

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

