idnits 2.17.1 draft-gahrns-imap-referrals-02.txt: ** The Abstract section seems to be numbered -(122): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(389): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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-03-29) 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. == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 9) being 60 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: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 1997) is 9845 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: 'RFC1738' is mentioned on line 86, but not defined ** Obsolete undefined reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) == Missing Reference: 'UNSEEN 10' is mentioned on line 251, but not defined == Missing Reference: 'UIDVALIDITY 123456789' is mentioned on line 252, but not defined ** Obsolete normative reference: RFC 2060 (Obsoleted by RFC 3501) == Outdated reference: A later version (-09) exists of draft-newman-url-imap-06 ** 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: 13 errors (**), 0 flaws (~~), 7 warnings (==), 4 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-referrals-02.txt April 1997 5 IMAP4 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 October 1997. Distribution of this draft 29 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. Additionally, 41 users may be frequently moved from one IMAP4 server to another 42 because of hardware failures or organizational changes. 44 Referrals allow clients to seamlessly access mailboxes that are 45 distributed across several IMAP4 servers or to transparently connect 46 to an alternate IMAP4 server. 48 A referral mechanism can provide efficiencies over the alternative 49 "proxy method", in which the local IMAP4 server contacts the remote 50 server on behalf of the client, and then transfers the data from the 51 remote server to itself, and then on to the client. The referral 52 mechanism's direct client connection to the remote server is often a 53 more efficient use of bandwidth, and does not require the local 54 server to impersonate the client when authenticating to the remote 55 server. 57 2. Conventions used in this document 59 In examples, "C:" and "S:" indicate lines sent by the client and 60 server respectively. 62 A home server, is an IMAP4 server that contains the user's inbox. 64 A remote mailbox is a mailbox that is not hosted on the user's home 65 server. 67 A remote server is a server that contains remote mailboxes. 69 A shared mailbox, is a mailbox that multiple users have access to. 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 73 this document are to be interpreted as described in [RFC-2119]. 75 3. Introduction and Overview 77 IMAP4 servers that support this extension MUST list the keyword 78 REFERRALS in their CAPABILITY response. No client action is needed 79 to invoke the REFERRALS capability in a server. 81 A REFERRALS capable IMAP4 server SHOULD NOT return referrals that 82 result in a referrals loop. 84 A referral response consists of an untagged NO response and a 85 REFERRAL response code. The REFERRAL response code MUST contain as 86 an argument a valid URL as defined in [RFC1738]. If a server replies 87 with multiple URLs for a particular object, they MUST all be of the 88 same type. When referring to another IMAP server or mailbox, the 89 URL MUST be an IMAP URL as defined in [IMAP-URL]. A client that 90 supports the REFERRALS extension MUST be prepared for a URL of any 91 type, but it need only be to process IMAP URLs. 93 A home server referral consists of a referral response that contains 94 as an argument an IMAP URL minimally specifying the home server 95 name. A home server referral may be given in response to a LOGIN or 96 AUTHENTICATE command. 98 Example: * NO [REFERRAL IMAP://SERVER2] Remote Server 99 An IMAP mailbox referral consists of a referral response that 100 contains as an argument an IMAP URL minimally specifying the remote 101 server and mailbox. A server MAY respond with multiple IMAP mailbox 102 referrals if there is more than one replica of the mailbox. This 103 allows the implementation of a load balancing or failover scheme. 104 How a server keeps multiple replicas of a mailbox in sync is not 105 addressed by this document. 107 If the server has a preferred order in which the client should 108 attempt to access the URLs, the preferred URL SHOULD be listed in 109 the first untagged response, with the remaining URLs presented in 110 descending order of preference. If multiple referrals are given for 111 a mailbox, a server should be aware that there are synchronization 112 issues for a client if the UIDVALIDITY of the referred mailboxes are 113 different. An IMAP mailbox referral may be given in response to an 114 IMAP command that specifies a mailbox as an argument. 116 Example: * NO [REFERRAL IMAP://SERVER2/REMOTE] Remote Mailbox 117 * NO [REFERRAL IMAP://SERVER3/REMOTE] Remote Mailbox 119 Remote mailboxes that are accessible via referrals SHOULD appear in 120 LIST and LSUB responses issued against the user's home server. For 121 example, if shared mailboxes were only accessible via referrals on a 122 remote server, a LIST �� "#SHARED%� command would return the same 123 response if issued against the user's home server or the remote 124 server. 126 Note: Mailboxes that are available on the user's home server do not 127 need to be available on the remote server. In addition, there may 128 be additional mailboxes available on the remote server, but they 129 will not accessible to the client via referrals unless they appear 130 in the LIST response on the user's home server. 132 Hierarchy referrals, in which a client would be required to connect 133 to the remote server to issue a LIST to discover the inferiors of a 134 mailbox are not addressed in this document. 136 4. Home Server Referrals 138 A home server referral may be returned in response to an 139 AUTHENTICATE or LOGIN command, or a derivative of it may appear in 140 the connection startup banner. If a server returns a home server 141 referral, that server does not contain any mailboxes that are 142 accessible to the user. 144 4.1. LOGIN and AUTHENTICATE Referrals 146 An IMAP4 server MAY respond to a LOGIN or AUTHENTICATE command with 147 a home server referral if it wishes to direct the user to another 148 IMAP4 server. 150 Example: C: A001 LOGIN MIKE PASSWORD 151 S: * NO [REFERRAL IMAP://SERVER2/] Remote Server 152 S: A001 NO Specified user is invalid on this server. 153 Try SERVER2 155 Example: C: A001 AUTHENTICATE KERBEROS_V4 156 S: + AweFG-0 157 C: BFsDdfJLEfdLeLLEFF9KLWsdfelf/Sdfef4sdwe 158 S: + wsEd/aSSWf 159 C: HiWdf3fg45fw:Lge 160 S: * NO [REFERRAL IMAP://SERVER2/] Remote Server 161 S: A001 NO Specified user is invalid on this server. 162 Try SERVER2 164 4.2. BYE at connection startup referral 166 An IMAP4 server MAY respond with an untagged BYE and a REFERRAL 167 response code that contains an IMAP URL to a home server if it is 168 not willing to accept connections and wishes to direct the client to 169 another IMAP4 server. 171 Example: S: * BYE [REFERRAL IMAP://SERVER2/] Server not accepting 172 connections. Try SERVER2 174 5. IMAP Mailbox Referrals 176 One or more IMAP mailbox referrals MAY be returned in response to a 177 SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, 178 STATUS, APPEND or COPY command. 180 5.1. SELECT, EXAMINE, DELETE, SUBSCRIBE, UNSUBSCRIBE, STATUS and APPEND 181 Referrals 183 An IMAP4 server MAY respond to the SELECT, EXAMINE, DELETE, 184 SUBSCRIBE, UNSUBSCRIBE, STATUS or APPEND command with one or more 185 IMAP mailbox referrals to indicate to the client that the mailbox is 186 hosted on a remote server. 188 When a client processes an IMAP mailbox referral, it will open a new 189 connection or use an existing connection to the remote server so 190 that it is able to issue the commands necessary to process the 191 remote mailbox. 193 Example: 195 C: A001 DELETE "SHARED/FOO" 196 S: * NO [REFERRAL IMAP://SERVER2/SHARED/FOO] Remote 197 Mailbox 198 S: A001 NO Remote mailbox. Try SERVER2 199 202 S: * OK IMAP4rev1 server ready 203 C: B001 LOGIN USER PASSWORD 204 S: B001 OK LOGIN completed 206 C: B002 DELETE "SHARED/FOO" 207 S: B002 OK DELETE completed. 209 Example: 211 C: A001 SELECT REMOTE 212 S: * NO [REFERRAL IMAP://SERVER2/REMOTE] Remote mailbox 213 S: * NO [REFERRAL IMAP://SERVER3/REMOTE] Remote mailbox 214 S: A001 NO Remote mailbox. Try SERVER2 or SERVER3 216 220 S: * OK IMAP4rev1 server ready 221 C: B001 LOGIN USER PASSWORD 222 S: B001 OK LOGIN completed 224 C: B002 SELECT REMOTE 225 S: * 12 EXISTS 226 S: * 1 RECENT 227 S: * OK [UNSEEN 10] Message 10 is first unseen 228 S: * OK [UIDVALIDITY 123456789] 229 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 230 S: * OK [PERMANENTFLAGS (\Answered \Deleted \Seen \*)] 231 S: B002 OK [READ-WRITE] Selected completed 233 C: B003 FETCH 10:12 RFC822 234 S: * 10 FETCH . . . 235 S: * 11 FETCH . . . 236 S: * 12 FETCH . . . 237 S: B003 OK FETCH Completed 239 242 C: B004 LOGOUT 243 S: * BYE IMAP4rev1 server logging out 244 S: B004 OK LOGOUT Completed 246 248 C: A002 SELECT INBOX 249 S: * 16 EXISTS 250 S: * 2 RECENT 251 S: * OK [UNSEEN 10] Message 10 is first unseen 252 S: * OK [UIDVALIDITY 123456789] 253 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 254 S: * OK [PERMANENTFLAGS (\Answered \Deleted \Seen \*)] 255 S: A002 OK [READ-WRITE] Selected completed 257 5.2. CREATE Referrals 259 An IMAP4 server MAY respond to the CREATE command with one or more 260 IMAP mailbox referrals, if it wishes to direct the client to issue 261 the CREATE against another server. The server can employ any means, 262 such as examining the hierarchy of the specified mailbox name, in 263 determining which server the mailbox should be created on. 265 Example: 267 C: A001 CREATE "SHARED/FOO" 268 S: * NO [REFERRAL IMAP://SERVER2/SHARED/FOO] Remote 269 mailbox 270 S: A001 NO Mailbox should be created on remote server 272 Alternatively, because a home server is required to maintain a 273 listing of referred remote mailboxes, a server MAY allow the 274 creation of a mailbox that will ultimately reside on a remote server 275 against the home server, and provide referrals on subsequent 276 commands that manipulate the mailbox. 278 Example: 279 C: A001 CREATE "SHARED/FOO" 280 S: A001 OK CREATE succeeded 282 C: A002 SELECT "SHARED/FOO" 283 S: * NO [REFERRAL IMAP://SERVER2/SHARED/FOO] Remote 284 Mailbox 285 S: A002 NO Remote mailbox. Try SERVER2 287 5.4. RENAME Referrals 289 An IMAP4 server MAY respond to the RENAME command with one or more 290 pairs of IMAP mailbox referrals. In each pair of IMAP mailbox 291 referrals, the first one is an URL to the existing mailbox name and 292 the second is an URL to the requested new mailbox name. 294 If within an IMAP mailbox referral pair, the existing and new 295 mailbox URLs are on different servers, the remote servers are unable 296 to perform the RENAME operation. To achieve the same behavior of 297 server RENAME, the client MAY issue the constituent CREATE, FETCH, 298 APPEND, and DELETE commands against both servers. 300 If within an IMAP mailbox referral pair, the existing and new 301 mailbox URLs are on the same server it is an indication that the 302 currently connected server is unable to perform the operation. The 303 client can simply re-issue the RENAME command on the remote server. 305 Example: 306 C: A001 RENAME FOO BAR 307 S: * NO [REFERRAL IMAP://SERVER1/FOO] Remote mailbox 308 S: * NO [REFERRAL IMAP://SERVER2/BAR] Remote mailbox 309 S: A001 NO Unable to rename mailbox across servers 311 Since the existing and new mailbox names are on different servers, 312 the client would be required to make a connection to both servers 313 and issue the constituent commands require to achieve the RENAME. 315 Example: 316 C: A001 RENAME FOO BAR 317 S: * NO [REFERRAL IMAP://SERVER2/FOO] Remote mailbox 318 S: * NO [REFERRAL IMAP://SERVER2/BAR] Remote mailbox 319 S: A001 NO Unable to rename mailbox located on SERVER2 321 Since both the existing and new mailbox are on the same remote 322 server, the client can simply make a connection to the remote server 323 and re-issue the RENAME command. 325 5.5. COPY Referrals 327 An IMAP4 server MAY respond to the COPY command with one or more 328 IMAP mailbox referrals. This indicates that the destination mailbox 329 is on a remote server. To achieve the same behavior of a server 330 COPY, the client MAY issue the constituent FETCH and APPEND commands 331 against both servers. 333 Example: 334 C: A001 COPY 1 "SHARED/PROJECT" 335 S: * NO [REFERRAL IMAP://SERVER2/SHARED/PROJECT] Remote 336 mailbox 337 S: A001 NO Unable to copy message(s) to SERVER2. 339 6. Formal Syntax 341 The following syntax specification uses the augmented Backus-Naur 342 Form (BNF) as described in [ABNF]. 344 connection_referral = "*" SPACE "BYE" SPACE 345 (text / text_mime2) 347 home_server_or_mailbox_referral = "*" SPACE "NO" SPACE 348 (text / text_mime2) 350 referral_response_code = "[" "REFERRAL" SPACE "]" 352 text = 1*text_char 354 text_char = 356 text_mime2 = "=?" "?" "?" "?=" 357 ; , , syntax as 358 ; defined in [RFC-2047] 360 url = 362 7. Security Considerations 364 The IMAP4 referral mechanism makes use of IMAP URLs, and as such, 365 have the same security considerations as general internet URLs [RFC- 366 1738], and in particular IMAP URLs [IMAP-URL]. 368 In the general case, only the remote server information is passed 369 back to the client in the IMAP URL. No referral scenarios are 370 envisioned that would require user and password information to be 371 passed back in the IMAP URL. Should they arise, including passwords 372 in the URL is discouraged unless this can be accomplished in a 373 secure manner. 375 In addition, the IMAP URL scheme allows a client authentication 376 mechanism to be specified and should be used when a server supports 377 a preferred authentication mechanism. 379 With the REFERRALS capability, it is potentially easier to write a 380 rogue 'password catching' server that collects login data and then 381 refers the client to their actual IMAP4 server. Also made easier, 382 is the ability for a rogue server to inject a bogus referral 383 response that directs a user to an incorrect mailbox. Although 384 referrals reduce the effort to write such a server, the REFERRAL 385 response makes detection of the intrusion easier. 387 8. References 389 [RFC-2060], Crispin, M., "Internet Message Access Protocol � Version 390 4rev1", RFC 2060, University of Washington, December 1996. 392 [IMAP-URL], Newman, C., "IMAP URL Scheme", draft-newman-url-imap- 393 06.txt (work in progress), Innosoft, March 1997 395 [RFC-1738], Berners-Lee, Masinter, McCahill, "Uniform Resource 396 Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of 397 Minnesota, December 1994 399 [RFC-2047], Moore, K., "MIME (Multipurpose Internet Mail Extensions) 400 Part Three: Message Header Extension for Non-ASCII Text", RFC 2047, 401 November 1996. 403 [RFC-2119], Bradner, S, "Key words for use in RFCs to Indicate 404 Requirement Levels", RFC 2119, Harvard University, March 1997 406 [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for 407 Syntax Specifications: ABNF", draft-drums-abnf-02.txt (work in 408 progress), Internet Mail Consortium, April 1997 410 9. Acknowledgments 412 Many valuable suggestions were received from private discussions and 413 the IMAP4 mailing list. In particular, Raymond Cheng, Mark Crispin, 414 Mark Keasling Chris Newman and Larry Osterman made significant 415 contributions to this document. 417 10. Author's Address 419 Mike Gahrns 420 Microsoft 421 One Microsoft Way 422 Redmond, WA, 98072 424 Phone: (206) 936-9833 425 Email: mikega@microsoft.co 427 m