90 lines
4.2 KiB
Plaintext
90 lines
4.2 KiB
Plaintext
MBOX-Line: From mrc at CAC.Washington.EDU Wed Jun 27 09:31:01 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: <1182953618.3768.338.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>
|
|
Message-ID: <alpine.OSX.0.99.0706270844570.6426@pangtzu.panda.com>
|
|
|
|
On Wed, 27 Jun 2007, Timo Sirainen wrote:
|
|
>> More importantly, what happens if the different namespaces have different
|
|
>> hierarchy semantics; different delimiters, different ways of expressing
|
|
>> root, etc.? Maybe a particular namespace doesn't have hierarchy at all.
|
|
> NAMESPACE reply returns the prefixes and you can compare those to the
|
|
> mailbox name. How is a "foo/" prefix any more ambiguous than "#foo/"
|
|
> prefix?
|
|
|
|
That makes two false assumptions:
|
|
(1) that there is such a thing as a string prefix matching (which, unlike
|
|
the # breakout character, is documented nowhere) that has priority
|
|
over other semantics.
|
|
(2) NAMESPACE is implemented and used by both client and server.
|
|
|
|
Remember, NAMESPACE is an extension, and is optional to implement for both
|
|
client and server. If the server does not implement NAMESPACE, then you
|
|
have a server which, for no apparent reason (since the only warning in the
|
|
base specification about such things is with the # breakout), changes
|
|
hierarchy semantics in a non-deterministic fashion.
|
|
|
|
Here's what you really missed, if the client does not implement NAMESPACE,
|
|
the same thing happens: you have a server which, for no apparent reason,
|
|
changes hierarchy semantics in a non-deterministic fashion!
|
|
|
|
More importantly, there is an additional false assumption, which is that a
|
|
specification can always tell you what is permitted and what is forbidden.
|
|
In any human endeavor, there is a HUGE grey area, impossible to itemize,
|
|
of behaviors which are not explictly forbidden but nonetheless should not
|
|
be done. The razor for this grey area is something called "common sense".
|
|
|
|
>> Does your server list all other users' mailboxes with that command (since
|
|
>> after all a user may have a public access mailbox)? Why not?
|
|
> I was actually going to make it do that, once support for shared
|
|
> mailboxes is finished.
|
|
|
|
Any server that automatically lists all other users' mailboxes by default
|
|
has huge privacy problem. The fact that another user's mailbox may be
|
|
accessible does not necessarily mean that it should be listed, especially
|
|
not by default in a LIST command that does not explicitly choose that
|
|
other user.
|
|
|
|
I'm trying to understand your purpose in doing this: are you trying to
|
|
drive people away from your server by adding harmful bugs? I think that
|
|
your server is valuable, if only to give maildir users an alternative to
|
|
the broken Courier server, but it'll be difficult for me to recommend your
|
|
server if it has this type of bug.
|
|
|
|
>> Does your server do an "ls -R /" for that command? Why not?
|
|
> If user's mailbox root directory is set to /, then yes..
|
|
|
|
You miss the point. If you are including other users' mailboxes and other
|
|
namespaces by default in a default-namespace list, then you are
|
|
effectively doing "ls -R /" for everybody, regardless of where their
|
|
mailbox's root directory is set.
|
|
|
|
> I've understood that many commonly used clients ignore namespaces and
|
|
> only show what is visible with LIST "" %, so I'd want to keep it
|
|
> possible to list contents of all namespaces with it.
|
|
|
|
I am trying to tell you that that is NOT a very good idea; and this is
|
|
from real-world experience.
|
|
|
|
If you do this, you are going to have a huge set of mailboxes listed, and
|
|
many users will react with "what is all this junk in my account, I need to
|
|
delete it."
|
|
|
|
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.
|
|
|
|
-- 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.
|
|
|