mailing list archives

meli community discussions

⚠️ if something does not work as intended when interracting with the mailing lists,
reach out Github mirror Gitea repo @epilys:matrix.org

E-mail headers
From: Dan Karp <dkarp@zimbra.com>
To: imap-protocol@u.washington.edu
Date: Fri, 08 Jun 2018 12:34:40 -0000
Message-ID: 1274724802.313211186077130557.JavaMail.root@dogfood.zimbra.com permalink / raw / eml / mbox
If an IMAP server supports NAMESPACE and defines "other users' namespaces" and/or "shared namespaces" prefixes, should mailboxes beneath these prefix roots be included or omitted from wildcarded LIST/LSUB requests?

For example, if

      C: A001 NAMESPACE
      S: * NAMESPACE (("" "/")) NIL (("Public Folders/" "/"))
      S: A001 OK NAMESPACE command completed

and

      C: A002 SUBSCRIBE "Public Folders/client1"
      S: A002 OK SUBSCRIBE command completed

then should "Public Folders/client1" be returned in either of these?

      C: A003 LIST "" "*"

      C: A004 LSUB "" "*"

My guess is that the answer is "no", but I'm just extrapolating from this bit in RFC 2342 section 5:

   A client can construct a LIST command by appending a "%" to the Other
   Users' Namespace prefix to discover the Personal Namespaces of other
   users that are available to the currently authenticated user.

   A server MAY return a LIST response containing only the names of
   users that have explicitly granted access to the user in question.

   Alternatively, a server MAY return NO to such a LIST command,
   requiring that a user name be included with the Other Users'
   Namespace prefix before listing any other user's mailboxes.
Reply
E-mail headers
From: mrc@CAC.Washington.EDU
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:40 -0000
Message-ID: alpine.OSX.0.999.0708021056110.5867@pangtzu.panda.com permalink / raw / eml / mbox
You are correct.

The whole point of namespaces is to have separate distinguishable 
hierarchies.  So, no, other namespaces should not be listed in the default 
namespace (= "*" should not list mailboxes in other namespaces).

The fundamental flaw of a namespace name like "Public Folders/", as 
opposed to using the # convention described in RFC 3501 (for example, 
"#public/"), is that it is not distinguishable.  Such names create 
ambiguity and cause the confusion over whether they are listed in the 
default hierarchy (and why or why not).

That's why I've told people, unsuccessfully, for years not to use such 
names.  Sometimes, the only way to learn is to experience the consequences 
of a wrongheaded course of action.

Use the RFC 3501 namespace convention and/or well-known breakout 
characters (such as the hierarchy delimiter, or ~ in a UNIX filesystem) to 
separate your hierarchies.  Then you won't have this problem.

Ignore this advice, and be forever doomed to confusion as to what the hell 
a namespace is compared to a top-level hierarchical name, not to mention 
the ongoing support problems.

-- 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.
Reply