Source from upstream; imap-2007f.tar.gz
MD5 2126fd125ea26b73b20f01fcd5940369
This commit is contained in:
Chris
507
docs/rfc/rfc2193.txt
Normal file
507
docs/rfc/rfc2193.txt
Normal file
@@ -0,0 +1,507 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
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]
|
||||
|
||||
Reference in New Issue
Block a user