MBOX-Line: From guenther+imap at sendmail.com  Wed May 19 11:01:27 2010
To: imap-protocol@u.washington.edu
From: Philip Guenther <guenther+imap@sendmail.com>
Date: Fri Jun  8 12:34:43 2018
Subject: [Imap-protocol] Namespace questions
In-Reply-To: <alpine.OSX.2.00.1005190859110.29651@hsinghsing.panda.com>
References: <201005191535.o4JFZP5Q013449@mxout14.cac.washington.edu>
	<alpine.OSX.2.00.1005190859110.29651@hsinghsing.panda.com>
Message-ID: <alpine.BSO.2.00.1005191049260.23411@vanye.sendmail.com>

On Wed, 19 May 2010, Mark Crispin wrote:
> On Wed, 19 May 2010, Pete Maclean wrote:
...
> > Is it correct that the command:
> > 
> > 1 LIST "" *
> > 
> > should list mailboxes in all namespaces?
> 
> NO!!!
> 
> This command lists the mailboxes in the default namespace, which in most
> implementations is the user's private set of mailboxes.

As much as I would like to agree, I cannot suggest that to Pete.  When 
Sendmail sold an IMAP server for generic use, customer experience with the 
IMAP clients that exist in the marketplace convinced me that
	tag LIST "" *

needs to cross namespace boundaries, at least for namespaces that may 
contain mailboxes that normal users may need to access.  The state of IMAP 
client implementations, at least a few years ago, was such that doing 
otherwise meant that entire hierarchies were *completely inaccessible* 
from common clients.  Responding to a customer support call with "your 
IMAP client is broken" is a not a good way to keep a customer.  This is 
the dynamic of the market for many products.

It sucked, but I changed our implementation to cross namespace boundaries 
and the complaints all went away.


Pete: I suggest you figure out what IMAP clients are used by your target 
users and then, whatever your choice, verify how they behave against your 
implementation.  Consider the user experience and the support costs of the 
behaviors you see and tune from there.


Philip Guenther

