IMAP4 Mailbox Referrals
Extracted elements (23)
Hierarchy referrals — where a client would need to connect to the remote server and issue LIST to discover inferiors of a mailbox — are explicitly not addressed by this document.
Remote mailboxes are excluded from LIST/LSUB responses on the home server to avoid displaying inaccessible mailboxes to non-MAILBOX-REFERRALS-enabled clients, while RLIST/RLSUB expose them to capable clients.
The referral mechanism is preferred over the proxy method because it allows a direct client connection to the remote server, which is often more bandwidth-efficient and does not require the local server to impersonate the client when authenticating to the remote server.
A MAILBOX-REFERRALS capable client issues RLIST and RLSUB in lieu of LIST and LSUB, so that remote mailboxes are visible. Non-capable clients will not see inaccessible remote mailboxes because they only issue LIST/LSUB.
The IMAP URL for referrals MUST use user;AUTH=* (as required by RFC-2192) to avoid the client falling back to anonymous login on the remote server.
When multiple referrals are given for a mailbox, a server should be aware of synchronization issues for a client if the UIDVALIDITY of the referred mailboxes differ.
A client that supports the REFERRALS extension MUST be prepared for a URL of any type, but it need only be able to process IMAP URLs.
A MAILBOX-REFERRALS capable IMAP4 server MUST NOT return referrals that result in a referrals loop.
If a RENAME referral pair references mailboxes on different servers, the remote servers cannot perform the RENAME. The client MAY achieve equivalent behavior by issuing constituent CREATE, FETCH, APPEND, and DELETE commands against both servers.
If a server replies with multiple URLs for a particular object, they MUST all be of the same type, and in this case the URL MUST be an IMAP URL as defined in RFC-2192.
If the server has a preferred order for the client to attempt URLs, the preferred URL SHOULD be listed first, with remaining URLs in descending order of preference.
IMAP4 servers that support this extension MUST list the keyword MAILBOX-REFERRALS in their CAPABILITY response. No client action is needed to invoke the capability.
Remote mailboxes accessible only via referrals SHOULD NOT appear in LIST and LSUB responses from the user's home server, but MUST appear in RLIST and RLSUB responses.
A referral response consists of a tagged NO response and a REFERRAL response code. The REFERRAL response code contains one or more valid URLs separated by spaces as defined in RFC-1738.
A server MAY respond with multiple IMAP mailbox referrals if there is more than one replica of the mailbox, enabling load balancing or failover. Synchronization of replicas is not addressed by this document.
An IMAP4 server MAY respond to SELECT, EXAMINE, DELETE, SUBSCRIBE, UNSUBSCRIBE, STATUS, or APPEND with one or more IMAP mailbox referrals to indicate the mailbox is hosted on a remote server.
An IMAP4 server MAY respond to the COPY command with one or more IMAP mailbox referrals indicating the destination mailbox is on a remote server. The client MAY simulate COPY by issuing constituent FETCH and APPEND commands against both servers.
An IMAP4 server MAY respond to the CREATE command with one or more IMAP mailbox referrals to direct the client to issue the CREATE against another server, using the mailbox hierarchy to determine the target server.
An IMAP4 server MAY respond to the RENAME command with one or more pairs of IMAP mailbox referrals: the first URL is the existing mailbox name and the second is the requested new mailbox name.
The RLIST command takes a reference name and mailbox name with possible wildcards, and behaves identically to LIST except remote mailboxes are returned in addition to local mailboxes in the LIST responses.
The RLSUB command takes a reference name and mailbox name with possible wildcards, and behaves identically to LSUB except remote mailboxes are returned in addition to local mailboxes in the LSUB responses.
The IMAP4 referral mechanism inherits the security considerations of general internet URLs (RFC-1738) and IMAP URLs (RFC-2192). The MAILBOX-REFERRALS capability potentially makes it easier to write a rogue server that injects bogus referral responses directing users to incorrect mailboxes, though the referral response also makes detection of such intrusion easier.
The referral_response_code is encoded as "[" "REFERRAL" followed by one or more space-separated URLs "]". The enclosing mailbox_referral is a tagged NO response followed by the referral_response_code and optional text.