GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2193

Network Working Group M. Gahrns Request for Comments: 2193 Microsoft Category: Standards Track September 1997

                      IMAP4 Mailbox Referrals

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo 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
 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.

Gahrns Standards Track [Page 1] RFC 2193 IMAP4 Mailbox Referrals September 1997

 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 [RFC-2192].  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
 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.

Gahrns Standards Track [Page 2] RFC 2193 IMAP4 Mailbox Referrals September 1997

 Example:
    A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/REMOTE]Remote Mailbox
 NOTE: user;AUTH=* is specified as required by [RFC-2192] 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 that
 it is able to issue the commands necessary to process the remote
 mailbox.

Gahrns Standards Track [Page 3] RFC 2193 IMAP4 Mailbox Referrals September 1997

 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 Standards Track [Page 4] RFC 2193 IMAP4 Mailbox Referrals September 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 Standards Track [Page 5] RFC 2193 IMAP4 Mailbox Referrals September 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 Standards Track [Page 6] RFC 2193 IMAP4 Mailbox Referrals September 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 Standards Track [Page 7] RFC 2193 IMAP4 Mailbox Referrals September 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 [RFC-2192].
 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.
 [RFC-2192], Newman, C., "IMAP URL Scheme", RFC 2192, Innosoft,
 September 1997.
 [RFC-1738], Berners-Lee, T., Masinter, L., and M. 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", 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 Standards Track [Page 8] RFC 2193 IMAP4 Mailbox Referrals September 1997

9. Author's Address

 Mike Gahrns
 Microsoft
 One Microsoft Way
 Redmond, WA, 98072
 Phone: (206) 936-9833
 EMail: mikega@microsoft.com

Gahrns Standards Track [Page 9]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2193.txt · Last modified: 1997/09/10 23:33 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki