idnits 2.17.1 draft-gahrns-imap-mailbox-referral-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == Mismatching filename: the document gives the document name as 'draft-gahrns-imap-mailbox-referrals-00', but the file name used is 'draft-gahrns-imap-mailbox-referral-00' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC-2060]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (May 1997) is 9840 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'UNSEEN 10' is mentioned on line 223, but not defined == Missing Reference: 'UIDVALIDITY 123456789' is mentioned on line 224, but not defined ** Obsolete normative reference: RFC 2060 (Obsoleted by RFC 3501) == Outdated reference: A later version (-09) exists of draft-newman-url-imap-08 ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) -- No information found for draft-drums-abnf - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ABNF' Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Gahrns 2 Internet Draft Microsoft 3 Document: draft-gahrns-imap-mailbox-referrals-00.txt May 1997 5 IMAP4 Mailbox Referrals 7 Status of this Memo 9 This document is an Internet Draft. Internet Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its Areas, 11 and its Working Groups. Note that other groups may also distribute 12 working documents as Internet Drafts. 14 Internet Drafts are draft documents valid for a maximum of six 15 months. Internet Drafts may be updated, replaced, or obsoleted by 16 other documents at any time. It is not appropriate to use Internet 17 Drafts as reference material or to cite them other than as a 18 "working draft" or "work in progress". 20 To learn the current status of any Internet-Draft, please check the 21 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 22 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 23 munnari.oz.au. 25 A revised version of this draft document will be submitted to the 26 RFC editor as a Proposed Standard for the Internet Community. 27 Discussion and suggestions for improvement are requested. This 28 document will expire before November 1997. Distribution of this 29 draft is unlimited. 31 1. Abstract 33 When dealing with large amounts of users, messages and 34 geographically dispersed IMAP4 [RFC-2060] servers, it is often 35 desirable to distribute messages amongst different servers within an 36 organization. For example an administrator may choose to store 37 user's personal mailboxes on a local IMAP4 server, while storing 38 shared mailboxes remotely on another server. This type of 39 configuration is common when it is uneconomical to store all data 40 centrally due to limited bandwidth or disk resources. 42 Mailbox referrals allow clients to seamlessly access mailboxes that 43 are distributed across several IMAP4 servers. 45 A referral mechanism can provide efficiencies over the alternative 46 "proxy method", in which the local IMAP4 server contacts the remote 47 server on behalf of the client, and then transfers the data from the 48 remote server to itself, and then on to the client. The referral 49 mechanism's direct client connection to the remote server is often a 50 more efficient use of bandwidth, and does not require the local 52 Gahrns 1 53 server to impersonate the client when authenticating to the remote 54 server. 56 2. Conventions used in this document 58 In examples, "C:" and "S:" indicate lines sent by the client and 59 server respectively. 61 A home server, is an IMAP4 server that contains the user's inbox. 63 A remote mailbox is a mailbox that is not hosted on the user's home 64 server. 66 A remote server is a server that contains remote mailboxes. 68 A shared mailbox, is a mailbox that multiple users have access to. 70 An IMAP mailbox referral is when the server directs the client to 71 another IMAP mailbox. 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 75 this document are to be interpreted as described in [RFC-2119]. 77 3. Introduction and Overview 79 IMAP4 servers that support this extension MUST list the keyword 80 MAILBOX-REFERRALS in their CAPABILITY response. No client action is 81 needed to invoke the MAILBOX-REFERRALS capability in a server. 83 A MAILBOX-REFERRALS capable IMAP4 server MUST NOT return referrals 84 that result in a referrals loop. 86 A referral response consists of a tagged NO response and a REFERRAL 87 response code. The REFERRAL response code MUST contain as an 88 argument a one or more valid URLs separated by a space as defined in 89 [RFC-1738]. If a server replies with multiple URLs for a particular 90 object, they MUST all be of the same type. In this case, the URL 91 MUST be an IMAP URL as defined in [IMAP-URL]. A client that 92 supports the REFERRALS extension MUST be prepared for a URL of any 93 type, but it need only be able to process IMAP URLs. 95 A server MAY respond with multiple IMAP mailbox referrals if there 96 is more than one replica of the mailbox. This allows the 97 implementation of a load balancing or failover scheme. How a server 98 keeps multiple replicas of a mailbox in sync is not addressed by 99 this document. 101 If the server has a preferred order in which the client should 102 attempt to access the URLs, the preferred URL SHOULD be listed in 103 the first, with the remaining URLs presented in descending order of 105 Gahrns 2 106 preference. If multiple referrals are given for a mailbox, a server 107 should be aware that there are synchronization issues for a client 108 if the UIDVALIDITY of the referred mailboxes are different. 110 An IMAP mailbox referral may be given in response to an IMAP command 111 that specifies a mailbox as an argument. 113 Example: 115 A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/REMOTE]Remote Mailbox 117 NOTE: user;AUTH=* is specified as required by [IMAP-URL] to avoid a 118 client falling back to anonymous login. 120 Remote mailboxes and their inferiors, that are accessible only via 121 referrals SHOULD NOT appear in LIST and LSUB responses issued 122 against the user's home server. They MUST appear in RLIST and RLSUB 123 responses issued against the user's home server. Hierarchy 124 referrals, in which a client would be required to connect to the 125 remote server to issue a LIST to discover the inferiors of a mailbox 126 are not addressed in this document. 128 For example, if shared mailboxes were only accessible via referrals 129 on a remote server, a RLIST "" "#SHARED/%" command would return the 130 same response if issued against the user's home server or the remote 131 server. 133 Note: Mailboxes that are available on the user's home server do not 134 need to be available on the remote server. In addition, there may 135 be additional mailboxes available on the remote server, but they 136 will not accessible to the client via referrals unless they appear 137 in the LIST response to the RLIST command against the user's home 138 server. 140 A MAILBOX-REFERRALS capable client will issue the RLIST and RLSUB 141 commands in lieu of LIST and LSUB. The RLIST and RLSUB commands 142 behave identically to their LIST and LSUB counterparts, except 143 remote mailboxes are returned in addition to local mailboxes in the 144 LIST and LSUB responses. This avoids displaying to a non MAILBOX- 145 REFERRALS enabled client inaccessible remote mailboxes. 147 4.1. SELECT, EXAMINE, DELETE, SUBSCRIBE, UNSUBSCRIBE, STATUS and APPEND 148 Referrals 150 An IMAP4 server MAY respond to the SELECT, EXAMINE, DELETE, 151 SUBSCRIBE, UNSUBSCRIBE, STATUS or APPEND command with one or more 152 IMAP mailbox referrals to indicate to the client that the mailbox is 153 hosted on a remote server. 155 When a client processes an IMAP mailbox referral, it will open a new 156 connection or use an existing connection to the remote server so 158 Gahrns 3 159 that it is able to issue the commands necessary to process the 160 remote mailbox. 162 Example: 164 C: A001 DELETE "SHARED/FOO" 165 S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO] 166 Remote mailbox. Try SERVER2. 168 171 S: * OK IMAP4rev1 server ready 172 C: B001 AUTHENTICATE KERBEROS_V4 173 174 S: B001 OK user is authenticated 176 C: B002 DELETE "SHARED/FOO" 177 S: B002 OK DELETE completed 179 Example: 181 C: A001 SELECT REMOTE 182 S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/REMOTE 183 IMAP://user;AUTH=*@SERVER3/REMOTE] Remote mailbox. 184 Try SERVER2 or SERVER3. 186 190 S: * OK IMAP4rev1 server ready 191 C: B001 AUTHENTICATE KERBEROS_V4 192 193 S: B001 OK user is authenticated 195 C: B002 SELECT REMOTE 196 S: * 12 EXISTS 197 S: * 1 RECENT 198 S: * OK [UNSEEN 10] Message 10 is first unseen 199 S: * OK [UIDVALIDITY 123456789] 200 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 201 S: * OK [PERMANENTFLAGS (\Answered \Deleted \Seen \*)] 202 S: B002 OK [READ-WRITE] Selected completed 204 C: B003 FETCH 10:12 RFC822 205 S: * 10 FETCH . . . 206 S: * 11 FETCH . . . 207 S: * 12 FETCH . . . 208 S: B003 OK FETCH Completed 210 Gahrns 4 211 214 C: B004 LOGOUT 215 S: * BYE IMAP4rev1 server logging out 216 S: B004 OK LOGOUT Completed 218 220 C: A002 SELECT INBOX 221 S: * 16 EXISTS 222 S: * 2 RECENT 223 S: * OK [UNSEEN 10] Message 10 is first unseen 224 S: * OK [UIDVALIDITY 123456789] 225 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 226 S: * OK [PERMANENTFLAGS (\Answered \Deleted \Seen \*)] 227 S: A002 OK [READ-WRITE] Selected completed 229 4.2. CREATE Referrals 231 An IMAP4 server MAY respond to the CREATE command with one or more 232 IMAP mailbox referrals, if it wishes to direct the client to issue 233 the CREATE against another server. The server can employ any means, 234 such as examining the hierarchy of the specified mailbox name, in 235 determining which server the mailbox should be created on. 237 Example: 239 C: A001 CREATE "SHARED/FOO" 240 S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO] 241 Mailbox should be created on remote server 243 Alternatively, because a home server is required to maintain a 244 listing of referred remote mailboxes, a server MAY allow the 245 creation of a mailbox that will ultimately reside on a remote server 246 against the home server, and provide referrals on subsequent 247 commands that manipulate the mailbox. 249 Example: 251 C: A001 CREATE "SHARED/FOO" 252 S: A001 OK CREATE succeeded 254 C: A002 SELECT "SHARED/FOO" 255 S: A002 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO] 256 Remote mailbox. Try SERVER2 258 Gahrns 5 259 4.3. RENAME Referrals 261 An IMAP4 server MAY respond to the RENAME command with one or more 262 pairs of IMAP mailbox referrals. In each pair of IMAP mailbox 263 referrals, the first one is an URL to the existing mailbox name and 264 the second is an URL to the requested new mailbox name. 266 If within an IMAP mailbox referral pair, the existing and new 267 mailbox URLs are on different servers, the remote servers are unable 268 to perform the RENAME operation. To achieve the same behavior of 269 server RENAME, the client MAY issue the constituent CREATE, FETCH, 270 APPEND, and DELETE commands against both servers. 272 If within an IMAP mailbox referral pair, the existing and new 273 mailbox URLs are on the same server it is an indication that the 274 currently connected server is unable to perform the operation. The 275 client can simply re-issue the RENAME command on the remote server. 277 Example: 279 C: A001 RENAME FOO BAR 280 S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER1/FOO 281 IMAP://user;AUTH=*@SERVER2/BAR] Unable to rename mailbox 282 across servers 284 Since the existing and new mailbox names are on different servers, 285 the client would be required to make a connection to both servers 286 and issue the constituent commands require to achieve the RENAME. 288 Example: 290 C: A001 RENAME FOO BAR 291 S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/FOO 292 IMAP://user;AUTH=*@SERVER2/BAR] Unable to rename mailbox 293 located on SERVER2 295 Since both the existing and new mailbox are on the same remote 296 server, the client can simply make a connection to the remote server 297 and re-issue the RENAME command. 299 4.4. COPY Referrals 301 An IMAP4 server MAY respond to the COPY command with one or more 302 IMAP mailbox referrals. This indicates that the destination mailbox 303 is on a remote server. To achieve the same behavior of a server 304 COPY, the client MAY issue the constituent FETCH and APPEND commands 305 against both servers. 307 Gahrns 6 308 Example: 310 C: A001 COPY 1 "SHARED/STUFF" 311 S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/STUFF] 312 Unable to copy message(s) to SERVER2. 314 5.1 RLIST command 316 Arguments: reference name 317 mailbox name with possible wildcards 319 Responses: untagged responses: LIST 321 Result: OK - RLIST Completed 322 NO - RLIST Failure 323 BAD - command unknown or arguments invalid 325 The RLIST command behaves identically to its LIST counterpart, 326 except remote mailboxes are returned in addition to local mailboxes 327 in the LIST responses. 329 5.2 RLSUB Command 331 Arguments: reference name 332 mailbox name with possible wildcards 334 Responses: untagged responses: LSUB 336 Result: OK - RLSUB Completed 337 NO - RLSUB Failure 338 BAD - command unknown or arguments invalid 340 The RLSUB command behaves identically to its LSUB counterpart, 341 except remote mailboxes are returned in addition to local mailboxes 342 in the LSUB responses. 344 6. Formal Syntax 346 The following syntax specification uses the augmented Backus-Naur 347 Form (BNF) as described in [ABNF]. 349 list_mailbox = as defined in [RFC-2060] 351 mailbox = as defined in [RFC-2060] 353 mailbox_referral = SPACE "NO" SPACE 354 (text / text_mime2) 355 ; See [RFC-2060] for , text and text_mime2 definition 357 Gahrns 7 358 referral_response_code = "[" "REFERRAL" 1*(SPACE ) "]" 359 ; See [RFC-1738] for definition 361 rlist = "RLIST" SPACE mailbox SPACE list_mailbox 363 rlsub = "RLSUB" SPACE mailbox SPACE list_mailbox 365 6. Security Considerations 367 The IMAP4 referral mechanism makes use of IMAP URLs, and as such, 368 have the same security considerations as general internet URLs [RFC- 369 1738], and in particular IMAP URLs [IMAP-URL]. 371 With the MAILBOX-REFERRALS capability, it is potentially easier to 372 write a rogue server that injects a bogus referral response that 373 directs a user to an incorrect mailbox. Although referrals reduce 374 the effort to write such a server, the referral response makes 375 detection of the intrusion easier. 377 7. References 379 [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version 380 4rev1", RFC 2060, University of Washington, December 1996. 382 [IMAP-URL], Newman, C., "IMAP URL Scheme", draft-newman-url-imap- 383 08.txt (work in progress), Innosoft, March 1997 385 [RFC-1738], Berners-Lee, Masinter, McCahill, "Uniform Resource 386 Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of 387 Minnesota, December 1994 389 [RFC-2119], Bradner, S, "Key words for use in RFCs to Indicate 390 Requirement Levels", RFC 2119, Harvard University, March 1997 392 [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for 393 Syntax Specifications: ABNF", draft-drums-abnf-02.txt (work in 394 progress), Internet Mail Consortium, April 1997 396 8. Acknowledgments 398 Many valuable suggestions were received from private discussions and 399 the IMAP4 mailing list. In particular, Raymond Cheng, Mark Crispin, 400 Mark Keasling Chris Newman and Larry Osterman made significant 401 contributions to this document. 403 Gahrns 8 404 9. Author's Address 406 Mike Gahrns 407 Microsoft 408 One Microsoft Way 409 Redmond, WA, 98072 411 Phone: (206) 936-9833 412 Email: mikega@microsoft.com 414 Gahrns 9