Internet Draft M. Karppinen Document: draft-karppinen-imap-conman-00.txt Icon Medialab Expires: April 2000 A. Skalski Chek October 1999 IMAP4 Connection Management Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 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, and should be addressed to the authors at persistentimap@chek.com. This document will expire before April 2000. Distribution of this draft is unlimited. 1. Abstract The IMAP4 [RFC-2060] protocol is based on the client-server paradigm where a single client is concerned only with the mail of a single user. However, due to advent of several scenarios where n-tier interaction is desired, the need has arisen to work with several users' mail during a single IMAP4 connection. In such scenario, a component of a n-tier system may act as an IMAP4 client on behalf of multiple end-users. Present examples of this include many WWW-based email services. Initial profiling suggests that persistent IMAP4 connections can lead to a performance increase of an order of magnitude when compared to separate IMAP4 connections per mailbox action. This document defines an extension to the IMAP4 protocol that allows a persistent connection to be established for accessing the mail of multiple users. The extension includes a new USERLOGOUT command, and a requirement for a CAPABILITIES response from servers implementing the extension. 2. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 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]. The key words "user", "client", and "connection" in this document are to be interpreted as described in [RFC-2060]. "User Session" refers to the sequence of client-server interaction from the time a user is logged in until that user is logged out. 3. Introduction and Overview The USERLOGOUT extension is present in any IMAP4 implementation which returns "USERLOGOUT" as one of the supported capabilities to the CAPABILITY command. The USERLOGOUT command introduced by this extension is used to end the current user session and return the connection to the Non-Authenticated state. The server responds by logging out the current user, closing any open folders, and waiting for the next user to log in. Alternatively, the server may choose to terminate the connection. The new USERLOGOUT command is available in the Authenticated and Selected states of an IMAP4 connection. When the client is done with the connection, it may disconnect by issuing a LOGOUT. 4. Implementation requirements IMAP4 servers that support this extension MUST list the keyword USERLOGOUT in their CAPABILITY response. If a server receives the USERLOGOUT command on a connection that was pre-authenticated, the server MUST terminate that connection. 5. An example session with Connection Management (1) The client connects to the server and requests CAPABILITY: C: a001 CAPABILITY S: * CAPABILITY IMAP4rev1 USERLOGOUT S: a001 CAPABILITY completed (2) The client can then initiate login/authentication and enter the Authenticated state. (3) When the Authenticated session is done, the client sends the USERLOGOUT command: C: a099 USERLOGOUT S: a099 USERLOGOUT completed (4) Repeat steps (2) and (3) for the number of Authenticated sessions that need to be handled. (5) The clients logs out and disconnects from the server. C: a999 LOGOUT S: * BYE IMAP4rev1 server terminating connection S: a999 LOGOUT completed 6. USERLOGOUT Command Available in Authenticated state: USERLOGOUT Command Arguments: none Responses: OPTIONAL untagged response: BYE Result: OK - userlogout completed BAD - command unknown or arguments invalid The USERLOGOUT command informs the server that the client is done with the current Authenticated session, and returns to non-authenticated state. The server MAY send a BYE untagged response before the (tagged) OK response, and then close the network connection. If the connection was pre-authenticated, the server MUST close the connection. Examples: C: A097 USERLOGOUT S: A097 OK USERLOGOUT completed C: A098 USERLOGOUT S: * BYE login session limit reached S: A098 OK USERLOGOUT completed 7. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as specified in [RFC-2234]. This extension adds to the IMAP4 grammar described in [RFC-2060] in the following ways: command_auth ::= append / create / delete / examine / list / lsub / rename / select / status / subscribe / unsubscribe / userlogout ;; Valid only in Authenticated or Selected state userlogout ::= "USERLOGOUT" 8. Security Considerations This extension allows the client to maintain the Non-Authenticated state between multiple Authenticated sessions. As such, it doesn't imply changes to IMAP4 security. However, most current IMAP4 server implementations are designed to handle only one user session per single server process. If such an implementation is upgraded to be in compliance with this extension, the process lifespan will be greatly lenghtened, easily leading to resource leaks and other problems that could pave the way to Denial of Service attacks. The servers implementing this extension MUST consider every authentication request (AUTHENTICATE or LOGIN command) separately. The same authentication credentials may or may not have been used in earlier Authenticated sessions during the connection. Even so, the earlier sessions MUST NOT have any effect on the authentication process in later ones. 9. References [RFC-2060] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996. [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC-2234] Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. 10. Authors' Addresses Marko Karppinen Icon Medialab Finland Aleksanterinkatu 15 A FIN-00100 Helsinki Finland Phone: +358 40 541 3399 Email: marko@iconmedialab.fi Andrew Skalski Chek, Inc. 300 Theatre Place Buffalo, NY 14202 Phone: +1 716 853 1350 Email: askalski@chekinc.com 11. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published andand distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."