The NAMESPACE command is designed to allow clients to automatically create personal mailboxes (e.g., 'Sent Mail', 'Drafts') by discovering the correct namespace prefix, eliminating the need for users to manually configure prefix values when mixing IMAP4 clients and servers.

Two conflicting namespace models existed prior to this document — the 'Personal Mailbox' model (only personal mailboxes in the default namespace) and the 'Complete Hierarchy' model (all accessible mailboxes in the default namespace). The NAMESPACE command was defined to allow clients to automatically discover server namespace structure rather than requiring manual user configuration.

A client can discover accessible personal mailboxes of other users by appending '%' to the Other Users' Namespace prefix in a LIST command; however, a server MAY return NO instead, requiring the client to include a specific username before listing.

Namespace prefixes containing the '#' character are not IMAP URL (RFC 2192) friendly, since '#' must be percent-encoded as %23 in URLs. Server implementers MAY instead use namespace prefixes that do not contain '#'.

A client MUST be prepared for multiple Personal Namespaces and multiple Other Users' Namespaces, even though servers typically support only one of each.

A client SHOULD allow the user to manually enter a namespace prefix, since a server MAY expose only a subset of the namespaces it supports via the NAMESPACE command.

A server SHOULD NOT return user names that have not granted access to their personal mailboxes when responding to a LIST command using the Other Users' Namespace prefix with a '%' wildcard.

security

Any international string in the NAMESPACE response MUST be of modified UTF-7 format as described in RFC-2060.

If an INBOX exists for a user, it MUST appear within the user's personal namespace.

IMAP4 servers that support the NAMESPACE extension MUST list the keyword NAMESPACE in their CAPABILITY response.

In the typical case, there SHOULD be only one Personal Namespace on a server, and there SHOULD be only one Other Users' Namespace on a server.

Namespace_Response_Extensions that are not on the IETF standards track MUST be prefixed with an 'X-'.

The next level of hierarchy following the Other Users' Namespace prefix SHOULD consist of <username>, where <username> is a user name as per the IMAP4 LOGIN or AUTHENTICATE command.

To access mailboxes in the Other Users' Namespace, the currently authenticated user MUST be explicitly granted access rights.

When a client must create a mailbox and it is unclear which Personal Namespace to use (e.g., when multiple exist), the client SHOULD let the user select which namespace to create the mailbox in.

The NAMESPACE command takes no arguments and is valid in the Authenticated and Selected states. It returns an untagged NAMESPACE response containing prefixes and hierarchy delimiters for Personal, Other Users', and Shared namespaces.

Three namespace classes are defined: Personal Namespace (within the authenticated user's personal scope), Other Users' Namespace (mailboxes from other users' personal namespaces requiring explicit access grants), and Shared Namespace (mailboxes shared among users, outside any personal namespace).

A server SHOULD NOT list users in response to a LIST command on the Other Users' Namespace prefix if those users have not granted list access to their mailboxes. Doing so could disclose confidential information about who has accounts on the server or provide a starting point for targeted attacks on user accounts.

security, privacy

A Namespace_Response_Extension has the form: SP string SP '(' string *(SP string) ')', allowing key-value extension parameters to be attached to a namespace descriptor. Non-standards-track extensions must use the 'X-' prefix.

The NAMESPACE response has the form: '* NAMESPACE' followed by three Namespace fields (Personal, Other Users', Shared). Each Namespace field is either NIL or a parenthesized list of namespace descriptors, each containing a prefix string and a hierarchy delimiter (quoted char or NIL), optionally followed by Namespace_Response_Extensions.