Internet DRAFT - draft-gahrns-imap-referrals
draft-gahrns-imap-referrals
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 00:01:33 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Tue, 17 Mar 1998 16:34:00 GMT
ETag: "2e99d8-4aec-350ea5f8"
Accept-Ranges: bytes
Content-Length: 19180
Connection: close
Content-Type: text/plain
Network Working Group M. Gahrns
Internet Draft Microsoft
Document: draft-gahrns-imap-referrals-02.txt April 1997
IMAP4 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 October 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. Additionally,
users may be frequently moved from one IMAP4 server to another
because of hardware failures or organizational changes.
Referrals allow clients to seamlessly access mailboxes that are
distributed across several IMAP4 servers or to transparently connect
to an alternate IMAP4 server.
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
Gahrns 1
IMAP4 Referrals April 1997
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.
A remote server is a server that contains remote mailboxes.
A shared mailbox, is a mailbox that multiple users have access to.
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
REFERRALS in their CAPABILITY response. No client action is needed
to invoke the REFERRALS capability in a server.
A REFERRALS capable IMAP4 server SHOULD NOT return referrals that
result in a referrals loop.
A referral response consists of an untagged NO response and a
REFERRAL response code. The REFERRAL response code MUST contain as
an argument a valid URL as defined in [RFC1738]. If a server replies
with multiple URLs for a particular object, they MUST all be of the
same type. When referring to another IMAP server or mailbox, 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 to process IMAP URLs.
A home server referral consists of a referral response that contains
as an argument an IMAP URL minimally specifying the home server
name. A home server referral may be given in response to a LOGIN or
AUTHENTICATE command.
Example: * NO [REFERRAL IMAP://SERVER2] Remote Server
Gahrns 2
IMAP4 Referrals April 1997
An IMAP mailbox referral consists of a referral response that
contains as an argument an IMAP URL minimally specifying the remote
server and mailbox. 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 untagged response, 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.
Example: * NO [REFERRAL IMAP://SERVER2/REMOTE] Remote Mailbox
* NO [REFERRAL IMAP://SERVER3/REMOTE] Remote Mailbox
Remote mailboxes that are accessible via referrals SHOULD appear in
LIST and LSUB responses issued against the user's home server. For
example, if shared mailboxes were only accessible via referrals on a
remote server, a LIST “” "#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 on 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.
4. Home Server Referrals
A home server referral may be returned in response to an
AUTHENTICATE or LOGIN command, or a derivative of it may appear in
the connection startup banner. If a server returns a home server
referral, that server does not contain any mailboxes that are
accessible to the user.
4.1. LOGIN and AUTHENTICATE Referrals
An IMAP4 server MAY respond to a LOGIN or AUTHENTICATE command with
a home server referral if it wishes to direct the user to another
IMAP4 server.
Gahrns 3
IMAP4 Referrals April 1997
Example: C: A001 LOGIN MIKE PASSWORD
S: * NO [REFERRAL IMAP://SERVER2/] Remote Server
S: A001 NO Specified user is invalid on this server.
Try SERVER2
Example: C: A001 AUTHENTICATE KERBEROS_V4
S: + AweFG-0
C: BFsDdfJLEfdLeLLEFF9KLWsdfelf/Sdfef4sdwe
S: + wsEd/aSSWf
C: HiWdf3fg45fw:Lge
S: * NO [REFERRAL IMAP://SERVER2/] Remote Server
S: A001 NO Specified user is invalid on this server.
Try SERVER2
4.2. BYE at connection startup referral
An IMAP4 server MAY respond with an untagged BYE and a REFERRAL
response code that contains an IMAP URL to a home server if it is
not willing to accept connections and wishes to direct the client to
another IMAP4 server.
Example: S: * BYE [REFERRAL IMAP://SERVER2/] Server not accepting
connections. Try SERVER2
5. IMAP Mailbox Referrals
One or more IMAP mailbox referrals MAY be returned in response to a
SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE,
STATUS, APPEND or COPY command.
5.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.
Example: <IMAP4 connection to home server>
C: A001 DELETE "SHARED/FOO"
S: * NO [REFERRAL IMAP://SERVER2/SHARED/FOO] Remote
Mailbox
S: A001 NO Remote mailbox. Try SERVER2
Gahrns 4
IMAP4 Referrals April 1997
<Client established a second connection to SERVER2 and
issues the DELETE command on the referred mailbox>
S: * OK IMAP4rev1 server ready
C: B001 LOGIN USER PASSWORD
S: B001 OK LOGIN completed
C: B002 DELETE "SHARED/FOO"
S: B002 OK DELETE completed.
Example: <IMAP4 connection to home server>
C: A001 SELECT REMOTE
S: * NO [REFERRAL IMAP://SERVER2/REMOTE] Remote mailbox
S: * NO [REFERRAL IMAP://SERVER3/REMOTE] Remote mailbox
S: A001 NO 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 LOGIN USER PASSWORD
S: B001 OK LOGIN completed
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
<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
Gahrns 5
IMAP4 Referrals April 1997
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
5.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: * NO [REFERRAL IMAP://SERVER2/SHARED/FOO] Remote
mailbox
S: A001 NO 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: * NO [REFERRAL IMAP://SERVER2/SHARED/FOO] Remote
Mailbox
S: A002 NO Remote mailbox. Try SERVER2
5.4. 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
Gahrns 6
IMAP4 Referrals April 1997
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: * NO [REFERRAL IMAP://SERVER1/FOO] Remote mailbox
S: * NO [REFERRAL IMAP://SERVER2/BAR] Remote mailbox
S: A001 NO 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: * NO [REFERRAL IMAP://SERVER2/FOO] Remote mailbox
S: * NO [REFERRAL IMAP://SERVER2/BAR] Remote mailbox
S: A001 NO 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.
5.5. 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.
Example:
C: A001 COPY 1 "SHARED/PROJECT"
S: * NO [REFERRAL IMAP://SERVER2/SHARED/PROJECT] Remote
mailbox
S: A001 NO Unable to copy message(s) to SERVER2.
6. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in [ABNF].
connection_referral = "*" SPACE "BYE" SPACE
Gahrns 7
IMAP4 Referrals April 1997
<referral_response_code> (text / text_mime2)
home_server_or_mailbox_referral = "*" SPACE "NO" SPACE
<referral_response_code> (text / text_mime2)
referral_response_code = "[" "REFERRAL" SPACE <url> "]"
text = 1*text_char
text_char = <any CHAR except CR and LF>
text_mime2 = "=?" <charset> "?" <encoding> "?" <encoded-text> "?="
; <charset>, <encoding>, <encoded-text> syntax as
; defined in [RFC-2047]
url = <any url as defined in [rfc-1738]>
7. 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].
In the general case, only the remote server information is passed
back to the client in the IMAP URL. No referral scenarios are
envisioned that would require user and password information to be
passed back in the IMAP URL. Should they arise, including passwords
in the URL is discouraged unless this can be accomplished in a
secure manner.
In addition, the IMAP URL scheme allows a client authentication
mechanism to be specified and should be used when a server supports
a preferred authentication mechanism.
With the REFERRALS capability, it is potentially easier to write a
rogue 'password catching' server that collects login data and then
refers the client to their actual IMAP4 server. Also made easier,
is the ability for a rogue server to inject 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.
8. 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-
06.txt (work in progress), Innosoft, March 1997
Gahrns 8
IMAP4 Referrals April 1997
[RFC-1738], Berners-Lee, Masinter, McCahill, "Uniform Resource
Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of
Minnesota, December 1994
[RFC-2047], Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extension for Non-ASCII Text", RFC 2047,
November 1996.
[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
9. 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.
10. Author's Address
Mike Gahrns
Microsoft
One Microsoft Way
Redmond, WA, 98072
Phone: (206) 936-9833
Email: mikega@microsoft.co
m
Gahrns 9
