[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 RFC 2193

Network Working Group                                        M. Gahrns
Internet Draft                                               Microsoft
Document: draft-gahrns-imap-mailbox-referrals-00.txt          May 1997


                          IMAP4 Mailbox Referrals


Status of this Memo

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   "working draft" or "work in progress".

   To learn the current status of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
   munnari.oz.au.

   A revised version of this draft document will be submitted to the
   RFC editor as a Proposed Standard for the Internet Community.
   Discussion and suggestions for improvement are requested.  This
   document will expire before November 1997. Distribution of this
   draft is unlimited.


1. Abstract

   When dealing with large amounts of users, messages and
   geographically dispersed IMAP4 [RFC-2060] servers, it is often
   desirable to distribute messages amongst different servers within an
   organization.  For example an administrator may choose to store
   user's personal mailboxes on a local IMAP4 server, while storing
   shared mailboxes remotely on another server.  This type of
   configuration is common when it is uneconomical to store all data
   centrally due to limited bandwidth or disk resources.

   Mailbox referrals allow clients to seamlessly access mailboxes that
   are distributed across several IMAP4 servers.

   A referral mechanism can provide efficiencies over the alternative
   "proxy method", in which the local IMAP4 server contacts the remote
   server on behalf of the client, and then transfers the data from the
   remote server to itself, and then on to the client.  The referral
   mechanism's direct client connection to the remote server is often a
   more efficient use of bandwidth, and does not require the local


Gahrns                                                               1
                       IMAP4 Mailbox Referrals               May 1997


   server to impersonate the client when authenticating to the remote
   server.


2. Conventions used in this document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

   A home server, is an IMAP4 server that contains the user's inbox.

   A remote mailbox is a mailbox that is not hosted on the user's home
   server.

   A remote server is a server that contains remote mailboxes.

   A shared mailbox, is a mailbox that multiple users have access to.

   An IMAP mailbox referral is when the server directs the client to
   another IMAP mailbox.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in [RFC-2119].


3. Introduction and Overview

   IMAP4 servers that support this extension MUST list the keyword
   MAILBOX-REFERRALS in their CAPABILITY response.  No client action is
   needed to invoke the MAILBOX-REFERRALS capability in a server.

   A MAILBOX-REFERRALS capable IMAP4 server MUST NOT return referrals
   that result in a referrals loop.

   A referral response consists of a tagged NO response and a REFERRAL
   response code.  The REFERRAL response code MUST contain as an
   argument a one or more valid URLs separated by a space as defined in
   [RFC-1738]. If a server replies with multiple URLs for a particular
   object, they MUST all be of the same type. In this case, the URL
   MUST be an IMAP URL as defined in [IMAP-URL].  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 server MAY respond with multiple IMAP mailbox referrals if there
   is more than one replica of the mailbox.  This allows the
   implementation of a load balancing or failover scheme. How a server
   keeps multiple replicas of a mailbox in sync is not addressed by
   this document.

   If the server has a preferred order in which the client should
   attempt to access the URLs, the preferred URL SHOULD be listed in
   the first, with the remaining URLs presented in descending order of

Gahrns                                                               2
                       IMAP4 Mailbox Referrals               May 1997


   preference.  If multiple referrals are given for a mailbox, a server
   should be aware that there are synchronization issues for a client
   if the UIDVALIDITY of the referred mailboxes are different.

   An IMAP mailbox referral may be given in response to an IMAP command
   that specifies a mailbox as an argument.

   Example:

     A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/REMOTE]Remote Mailbox

   NOTE: user;AUTH=* is specified as required by [IMAP-URL] to avoid a
   client falling back to anonymous login.

   Remote mailboxes and their inferiors, that are accessible only via
   referrals SHOULD NOT appear in LIST and LSUB responses issued
   against the user's home server.  They MUST appear in RLIST and RLSUB
   responses issued against the user's home server. Hierarchy
   referrals, in which a client would be required to connect to the
   remote server to issue a LIST to discover the inferiors of a mailbox
   are not addressed in this document.

   For example, if shared mailboxes were only accessible via referrals
   on a remote server, a RLIST "" "#SHARED/%" command would return the
   same response if issued against the user's home server or the remote
   server.

   Note: Mailboxes that are available on the user's home server do not
   need to be available on the remote server.  In addition, there may
   be additional mailboxes available on the remote server, but they
   will not accessible to the client via referrals unless they appear
   in the LIST response to the RLIST command against the user's home
   server.

   A MAILBOX-REFERRALS capable client will issue the RLIST and RLSUB
   commands in lieu of LIST and LSUB.  The RLIST and RLSUB commands
   behave identically to their LIST and LSUB counterparts, except
   remote mailboxes are returned in addition to local mailboxes in the
   LIST and LSUB responses.  This avoids displaying to a non MAILBOX-
   REFERRALS enabled client inaccessible remote mailboxes.


4.1. SELECT, EXAMINE, DELETE, SUBSCRIBE, UNSUBSCRIBE, STATUS and APPEND
     Referrals

   An IMAP4 server MAY respond to the SELECT, EXAMINE, DELETE,
   SUBSCRIBE, UNSUBSCRIBE, STATUS or APPEND command with one or more
   IMAP mailbox referrals to indicate to the client that the mailbox is
   hosted on a remote server.

   When a client processes an IMAP mailbox referral, it will open a new
   connection or use an existing connection to the remote server so


Gahrns                                                               3
                       IMAP4 Mailbox Referrals               May 1997


   that it is able to issue the commands necessary to process the
   remote mailbox.

   Example:  <IMAP4 connection to home server>

      C: A001 DELETE "SHARED/FOO"
      S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO]
              Remote mailbox. Try SERVER2.

      <Client established a second connection to SERVER2 and
       issues the DELETE command on the referred mailbox>

      S: * OK IMAP4rev1 server ready
      C: B001 AUTHENTICATE KERBEROS_V4
      <authentication exchange>
      S: B001 OK user is authenticated

      C: B002 DELETE "SHARED/FOO"
      S: B002 OK DELETE completed


   Example:  <IMAP4 connection to home server>

      C: A001 SELECT REMOTE
      S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/REMOTE
          IMAP://user;AUTH=*@SERVER3/REMOTE] Remote mailbox.
          Try SERVER2 or SERVER3.

      <Client opens second connection to remote server, and
       issues the commands needed to process the items in the
       remote mailbox>

      S: * OK IMAP4rev1 server ready
      C: B001 AUTHENTICATE KERBEROS_V4
      <authentication exchange>
      S: B001 OK user is authenticated

      C: B002 SELECT REMOTE
      S: * 12 EXISTS
      S: * 1 RECENT
      S: * OK [UNSEEN 10] Message 10 is first unseen
      S: * OK [UIDVALIDITY 123456789]
      S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
      S: * OK [PERMANENTFLAGS (\Answered \Deleted \Seen \*)]
      S: B002 OK [READ-WRITE] Selected completed

      C: B003 FETCH 10:12 RFC822
      S: * 10 FETCH . . .
      S: * 11 FETCH . . .
      S: * 12 FETCH . . .
      S: B003 OK FETCH Completed



Gahrns                                                               4
                       IMAP4 Mailbox Referrals               May 1997


      <Client is finished processing the REMOTE mailbox and
       wants to process a mailbox on its home server>

      C: B004 LOGOUT
      S: * BYE IMAP4rev1 server logging out
      S: B004 OK LOGOUT Completed

      <Client continues with first connection>

      C: A002 SELECT INBOX
      S: * 16 EXISTS
      S: * 2 RECENT
      S: * OK [UNSEEN 10] Message 10 is first unseen
      S: * OK [UIDVALIDITY 123456789]
      S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
      S: * OK [PERMANENTFLAGS (\Answered \Deleted \Seen \*)]
      S: A002 OK [READ-WRITE] Selected completed


4.2. CREATE Referrals

   An IMAP4 server MAY respond to the CREATE command with one or more
   IMAP mailbox referrals, if it wishes to direct the client to issue
   the CREATE against another server.  The server can employ any means,
   such as examining the hierarchy of the specified mailbox name, in
   determining which server the mailbox should be created on.

   Example:

      C: A001 CREATE "SHARED/FOO"
      S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO]
          Mailbox should be created on remote server


   Alternatively, because a home server is required to maintain a
   listing of referred remote mailboxes, a server MAY allow the
   creation of a mailbox that will ultimately reside on a remote server
   against the home server, and provide referrals on subsequent
   commands that manipulate the mailbox.

   Example:

      C: A001 CREATE "SHARED/FOO"
      S: A001 OK CREATE succeeded

      C: A002 SELECT "SHARED/FOO"
      S: A002 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO]
          Remote mailbox.  Try SERVER2






Gahrns                                                               5
                       IMAP4 Mailbox Referrals               May 1997


4.3. RENAME Referrals

   An IMAP4 server MAY respond to the RENAME command with one or more
   pairs of IMAP mailbox referrals.  In each pair of IMAP mailbox
   referrals, the first one is an URL to the existing mailbox name and
   the second is an URL to the requested new mailbox name.

   If within an IMAP mailbox referral pair, the existing and new
   mailbox URLs are on different servers, the remote servers are unable
   to perform the RENAME operation.   To achieve the same behavior of
   server RENAME, the client MAY issue the constituent CREATE, FETCH,
   APPEND, and DELETE commands against both servers.

   If within an IMAP mailbox referral pair, the existing and new
   mailbox URLs are on the same server it is an indication that the
   currently connected server is unable to perform the operation.  The
   client can simply re-issue the RENAME command on the remote server.

   Example:

      C: A001 RENAME FOO BAR
      S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER1/FOO
               IMAP://user;AUTH=*@SERVER2/BAR] Unable to rename mailbox
               across servers


   Since the existing and new mailbox names are on different servers,
   the client would be required to make a connection to both servers
   and issue the constituent commands require to achieve the RENAME.


   Example:

      C: A001 RENAME FOO BAR
      S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/FOO
               IMAP://user;AUTH=*@SERVER2/BAR] Unable to rename mailbox
               located on SERVER2


   Since both the existing and new mailbox are on the same remote
   server, the client can simply make a connection to the remote server
   and re-issue the RENAME command.


4.4. COPY Referrals

   An IMAP4 server MAY respond to the COPY command with one or more
   IMAP mailbox referrals.  This indicates that the destination mailbox
   is on a remote server.  To achieve the same behavior of a server
   COPY, the client MAY issue the constituent FETCH and APPEND commands
   against both servers.



Gahrns                                                               6
                       IMAP4 Mailbox Referrals               May 1997


   Example:


      C: A001 COPY 1 "SHARED/STUFF"
      S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/STUFF]
                Unable to copy message(s) to SERVER2.


5.1 RLIST command

   Arguments:  reference name
               mailbox name with possible wildcards

   Responses:  untagged responses: LIST

   Result:     OK - RLIST Completed
               NO - RLIST Failure
               BAD - command unknown or arguments invalid

   The RLIST command behaves identically to its LIST counterpart,
   except remote mailboxes are returned in addition to local mailboxes
   in the LIST responses.


5.2 RLSUB Command

   Arguments:  reference name
               mailbox name with possible wildcards

   Responses:  untagged responses: LSUB

   Result:     OK - RLSUB Completed
               NO - RLSUB Failure
               BAD - command unknown or arguments invalid

   The RLSUB command behaves identically to its LSUB counterpart,
   except remote mailboxes are returned in addition to local mailboxes
   in the LSUB responses.


6. Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in [ABNF].


   list_mailbox = <list_mailbox> as defined in [RFC-2060]

   mailbox = <mailbox> as defined in [RFC-2060]

   mailbox_referral = <tag> SPACE "NO" SPACE
      <referral_response_code> (text / text_mime2)
      ; See [RFC-2060] for <tag>, text and text_mime2 definition

Gahrns                                                               7
                       IMAP4 Mailbox Referrals               May 1997



   referral_response_code = "[" "REFERRAL" 1*(SPACE <url>) "]"
      ; See [RFC-1738] for <url> definition

   rlist = "RLIST" SPACE mailbox SPACE list_mailbox

   rlsub = "RLSUB" SPACE mailbox SPACE list_mailbox


6. Security Considerations

   The IMAP4 referral mechanism makes use of IMAP URLs, and as such,
   have the same security considerations as general internet URLs [RFC-
   1738], and in particular IMAP URLs [IMAP-URL].

   With the MAILBOX-REFERRALS capability, it is potentially easier to
   write a rogue server that injects a bogus referral response that
   directs a user to an incorrect mailbox.  Although referrals reduce
   the effort to write such a server, the referral response makes
   detection of the intrusion easier.


7. References

   [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version
   4rev1", RFC 2060, University of Washington, December 1996.

   [IMAP-URL], Newman, C., "IMAP URL Scheme", draft-newman-url-imap-
   08.txt (work in progress), Innosoft, March 1997

   [RFC-1738], Berners-Lee, Masinter, McCahill, "Uniform Resource
   Locators  (URL)", RFC 1738, CERN, Xerox Corporation, University of
   Minnesota, December 1994

   [RFC-2119], Bradner, S, "Key words for use in RFCs to Indicate
   Requirement Levels", RFC 2119, Harvard University, March 1997

   [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for
   Syntax Specifications: ABNF", draft-drums-abnf-02.txt (work in
   progress), Internet Mail Consortium, April 1997


8.  Acknowledgments

   Many valuable suggestions were received from private discussions and
   the IMAP4 mailing list.  In particular, Raymond Cheng, Mark Crispin,
   Mark Keasling Chris Newman and Larry Osterman made significant
   contributions to this document.






Gahrns                                                               8
                       IMAP4 Mailbox Referrals               May 1997


9. Author's Address

   Mike Gahrns
   Microsoft
   One Microsoft Way
   Redmond, WA, 98072

   Phone: (206) 936-9833
   Email: mikega@microsoft.com













































Gahrns                                                               9


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/