50 lines
1.9 KiB
Plaintext
50 lines
1.9 KiB
Plaintext
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
|
|
|