Network Working Group
Internet Engineering Task Force (IETF)                         R. Sparks
Internet-Draft
Request for Comments: 7017                                       Tekelec
Intended status:
Category: Informational                             July 15,                                      August 2013
Expires: January 16, 2014
ISSN: 2070-1721

                IMAP Access to IETF Email List Archives
                    draft-sparks-genarea-imaparch-08

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, and it is intended as input to a later activity for
   the design and development of such a service.

Status of This Memo

   This Internet-Draft document is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a maximum candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 January 16, 2014.
   http://www.rfc-editor.org/info/rfc7017.

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
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements for IMAP access Access to archived Archived IETF lists Lists . . . . .   2
   3.  Internationalized Address Considerations  . . . . . . . . . .   3
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   7.  Changelog . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     7.1.  06 to 07  . . . . . . . . . . . . . . . . . . . . . . . .   4
     7.2.  05 to 06  . . . . . . . . . . . . . . . . . . . . . . . .   4
     7.3.  04 to 05  . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.4.  03 to 04  . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.5.  02 to 03  . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.6.  01 to 02  . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.7.  00 to 01  . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.8.  00  . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   8.
   6.  Informative References  . . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6   4

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, and it is intended as
   input to a later activity for the design and development of such a
   service.

2.  Requirements for IMAP access Access to archived Archived IETF lists 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  It must be possible for administrators to set per-user storage
      quotas, limiting the space a user can consume with annotations.

   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, enabled and should
      scale to support multiple simultaneous extensive searches.  The
      server should provide the enhanced search capabilities described
      in [RFC6778].  The implementation should consider taking advantage
      of the extensions defined for IMAP SORT and THREAD [RFC5256],
      multimailbox search [RFC6237], and fuzzy search [RFC6203].

   o  When the system requires credentials, it must use the
      datatracker's authentication system 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 allow access to open archives with or
            without providing credentials.  Specifically, the system
            will allow anonymous access using the SASL Simple Authentication
            and Security Layer (SASL) ANONYMOUS
            authentication mechanism [RFC4505] or a
            LOGIN command with a special username (such as "anonymous")
            determined by the administrator.

3.  Internationalized Address Considerations

   The implementation should anticipate internationalized email
   addresses as discussed in the following three documents [RFC6532]
   [RFC6531] documents: [RFC6532],
   [RFC6531], and [RFC6855].  There is no firm requirement at this time.

4.  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 input/output (I/O) and CPU intensive.  Clients that
   make local copies of all messages in a mailbox can also present an I/O I/
   O burden, particularly when syncronizing synchronizing for the first time.  The
   implementors of this interface should consider the potential for
   maliciously crafted searches attempting to consume a damaging amount
   of resources.  The implementors should consider the potential for denial
   of service
   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 annotations attempting
   to consume a damaging amount of storage space.  The
   implementers implementors
   should consider making it easy to alert the administrator when a user
   begins consuming exceptional amounts of space.

5.  IANA Considerations

   This document has no actions for IANA.

6.  Acknowledgements

   This text was derived directly from an early version of the Internet
   Draft document
   that became [RFC6778] [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.  Reviews were provided by Martin Duerst, Carl Wallace,
   Wassim Haddad, and Juergen Schoenwaelder.

7.  Changelog

7.1.  06 to 07

   o  Editorial tweaks and clarifications based on IETF LC reviews.

7.2.  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.

7.3.  04 to 05

   o  Adapted text from RFC6778 to make it more clear that both
      authenticated and unauthenticated access should be supported.

7.4.  03 to 04

   o  Incorporated suggestions from Pete Resnick and Barry Leiba.

7.5.  02 to 03

   o  None - expiry refresh

7.6.  01 to 02

   o  Minor editorial changes

7.7.  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.

7.8.  00

   o  Split this set of requirements out from the mailarch doc so that
      this project could be pursued separately

8.

6.  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.

   [RFC6531]  Yao, J. and W. Mao, "SMTP Extension for Internationalized
              Email", RFC 6531, February 2012.

   [RFC6532]  Yang, A., Steele, S., and N. Freed, "Internationalized
              Email Headers", RFC 6532, February 2012.

   [RFC6778]  Sparks, R., "Requirements for Archiving IETF Email Lists
              and for Providing Web-Based Browsing and Searching", RFC
              6778, October 2012.

   [RFC6855]  Resnick, P., Newman, C., and S. Shen, "IMAP Support for
              UTF-8", RFC 6855, March 2013.

Author's Address

   Robert Sparks
   Tekelec
   17210 Campbell Road
   Suite 250
   Dallas, Texas  75254-4203
   USA

   Email:

   EMail: rjsparks@nostrum.com