Mailbox Namespaces

Namespace Basics

What is a namespace? A namespace is a hierarchical list of mailboxes a user has access to, named to maintain uniqueness and provide access control.

There are four different uses of the term “namespace” within Cyrus:

  1. IMAP NAMESPACE command

    This is the set of mailboxes a user has access to and is the namespace as defined by RFC 2342 in response to the IMAP NAMESPACE command.

    A user can have access to three different kinds of mailboxes: their own (known as personal), other people’s mailboxes that they have shared access to (known as other users) and any mailboxes that have more than one owner (known as shared).

    More info at User Access Namespaces.

  2. User namespace mode: altnamespace

    Cyrus’s user namespace mode controls how it responds to the IMAP NAMESPACE command and what the hierarchy of mailboxes looks like in response to an IMAP LIST command for a user. The config setting altnamespace: on or off in imapd.conf(5) manages the mode. It is also affected by the hierarchy separator, which can be “/” (default: on) or “.” (off) controlled by unixhierarchysep in imapd.conf(5).

    1. altnamespace: on (default)

      • personal: “” (empty string)

      • other users: “Other Users” (The string can be changed in imapd.conf(5) with userprefix)

      • shared: “Shared Folders” (The string can be changed in imapd.conf(5) with sharedprefix)

    2. altnamespace: off (was known as standard or regular)

      • personal: INBOX

      • other users: user

      • shared: “” (empty string)

    Note

    altnamespace mode is valid only for the user namespace: it doesn’t affect the administrator’s view.

    Consider a user “uhura”. Uhura can see all the folders from user “spock”, some folders from users “kirk”, as well as the shared folder “commandcrew”.

    Under altnamespace:off mode with a . separator, she sees her folders as:

    • INBOX

    • INBOX.folder-1

    • INBOX.folder-2 (etc)

    • user.spock (this is INBOX for “spock”)

    • user.spock.folder-x

    • user.kirk.folder-y (“kirk” hasn’t shared their INBOX)

    • commandcrew

    Under altnamespace:on mode with a / separator, she sees her folders as:

    • INBOX (INBOX is special in IMAP and is always the users Inbox)

    • folder-1

    • folder-2 (etc)

    • Other Users/spock

    • Other Users/spock/folder-x

    • Other Users/kirk/folder-y

    • Shared Folders/commandcrew

    Warning

    When using a . separator (unixhierarchysep: off), user names and folder names internally swap the . with ^. This is because dots mark a subfolder if you’re not using unixhierarchy separators. Some IMAP clients do not cope well with the ^ character, which is why unixhierarchysep: on is now the default as it allows dots in usernames and folder names.

    More info at User Namespace Mode.

  3. Administrator namespace

    While a user has their three kinds of mailboxes they have access to, an administrator can see all mailboxes (optionally restricted to the administrator’s own domain). As a result, the response to LIST commands is different for administrators.

    In the administrator namespace, all user mailboxes are presented as user/<username>/<folder> (with unixhierarchysep: on) and with @<domain> appended in virtual domain mode. Shared folders appear at the top level. The user namespace mode (altnamespace on/off) does NOT affect administrator mode; only the hierarchy separator affects display.

    For unixhierarchy separators:

    More info at Administrator Namespaces.

  4. Internal namespace

    Developer reference only. This is how each mailbox is uniquely stored inside mailboxes.db. Each mailbox name has a unique representation that is the “key” in the mailboxes.db key-value database.

    • commandcrew (??)

    • example.com!user.uhura

    • example.com!user.uhura.folder-1

    • example.com!user.spock

    • example.com!user.spock.folder-x

    • example.com!user.kirk

    • example.com|user.mc^coy

    More info at Namespaces: a developer view.

User Access Namespaces

Personal Namespace

The personal namespace refers to the hierarchy of mailboxes that a Cyrus IMAP user owns, such as user Nyota Uhura <nyota.uhura@example.com> being the owner of the user/nyota.uhura@example.com hierarchy.

Mailboxes in the personal namespace start with the literal string user.

Uhura will typically view her personal namespace such that sub-folders of her INBOX may not have a distinguished prefix – other than perhaps INBOX if altnamespace is disabled:

INBOX
Drafts
Sent Items
Spam
Trash

Other Users Namespace

The Other Users namespace is a namespace that is reserved for mailboxes in other user’s personal namespaces, that have been shared with the current user.

With Spock and Kirk in the same environment, who are also sharing their personal mailboxes with Uhura, the Other Users Namespace namespace kicks in when these mailboxes are viewed.

For Nyota Uhura <nyota.uhura@example.org>, with James Kirk <james.kirk@example.org> sharing a selection of his mailboxes, Uhura’s mailbox list looks like:

INBOX
Drafts
Sent Items
Spam
Trash
Other Users/james.kirk
Other Users/james.kirk/Subfolder

Note that the prefix used here is “Other Users” to show the mailbox in question is part of another user’s personal namespace.

The other users namespace can be suppressed in LIST commands by setting disable_user_namespace to 1 in imapd.conf(5). This is useful in larger environments because of the nature of the Discretionary Access Control Cyrus IMAP entertains by default.

Shared Namespaces

Shared namespaces contain mailboxes that are not owned by any one user, though one or more actual users have administrative rights on the folders.

More than one shared namespaces can be created (aside from those named user as this hierarchy is reserved for the Personal Namespace of each user).

Examples of shared folders could include:

Shared mail folders for mailing list traffic

  • lists/cyrus.imap/announce@example.org

  • lists/cyrus.imap/devel@example.org

Shared mail folders for common email addresses

  • shared/contact@example.org

  • shared/hostmaster@example.org

  • shared/info@example.org

  • shared/postmaster@example.org

  • shared/root@example.org

  • shared/webmaster@example.org

The shared namespace can be suppressed in LIST commands by setting disable_shared_namespace to 1 in imapd.conf(5). This is useful in larger environments that want to avoid all LIST operations which can result in large, long lists of folders.

User Namespace Mode

altnamespace: on or off

Note

If you are upgrading an existing server which uses timsieved(8) to manage Sieve scripts and choose to swap namespace modes, you should run the script translatesieve(8) after configuring the namespace option(s). This script will translate the folder names in fileinto actions.

By default Cyrus IMAP uses altnamespace: on , and unixhierarchysep: on “/” (slash) character for the hierarchy separator.

The following limits also apply:

  • Mailbox names are case-sensitive,

  • A mailbox name may not start with a . (dot) character,

  • A mailbox name may not contain two . (dot) characters in a row,

  • Non-ASCII characters and shell meta-characters are not permitted in mailbox names.

While these limits apply under all circumstances, use of the unix hierarchy separator can also affect the display.

When using the altnamespace:off namespace mode, a user’s shorthand qualifier (e.g. john for john@example.org) MAY NOT contain a . (dot) character, as the character is being used as a hierarchy separator in mailbox names, and would thus create a personal mailbox rather then a user’s INBOX. Using john.doe for the INBOX name for user John Doe <john.doe@example.org> does not work, as it would create a sub-folder doe for the INBOX user.john.

The same limitation goes for the use of virtual domains. Since a mailbox in a virtual domain typically uses a fully qualified user identifier (e.g. john@example.org, thus including a valid (sub-)domain name), the . (dot) character is inherited from the Domain Name System naming convention. This poses a problem without the use of the . (dot) character as a mailbox hierarchy separator.

Example

In a default situation using the altnamespace:on namespace mode, a user John Doe <john@example.org> would start out with a mailbox INBOX, and will want to create sub-folders such as for drafted and sent messages.

These mailboxes will be presented to John’s client as follows (assuming dot separator):

  • INBOX

  • Drafts

  • Sent Items

Where altnamespace is set to off, this looks like:

  • INBOX

  • INBOX.Drafts

  • INBOX.Sent Items

Warning

Changing altnamespace in an active operating environment will cause all IMAP clients to need to resync the entire hierarchy.

Administrator Namespaces

An administrator – a user for which the username is included in the admins setting in imapd.conf(5) – has a different perspective when using the IMAP protocol to perform administrative tasks.

Note

The administrator namespace is not affected by the user namespace mode (altnamespace: on/off)

With the UNIX hierarchy separator enabled, the list would look as follows:

  • user/jane

  • user/jane/Drafts

  • user/jane/Sent Items

  • user/john

  • user/john/Drafts

  • user/john/Sent Items

Continuing with the UNIX hierarchy separator enabled, should virtual domains be in use, the list may appear to the administrator user cyrus as follows:

  • user/jane@example.org

  • user/jane/Drafts@example.org

  • user/jane/Sent Items@example.org

  • user/john@example.org

  • user/john/Drafts@example.org

  • user/john/Sent Items@example.org

But the admins setting in imapd.conf(5) allows for a username of admin@example.org to be specified as an administrator as well. Should admin@example.org take a peek, then the following list would appear:

  • user/jane

  • user/jane/Drafts

  • user/jane/Sent Items

  • user/john

  • user/john/Drafts

  • user/john/Sent Items

Important

In multi-domain or multi-tenant environments, the following mailboxes may exist:

  • user/john

  • user/john@example.com

  • user/john@example.org

Be aware that an unrealmed cyrus administrator user can administrator mailboxes in each of the three realms (null for user/john, example.com for user/john@example.com and example.org for user/john@example.org), but a realmed administrator admin@example.org will be able to see and administer mailboxes restricted to the example.org authorization realm. In this case they will see john@example.com being presented as user/john – not to be confused with the actually unrealmed user/john mailbox that exists on the system as well.