1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/docs/rfc/rfc2221.txt	Mon Sep 14 15:17:45 2009 +0900
     1.3 @@ -0,0 +1,283 @@
     1.4 +
     1.5 +
     1.6 +
     1.7 +
     1.8 +
     1.9 +
    1.10 +Network Working Group                                           M. Gahrns
    1.11 +Request for Comments: 2221                                      Microsoft
    1.12 +Category: Standards Track                                    October 1997
    1.13 +
    1.14 +
    1.15 +                         IMAP4 Login Referrals
    1.16 +
    1.17 +Status of this Memo
    1.18 +
    1.19 +   This document specifies an Internet standards track protocol for the
    1.20 +   Internet community, and requests discussion and suggestions for
    1.21 +   improvements.  Please refer to the current edition of the "Internet
    1.22 +   Official Protocol Standards" (STD 1) for the standardization state
    1.23 +   and status of this protocol.  Distribution of this memo is unlimited.
    1.24 +
    1.25 +Copyright Notice
    1.26 +
    1.27 +   Copyright (C) The Internet Society (1997).  All Rights Reserved.
    1.28 +
    1.29 +1. Abstract
    1.30 +
    1.31 +   When dealing with large amounts of users and many IMAP4 [RFC-2060]
    1.32 +   servers, it is often necessary to move users from one IMAP4 server to
    1.33 +   another.  For example, hardware failures or organizational changes
    1.34 +   may dictate such a move.
    1.35 +
    1.36 +   Login referrals allow clients to transparently connect to an
    1.37 +   alternate IMAP4 server, if their home IMAP4 server has changed.
    1.38 +
    1.39 +   A referral mechanism can provide efficiencies over the alternative
    1.40 +   'proxy method', in which the local IMAP4 server contacts the remote
    1.41 +   server on behalf of the client, and then transfers the data from the
    1.42 +   remote server to itself, and then on to the client.  The referral
    1.43 +   mechanism's direct client connection to the remote server is often a
    1.44 +   more efficient use of bandwidth, and does not require the local
    1.45 +   server to impersonate the client when authenticating to the remote
    1.46 +   server.
    1.47 +
    1.48 +2. Conventions used in this document
    1.49 +
    1.50 +   In examples, "C:" and "S:" indicate lines sent by the client and
    1.51 +   server respectively.
    1.52 +
    1.53 +   A home server, is an IMAP4 server that contains the user's inbox.
    1.54 +
    1.55 +   A remote server is a server that contains remote mailboxes.
    1.56 +
    1.57 +
    1.58 +
    1.59 +
    1.60 +
    1.61 +Gahrns                      Standards Track                     [Page 1]
    1.62 +
    1.63 +RFC 2221                 IMAP4 Login Referrals              October 1997
    1.64 +
    1.65 +
    1.66 +   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    1.67 +   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
    1.68 +   document are to be interpreted as described in [RFC-2119].
    1.69 +
    1.70 +3. Introduction and Overview
    1.71 +
    1.72 +   IMAP4 servers that support this extension MUST list the keyword
    1.73 +   LOGIN-REFERRALS in their CAPABILITY response.  No client action is
    1.74 +   needed to invoke the LOGIN-REFERRALS capability in a server.
    1.75 +
    1.76 +   A LOGIN-REFERRALS capable IMAP4 server SHOULD NOT return a referral
    1.77 +   to a server that will return a referral. A client MUST NOT follow
    1.78 +   more than 10 levels of referral without consulting the user.
    1.79 +
    1.80 +   A LOGIN-REFERRALS response code MUST contain as an argument a valid
    1.81 +   IMAP server URL as defined in [IMAP-URL].
    1.82 +
    1.83 +   A home server referral consists of either a tagged NO or OK, or an
    1.84 +   untagged BYE response that contains a LOGIN-REFERRALS response code.
    1.85 +
    1.86 +   Example: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/] Remote Server
    1.87 +
    1.88 +   NOTE: user;AUTH=* is specified as required by [IMAP-URL] to avoid a
    1.89 +   client falling back to anonymous login.
    1.90 +
    1.91 +4. Home Server Referrals
    1.92 +
    1.93 +   A home server referral may be returned in response to an AUTHENTICATE
    1.94 +   or LOGIN command, or it may appear in the connection startup banner.
    1.95 +   If a server returns a home server referral in a tagged NO response,
    1.96 +   that server does not contain any mailboxes that are accessible to the
    1.97 +   user.  If a server returns a home server referral in a tagged OK
    1.98 +   response, it indicates that the user's personal mailboxes are
    1.99 +   elsewhere, but the server contains public mailboxes which are
   1.100 +   readable by the user.  After receiving a home server referral, the
   1.101 +   client can not make any assumptions as to whether this was a
   1.102 +   permanent or temporary move of the user.
   1.103 +
   1.104 +4.1.  LOGIN and AUTHENTICATE Referrals
   1.105 +
   1.106 +   An IMAP4 server MAY respond to a LOGIN or AUTHENTICATE command with a
   1.107 +   home server referral if it wishes to direct the user to another IMAP4
   1.108 +   server.
   1.109 +
   1.110 +   Example:  C: A001 LOGIN MIKE PASSWORD
   1.111 +             S: A001 NO [REFERRAL IMAP://MIKE@SERVER2/] Specified user
   1.112 +                     is invalid on this server. Try SERVER2.
   1.113 +
   1.114 +
   1.115 +
   1.116 +
   1.117 +Gahrns                      Standards Track                     [Page 2]
   1.118 +
   1.119 +RFC 2221                 IMAP4 Login Referrals              October 1997
   1.120 +
   1.121 +
   1.122 +   Example:  C: A001 LOGIN MATTHEW PASSWORD
   1.123 +             S: A001 OK [REFERRAL IMAP://MATTHEW@SERVER2/] Specified
   1.124 +                     user's personal mailboxes located on Server2, but
   1.125 +                     public mailboxes are available.
   1.126 +
   1.127 +   Example:  C: A001 AUTHENTICATE GSSAPI
   1.128 +             <authentication exchange>
   1.129 +             S: A001 NO [REFERRAL IMAP://user;AUTH=GSSAPI@SERVER2/]
   1.130 +                     Specified user is invalid on this server. Try
   1.131 +                     SERVER2.
   1.132 +
   1.133 +4.2. BYE at connection startup referral
   1.134 +
   1.135 +   An IMAP4 server MAY respond with an untagged BYE and a REFERRAL
   1.136 +   response code that contains an IMAP URL to a home server if it is not
   1.137 +   willing to accept connections and wishes to direct the client to
   1.138 +   another IMAP4 server.
   1.139 +
   1.140 +   Example:  S: * BYE [REFERRAL IMAP://user;AUTH=*@SERVER2/] Server not
   1.141 +                  accepting connections.  Try SERVER2
   1.142 +
   1.143 +5. Formal Syntax
   1.144 +
   1.145 +   The following syntax specification uses the augmented Backus-Naur
   1.146 +   Form (BNF) as described in [ABNF].
   1.147 +
   1.148 +   This amends the "resp_text_code" element of the IMAP4 grammar
   1.149 +   described in [RFC-2060]
   1.150 +
   1.151 +   resp_text_code =/ "REFERRAL" SPACE <imapurl>
   1.152 +      ; See [IMAP-URL] for definition of <imapurl>
   1.153 +      ; See [RFC-2060] for base definition of resp_text_code
   1.154 +
   1.155 +6. Security Considerations
   1.156 +
   1.157 +   The IMAP4 login referral mechanism makes use of IMAP URLs, and as
   1.158 +   such, have the same security considerations as general internet URLs
   1.159 +   [RFC-1738], and in particular IMAP URLs [IMAP-URL].
   1.160 +
   1.161 +   A server MUST NOT give a login referral if authentication for that
   1.162 +   user fails. This is to avoid revealing information about the user's
   1.163 +   account to an unauthorized user.
   1.164 +
   1.165 +   With the LOGIN-REFERRALS capability, it is potentially easier to
   1.166 +   write a rogue 'password catching' server that collects login data and
   1.167 +   then refers the client to their actual IMAP4 server.  Although
   1.168 +   referrals reduce the effort to write such a server, the referral
   1.169 +   response makes detection of the intrusion easier.
   1.170 +
   1.171 +
   1.172 +
   1.173 +Gahrns                      Standards Track                     [Page 3]
   1.174 +
   1.175 +RFC 2221                 IMAP4 Login Referrals              October 1997
   1.176 +
   1.177 +
   1.178 +7. References
   1.179 +
   1.180 +   [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version
   1.181 +   4rev1", RFC 2060, December 1996.
   1.182 +
   1.183 +   [IMAP-URL], Newman, C., "IMAP URL Scheme", RFC 2192, Innosoft,
   1.184 +   September 1997.
   1.185 +
   1.186 +   [RFC-1738], Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
   1.187 +   Resource Locators  (URL)", RFC 1738, December 1994.
   1.188 +
   1.189 +   [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
   1.190 +   Requirement Levels", RFC 2119, March 1997.
   1.191 +
   1.192 +   [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for
   1.193 +   Syntax Specifications: ABNF", Work in Progress.
   1.194 +
   1.195 +8.  Acknowledgments
   1.196 +
   1.197 +   Many valuable suggestions were received from private discussions and
   1.198 +   the IMAP4 mailing list.  In particular, Raymond Cheng, Mark Crispin,
   1.199 +   Mark Keasling Chris Newman and Larry Osterman made significant
   1.200 +   contributions to this document.
   1.201 +
   1.202 +9. Author's Address
   1.203 +
   1.204 +   Mike Gahrns
   1.205 +   Microsoft
   1.206 +   One Microsoft Way
   1.207 +   Redmond, WA, 98072
   1.208 +
   1.209 +   Phone: (206) 936-9833
   1.210 +   EMail: mikega@microsoft.com
   1.211 +
   1.212 +
   1.213 +
   1.214 +
   1.215 +
   1.216 +
   1.217 +
   1.218 +
   1.219 +
   1.220 +
   1.221 +
   1.222 +
   1.223 +
   1.224 +
   1.225 +
   1.226 +
   1.227 +
   1.228 +
   1.229 +Gahrns                      Standards Track                     [Page 4]
   1.230 +
   1.231 +RFC 2221                 IMAP4 Login Referrals              October 1997
   1.232 +
   1.233 +
   1.234 +10.  Full Copyright Statement
   1.235 +
   1.236 +   Copyright (C) The Internet Society (1997).  All Rights Reserved.
   1.237 +
   1.238 +   This document and translations of it may be copied and furnished to
   1.239 +   others, and derivative works that comment on or otherwise explain it
   1.240 +   or assist in its implmentation may be prepared, copied, published
   1.241 +   andand distributed, in whole or in part, without restriction of any
   1.242 +   kind, provided that the above copyright notice and this paragraph are
   1.243 +   included on all such copies and derivative works.  However, this
   1.244 +   document itself may not be modified in any way, such as by removing
   1.245 +   the copyright notice or references to the Internet Society or other
   1.246 +   Internet organizations, except as needed for the purpose of
   1.247 +   developing Internet standards in which case the procedures for
   1.248 +   copyrights defined in the Internet Standards process must be
   1.249 +   followed, or as required to translate it into languages other than
   1.250 +   English.
   1.251 +
   1.252 +   The limited permissions granted above are perpetual and will not be
   1.253 +   revoked by the Internet Society or its successors or assigns.
   1.254 +
   1.255 +   This document and the information contained herein is provided on an
   1.256 +   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   1.257 +   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   1.258 +   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   1.259 +   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   1.260 +   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
   1.261 +
   1.262 +
   1.263 +
   1.264 +
   1.265 +
   1.266 +
   1.267 +
   1.268 +
   1.269 +
   1.270 +
   1.271 +
   1.272 +
   1.273 +
   1.274 +
   1.275 +
   1.276 +
   1.277 +
   1.278 +
   1.279 +
   1.280 +
   1.281 +
   1.282 +
   1.283 +
   1.284 +
   1.285 +Gahrns                      Standards Track                     [Page 5]
   1.286 +