idnits 2.17.1 draft-gahrns-imap-login-referrals-02.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-25) 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 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: ---------------------------------------------------------------------------- -- 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 (October 1997) is 9689 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) ** Obsolete normative reference: RFC 2060 (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 2192 (ref. 'IMAP-URL') (Obsoleted by RFC 5092) ** 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 (~~), 2 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-login-referrals-02.txt October 1997 5 IMAP4 Login 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 May 1998. Distribution of this draft is 29 unlimited. 31 1. Abstract 33 When dealing with large amounts of users and many IMAP4 [RFC-2060] 34 servers, it is often necessary to move users from one IMAP4 server 35 to another. For example, hardware failures or organizational 36 changes may dictate such a move. 38 Login referrals allow clients to transparently connect to an 39 alternate IMAP4 server, if their home IMAP4 server has changed. 41 A referral mechanism can provide efficiencies over the alternative 42 'proxy method', in which the local IMAP4 server contacts the remote 43 server on behalf of the client, and then transfers the data from the 44 remote server to itself, and then on to the client. The referral 45 mechanism's direct client connection to the remote server is often a 46 more efficient use of bandwidth, and does not require the local 47 server to impersonate the client when authenticating to the remote 48 server. 50 Gahrns 1 51 IMAP4 Login Referrals October 1997 53 2. Conventions used in this document 55 In examples, "C:" and "S:" indicate lines sent by the client and 56 server respectively. 58 A home server, is an IMAP4 server that contains the user's inbox. 60 A remote server is a server that contains remote mailboxes. 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 64 this document are to be interpreted as described in [RFC-2119]. 66 3. Introduction and Overview 68 IMAP4 servers that support this extension MUST list the keyword 69 LOGIN-REFERRALS in their CAPABILITY response. No client action is 70 needed to invoke the LOGIN-REFERRALS capability in a server. 72 A LOGIN-REFERRALS capable IMAP4 server MUST NOT return referrals 73 that result in a referrals loop. 75 A LOGIN-REFERRALS response code MUST contain as an argument a valid 76 IMAP server URL as defined in [IMAP-URL]. 78 A home server referral consists of either a tagged NO or OK, or an 79 untagged BYE response that contains a LOGIN-REFERRALS response code. 81 Example: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/] Remote 82 Server 84 NOTE: user;AUTH=* is specified as required by [IMAP-URL] to avoid a 85 client falling back to anonymous login. 87 4. Home Server Referrals 89 A home server referral may be returned in response to an 90 AUTHENTICATE or LOGIN command, or it may appear in the connection 91 startup banner. If a server returns a home server referral in a 92 tagged NO response, that server does not contain any mailboxes that 93 are accessible to the user. If a server returns a home server 94 referral in a tagged OK response, it indicates that the user's 95 personal mailboxes are elsewhere, but the server contains public 96 mailboxes which are readable by the user. After receiving a home 97 server referral, the client can not make any assumptions as to 98 whether this was a permanent or temporary move of the user. 100 Gahrns 2 101 IMAP4 Login Referrals October 1997 103 4.1. LOGIN and AUTHENTICATE Referrals 105 An IMAP4 server MAY respond to a LOGIN or AUTHENTICATE command with 106 a home server referral if it wishes to direct the user to another 107 IMAP4 server. 109 Example: C: A001 LOGIN MIKE PASSWORD 110 S: A001 NO [REFERRAL IMAP://MIKE@SERVER2/] Specified user 111 is invalid on this server. Try SERVER2. 113 Example: C: A001 LOGIN MATTHEW PASSWORD 114 S: A001 OK [REFERRAL IMAP://MATTHEW@SERVER2/] Specified 115 user's personal mailboxes located on Server2, but 116 public mailboxes are available. 118 Example: C: A001 AUTHENTICATE GSSAPI 119 120 S: A001 NO [REFERRAL IMAP://user;AUTH=GSSAPI@SERVER2/] 121 Specified user is invalid on this server. Try 122 SERVER2. 124 4.2. BYE at connection startup referral 126 An IMAP4 server MAY respond with an untagged BYE and a REFERRAL 127 response code that contains an IMAP URL to a home server if it is 128 not willing to accept connections and wishes to direct the client to 129 another IMAP4 server. 131 Example: S: * BYE [REFERRAL IMAP://user;AUTH=*@SERVER2/] Server not 132 accepting connections. Try SERVER2 134 5. Formal Syntax 136 The following syntax specification uses the augmented Backus-Naur 137 Form (BNF) as described in [ABNF]. 139 This amends the "resp_text_code" element of the IMAP4 grammar 140 described in [RFC-2060] 142 resp_text_code =/ "REFERRAL" SPACE 143 ; See [IMAP-URL] for definition of 144 ; See [RFC-2060] for base definition of resp_text_code 146 6. Security Considerations 148 The IMAP4 login referral mechanism makes use of IMAP URLs, and as 149 such, have the same security considerations as general internet URLs 150 [RFC-1738], and in particular IMAP URLs [IMAP-URL]. 152 Gahrns 3 153 IMAP4 Login Referrals October 1997 155 A server MUST NOT give a login referral if authentication for that 156 user fails. This is to avoid revealing information about the user's 157 account to an unauthorized user. 159 With the LOGIN-REFERRALS capability, it is potentially easier to 160 write a rogue 'password catching' server that collects login data 161 and then refers the client to their actual IMAP4 server. Although 162 referrals reduce the effort to write such a server, the referral 163 response makes detection of the intrusion easier. 165 7. References 167 [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version 168 4rev1", RFC 2060, University of Washington, December 1996. 170 [IMAP-URL], Newman, C., "IMAP URL Scheme", RFC 2192, Innosoft, 171 September 1997 173 [RFC-1738], Berners-Lee, Masinter, McCahill, "Uniform Resource 174 Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of 175 Minnesota, December 1994 177 [RFC-2119], Bradner, S, "Key words for use in RFCs to Indicate 178 Requirement Levels", RFC 2119, Harvard University, March 1997 180 [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for 181 Syntax Specifications: ABNF", draft-drums-abnf-04.txt (work in 182 progress), Internet Mail Consortium, September 1997 184 8. Acknowledgments 186 Many valuable suggestions were received from private discussions and 187 the IMAP4 mailing list. In particular, Raymond Cheng, Mark Crispin, 188 Mark Keasling Chris Newman and Larry Osterman made significant 189 contributions to this document. 191 9. Author's Address 193 Mike Gahrns 194 Microsoft 195 One Microsoft Way 196 Redmond, WA, 98072 198 Phone: (206) 936-9833 199 Email: mikega@microsoft.com 201 Gahrns 4