Network Working Group M. Gahrns Internet Draft Microsoft Document: draft-gahrns-imap-login-referrals-00.txt May 1997 IMAP4 Login 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 November 1997. Distribution of this draft is unlimited. 1. Abstract When dealing with large amounts of users and many IMAP4 [RFC-2060] servers, it is often necessary to move users from one IMAP4 server to another. For example, hardware failures or organizational changes may dictate such a move. Login referrals allow clients to transparently connect to an alternate IMAP4 server, if their home IMAP4 server has changed. 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. Gahrns 1 IMAP4 Login Referrals May 1997 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 server is a server that contains remote mailboxes. 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 LOGIN-REFERRALS in their CAPABILITY response. No client action is needed to invoke the LOGIN-REFERRALS capability in a server. A LOGIN-REFERRALS capable IMAP4 server MUST NOT return referrals that result in a referrals loop. A LOGIN-REFERRALS response code MUST contain as an argument a valid IMAP server URL as defined in [IMAP-URL]. A home server referral consists of either an tagged NO or an untagged BYE response that contains a LOGIN-REFERRALS response code. Example: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/] Remote Server NOTE: user;AUTH=* is specified as required by [IMAP-URL] to avoid a client falling back to anonymous login. 4. Home Server Referrals A home server referral may be returned in response to an AUTHENTICATE or LOGIN command, or 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. After receiving a home server referral, the client can not make any assumptions as to whether this was a permanent or temporary move of 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 2 IMAP4 Login Referrals May 1997 Example: C: A001 LOGIN MIKE PASSWORD S: A001 NO [REFERRAL IMAP://user@SERVER2/] Specified user is invalid on this server. Try SERVER2. Example: C: A001 AUTHENTICATE GSSAPI <authentication exchange> S: A001 NO [REFERRAL IMAP://user;AUTH=GSSAPI@SERVER2/] 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://user;AUTH=*@SERVER2/] Server not accepting connections. Try SERVER2 5. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in [ABNF]. connection_referral = "*" SPACE "BYE" SPACE <referral_response_code> (text / text_mime2) ; See [RFC-2060] for text and text_mime2 definition login_referral = <tag> SPACE "NO" SPACE <referral_response_code> (text / text_mime2) ; See [RFC-2060] for <tag>, text and text_mime2 definition referral_response_code = "[" "REFERRAL" SPACE <url> "]" ; See [IMAP-URL] for <url> definition 6. Security Considerations The IMAP4 login 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]. With the LOGIN-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. Although referrals reduce the effort to write such a server, the referral response makes detection of the intrusion easier. Gahrns 3 IMAP4 Login Referrals May 1997 7. 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- 08.txt (work in progress), Innosoft, May 1997 [RFC-1738], Berners-Lee, Masinter, 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", draft-drums-abnf-02.txt (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. 9. Author's Address Mike Gahrns Microsoft One Microsoft Way Redmond, WA, 98072 Phone: (206) 936-9833 Email: mikega@microsoft.com Gahrns 4