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.