idnits 2.17.1 draft-sparks-genarea-imaparch-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Apr 3, 2013) is 4041 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 6237 (Obsoleted by RFC 7377) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Sparks 3 Internet-Draft Tekelec 4 Intended status: Informational Apr 3, 2013 5 Expires: October 5, 2013 7 IMAP Access to IETF Email List Archives 8 draft-sparks-genarea-imaparch-06 10 Abstract 12 The IETF makes heavy use of email lists to conduct its work. This 13 often involves accessing the archived history of those email lists. 14 Participants would like to have the ability to browse and search 15 those archives using standard IMAP clients. This memo captures the 16 requirements for providing a service that would allow such browsing 17 and searching. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 5, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements for IMAP access to archived IETF lists . . . . . . 3 55 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 58 6. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 6.1. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 6.2. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 6.3. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 6.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 6.5. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 6.6. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 6.7. 00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 7. Informative References . . . . . . . . . . . . . . . . . . . . 6 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 The IETF makes heavy use of email lists to conduct its work. This 72 often involves accessing the archived history of those email lists. 73 Requirements for improved web-based browsing and searching of these 74 archives are captured in [RFC6778]. Participants would like to have 75 the ability to browse and search those archives using standard IMAP 76 clients. This memo captures the requirements for providing a service 77 that would allow such browsing and searching. 79 Discussion of this memo should take place on the ietf@ietf.org 80 mailing list. 82 2. Requirements for IMAP access to archived IETF lists 84 Many participants would prefer to access the list archives using IMAP 85 [RFC3501]. Providing this access while meeting the following 86 requirements will likely require an IMAP server with specialized 87 capabilities. 89 o The system should expose the archive using an IMAP interface, with 90 each list represented as a mailbox. 92 o This interface must work with standard IMAP clients. 94 o The interface should allow users that have provided credentials to 95 each have their own read/unread marks for messages. Allowing 96 other annotation is desirable. The implementation should consider 97 taking advantage of the IMAP extensions for ANNOTATE [RFC5257] and 98 METADATA [RFC5464]. 100 o The interface must allow administrators to disable setting read/ 101 unread marks and other annotations, and delete any such marks or 102 annotations on a per user basis. 104 o The interface must not allow users to modify the underlying 105 message or metadata other than the read/unread marks and 106 annotations described above. Specifically, users must not be able 107 to delete or insert messages, or move them between mailboxes in 108 the archive. (Clients will, of course, be able to make local 109 copies of messages from the archive.) 111 o The interface must have server-side searching enabled, and should 112 support multiple simultaneous extensive searches. The server 113 should facilitate the enhanced search capabilities described in 114 [RFC6778]. The implementation should consider taking advantage of 115 the extensions defined for IMAP SORT and THREAD [RFC5256], 116 multimailbox search [RFC6237], and fuzzy search [RFC6203]. 118 o When the system requires credentials, it must use the 119 datatracker's authentication system 121 - While the vast majority of archived lists have an open access 122 policy, some archived lists have restricted archives. The 123 system must make it possible to limit access to a restricted 124 archive based on login credentials. 126 - The system must not require credentials for accessing lists 127 with open archives. (But it is acceptable for a user to access 128 such archives while providing credentials). Specifically, the 129 system will allow anonymous access using the SASL ANONYMOUS 130 authentication mechanism [RFC4505] or an LOGIN command with a 131 special username (such as "anonymous") determined by the 132 administrator . 134 3. Security Considerations 136 Allowing IMAP as an interface for browsing and searching the archives 137 of IETF email lists does not affect the security of the Internet in 138 any significant fashion. 140 Searching can be I/O and CPU intensive. Clients that make local 141 copies all messages in a mailbox can also present an I/O burden, 142 particularly when syncronizing for the first time. The implementors 143 of this interface should consider the potential for maliciously 144 crafted searches attempting to consume all available resources. The 145 implementors should consider the potential for denial of service 146 attacks through making many connections to the interface. The 147 implementors should consider ways to rate limit I/O due to making 148 local copies of messages. 150 Storing read/unread marks and other annotations requires potentially 151 unbounded storage space. The implementors of this interface should 152 consider the potential for maliciously crafted annontations 153 attempting to consume all storage space. The implementers should 154 consider making it easy for the administrator to determine which 155 users are consuming exceptional space. 157 4. IANA Considerations 159 This document has no actions for IANA. 161 5. Acknowledgements 163 This text was derived directly from an early version of the Internet 164 Draft that became [RFC6778] which incorporated text suggestions from 165 Alexey Melnikov, Pete Resnick, and S. Moonesamy. Barry Leiba 166 suggested several references to IMAP extensions for an implementation 167 to consider. 169 6. Changelog 171 6.1. 05 to 06 173 o Added a requirement making it explicit that this interface won't 174 allow users to delete, insert, or move messages between archives. 176 o Clarified how the would allow access without credentials (at 177 Alexey's suggestion). 179 o Pointed to potential resource abuse issues in the security 180 considerations section. 182 6.2. 04 to 05 184 o Adapted text from RFC6778 to make it more clear that both 185 authenticated and unauthenticated access should be supported. 187 6.3. 03 to 04 189 o Incorporated suggestions from Pete Resnick and Barry Leiba. 191 6.4. 02 to 03 193 o None - expiry refresh 195 6.5. 01 to 02 197 o Minor editorial changes 199 6.6. 00 to 01 201 o Added requirements to enable controlled access to restricted 202 archives based on credentials 204 o Generalized the requirement to use the datatracker's credentials. 206 6.7. 00 208 o Split this set of requirements out from the mailarch doc so that 209 this project could be pursued separately 211 7. Informative References 213 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 214 4rev1", RFC 3501, March 2003. 216 [RFC4505] Zeilenga, K., "Anonymous Simple Authentication and 217 Security Layer (SASL) Mechanism", RFC 4505, June 2006. 219 [RFC5256] Crispin, M. and K. Murchison, "Internet Message Access 220 Protocol - SORT and THREAD Extensions", RFC 5256, 221 June 2008. 223 [RFC5257] Daboo, C. and R. Gellens, "Internet Message Access 224 Protocol - ANNOTATE Extension", RFC 5257, June 2008. 226 [RFC5464] Daboo, C., "The IMAP METADATA Extension", RFC 5464, 227 February 2009. 229 [RFC6203] Sirainen, T., "IMAP4 Extension for Fuzzy Search", 230 RFC 6203, March 2011. 232 [RFC6237] Leiba, B. and A. Melnikov, "IMAP4 Multimailbox SEARCH 233 Extension", RFC 6237, May 2011. 235 [RFC6778] Sparks, R., "Requirements for Archiving IETF Email Lists 236 and for Providing Web-Based Browsing and Searching", 237 RFC 6778, October 2012. 239 Author's Address 241 Robert Sparks 242 Tekelec 243 17210 Campbell Road 244 Suite 250 245 Dallas, Texas 75254-4203 246 USA 248 Email: rjsparks@nostrum.com