Network Working Group R. Sparks Internet-Draft Tekelec Intended status: Informational Apr 3, 2013 Expires: October 5, 2013 IMAP Access to IETF Email List Archives draft-sparks-genarea-imaparch-06 Abstract The IETF makes heavy use of email lists to conduct its work. This often involves accessing the archived history of those email lists. Participants would like to have the ability to browse and search those archives using standard IMAP clients. This memo captures the requirements for providing a service that would allow such browsing and searching. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on October 5, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Sparks Expires October 5, 2013 [Page 1] Internet-Draft IMAP Access to IETF Email List Archives Apr 2013 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements for IMAP access to archived IETF lists . . . . . . 3 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 6. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.2. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.3. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.5. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.6. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.7. 00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Informative References . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Sparks Expires October 5, 2013 [Page 2] Internet-Draft IMAP Access to IETF Email List Archives Apr 2013 1. Introduction The IETF makes heavy use of email lists to conduct its work. This often involves accessing the archived history of those email lists. Requirements for improved web-based browsing and searching of these archives are captured in [RFC6778]. Participants would like to have the ability to browse and search those archives using standard IMAP clients. This memo captures the requirements for providing a service that would allow such browsing and searching. Discussion of this memo should take place on the ietf@ietf.org mailing list. 2. Requirements for IMAP access to archived IETF lists Many participants would prefer to access the list archives using IMAP [RFC3501]. Providing this access while meeting the following requirements will likely require an IMAP server with specialized capabilities. o The system should expose the archive using an IMAP interface, with each list represented as a mailbox. o This interface must work with standard IMAP clients. o The interface should allow users that have provided credentials to each have their own read/unread marks for messages. Allowing other annotation is desirable. The implementation should consider taking advantage of the IMAP extensions for ANNOTATE [RFC5257] and METADATA [RFC5464]. o The interface must allow administrators to disable setting read/ unread marks and other annotations, and delete any such marks or annotations on a per user basis. o The interface must not allow users to modify the underlying message or metadata other than the read/unread marks and annotations described above. Specifically, users must not be able to delete or insert messages, or move them between mailboxes in the archive. (Clients will, of course, be able to make local copies of messages from the archive.) o The interface must have server-side searching enabled, and should support multiple simultaneous extensive searches. The server should facilitate the enhanced search capabilities described in [RFC6778]. The implementation should consider taking advantage of the extensions defined for IMAP SORT and THREAD [RFC5256], Sparks Expires October 5, 2013 [Page 3] Internet-Draft IMAP Access to IETF Email List Archives Apr 2013 multimailbox search [RFC6237], and fuzzy search [RFC6203]. o When the system requires credentials, it must use the datatracker's authentication system - While the vast majority of archived lists have an open access policy, some archived lists have restricted archives. The system must make it possible to limit access to a restricted archive based on login credentials. - The system must not require credentials for accessing lists with open archives. (But it is acceptable for a user to access such archives while providing credentials). Specifically, the system will allow anonymous access using the SASL ANONYMOUS authentication mechanism [RFC4505] or an LOGIN command with a special username (such as "anonymous") determined by the administrator . 3. Security Considerations Allowing IMAP as an interface for browsing and searching the archives of IETF email lists does not affect the security of the Internet in any significant fashion. Searching can be I/O and CPU intensive. Clients that make local copies all messages in a mailbox can also present an I/O burden, particularly when syncronizing for the first time. The implementors of this interface should consider the potential for maliciously crafted searches attempting to consume all available resources. The implementors should consider the potential for denial of service attacks through making many connections to the interface. The implementors should consider ways to rate limit I/O due to making local copies of messages. Storing read/unread marks and other annotations requires potentially unbounded storage space. The implementors of this interface should consider the potential for maliciously crafted annontations attempting to consume all storage space. The implementers should consider making it easy for the administrator to determine which users are consuming exceptional space. 4. IANA Considerations This document has no actions for IANA. Sparks Expires October 5, 2013 [Page 4] Internet-Draft IMAP Access to IETF Email List Archives Apr 2013 5. Acknowledgements This text was derived directly from an early version of the Internet Draft that became [RFC6778] which incorporated text suggestions from Alexey Melnikov, Pete Resnick, and S. Moonesamy. Barry Leiba suggested several references to IMAP extensions for an implementation to consider. 6. Changelog 6.1. 05 to 06 o Added a requirement making it explicit that this interface won't allow users to delete, insert, or move messages between archives. o Clarified how the would allow access without credentials (at Alexey's suggestion). o Pointed to potential resource abuse issues in the security considerations section. 6.2. 04 to 05 o Adapted text from RFC6778 to make it more clear that both authenticated and unauthenticated access should be supported. 6.3. 03 to 04 o Incorporated suggestions from Pete Resnick and Barry Leiba. 6.4. 02 to 03 o None - expiry refresh 6.5. 01 to 02 o Minor editorial changes 6.6. 00 to 01 o Added requirements to enable controlled access to restricted archives based on credentials o Generalized the requirement to use the datatracker's credentials. Sparks Expires October 5, 2013 [Page 5] Internet-Draft IMAP Access to IETF Email List Archives Apr 2013 6.7. 00 o Split this set of requirements out from the mailarch doc so that this project could be pursued separately 7. Informative References [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. [RFC4505] Zeilenga, K., "Anonymous Simple Authentication and Security Layer (SASL) Mechanism", RFC 4505, June 2006. [RFC5256] Crispin, M. and K. Murchison, "Internet Message Access Protocol - SORT and THREAD Extensions", RFC 5256, June 2008. [RFC5257] Daboo, C. and R. Gellens, "Internet Message Access Protocol - ANNOTATE Extension", RFC 5257, June 2008. [RFC5464] Daboo, C., "The IMAP METADATA Extension", RFC 5464, February 2009. [RFC6203] Sirainen, T., "IMAP4 Extension for Fuzzy Search", RFC 6203, March 2011. [RFC6237] Leiba, B. and A. Melnikov, "IMAP4 Multimailbox SEARCH Extension", RFC 6237, May 2011. [RFC6778] Sparks, R., "Requirements for Archiving IETF Email Lists and for Providing Web-Based Browsing and Searching", RFC 6778, October 2012. Author's Address Robert Sparks Tekelec 17210 Campbell Road Suite 250 Dallas, Texas 75254-4203 USA Email: rjsparks@nostrum.com Sparks Expires October 5, 2013 [Page 6]