RFC 7017

IMAP Access to IETF Email List Archives

📅 published August 2013, from ietf

RFC 7017 💖 IMAP Access to IETF Email List Archives 📬

Okay bestie, RFC 7017 is an Informational doc from the IETF 🌸 (so it's published for info, not as a standard). R. Sparks at Oracle wrote it, and it's dated August 2013, ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's standing alone ✨

Abstract ✨

The IETF runs on email lists, and people constantly need to dig back through the archived history of those lists 📚 Everyone wants to browse and search those archives with normal IMAP clients, and this memo lays out the requirements for a service that would make that possible. It's meant as input for whoever designs and builds that service later 🧚

Status of This Memo 🎀

This document is not an Internet Standards Track specification, so it's just published for information 💅

It's a product of the IETF and reflects the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for that bit 🫶

For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7017.

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) as in effect on the date of publication. Please actually read these, because they spell out your rights and restrictions for this document 🙈 Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License.

Table of Contents 📋

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Requirements for IMAP Access to Archived IETF Lists . . . . .   2
3.  Internationalized Address Considerations  . . . . . . . . . .   3
4.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
6.  Informative References  . . . . . . . . . . . . . . . . . . .   4

1. Introduction 🦋

Same story as the abstract, bestie: the IETF uses email lists constantly, so going back through their archives is a whole thing 📮 Requirements for better web-based browsing and searching of those archives are covered in [RFC6778]. This memo is the IMAP side of that, so people can browse and search with standard IMAP clients. It's still just requirements, meant to feed a later design-and-build phase 💜

2. Requirements for IMAP Access to Archived IETF Lists 💅

Lots of participants would rather reach the list archives over IMAP [RFC3501]. Hitting all of the requirements below will probably take an IMAP server with some specialized capabilities 🔥

  • The system should expose the archive through an IMAP interface, with each list showing up as a mailbox.
  • This interface must work with standard IMAP clients.
  • The interface should let each user who has provided credentials keep their own read/unread marks for messages. Allowing other annotations is desirable too. The implementation should consider using the IMAP extensions for ANNOTATE [RFC5257] and METADATA [RFC5464].
  • It must be possible for administrators to set per-user storage quotas, which limit how much space a user can eat up with annotations 💀
  • The interface must not let users change the underlying message or metadata beyond the read/unread marks and annotations described above. So users must not be able to delete or insert messages, or move them between mailboxes in the archive. (Clients can obviously still make local copies of messages from the archive 🍓)
  • The interface must have server-side searching enabled, and it should scale to handle multiple simultaneous extensive searches. The server should provide the enhanced search capabilities described in [RFC6778]. The implementation should consider using the extensions for IMAP SORT and THREAD [RFC5256], multimailbox search [RFC6237], and fuzzy search [RFC6203] ⭐
  • When the system requires credentials, it must use the datatracker's authentication system.
    • Most archived lists have an open access policy, but some 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 credentials. Specifically, the system will allow anonymous access using the Simple Authentication and Security Layer (SASL) ANONYMOUS mechanism [RFC4505], or a LOGIN command with a special username (such as "anonymous") that the administrator picks 🧚

3. Internationalized Address Considerations 🌸

The implementation should be ready for internationalized email addresses, as discussed in [RFC6532], [RFC6531], and [RFC6855]. There isn't a firm requirement on this yet, so it's more of a heads-up than a must 🫶

4. Security Considerations 🔥

Okay, serious moment, but make it cute 🎀 Using IMAP to browse and search IETF list archives doesn't affect the security of the Internet in any significant fashion 💖

Searching can be I/O and CPU intensive. Clients that make local copies of every message in a mailbox can also be an I/O burden, especially on the first sync. Implementors should consider the potential for maliciously crafted searches trying to eat a damaging amount of resources 😭 They should also consider denial-of-service attacks made by opening a ton of connections to the interface. And they should consider ways to rate limit I/O from making local copies of messages 🚦

Storing read/unread marks and other annotations can require potentially unbounded storage space. Implementors should consider the potential for maliciously crafted annotations trying to consume a damaging amount of storage. They should also consider making it easy to alert the administrator when a user starts using exceptional amounts of space 🚨

5. Acknowledgements 🫶

This text came straight from an early draft of what became [RFC6778], which included text suggestions from Alexey Melnikov, Pete Resnick, and S. Moonesamy. Barry Leiba suggested several references to IMAP extensions for implementations to consider. Reviews came from Martin Duerst, Carl Wallace, Wassim Haddad, and Juergen Schoenwaelder. Thank you, legends 👑

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
Oracle
17210 Campbell Road
Suite 250
Dallas, Texas  75254-4203
USA

EMail: rjsparks@nostrum.com
📦 where this page comes from