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.

