RFC 8440

IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST

📅 published August 2018, from ietf

RFC 8440: IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST 🎀

okay bestie, let's talk about RFC 8440! 💖 it's an IMAP Standards Track document from August 2018 by Kenneth Murchison and Bron Gondwana, both at FastMail. it's published as ISSN 2070-1721 and it doesn't obsolete or update anything (no Obsoletes or Updates lines in the header). the whole point is letting clients ask for MYRIGHTS info in the same LIST command ✨

Abstract

This document defines an extension to the IMAP LIST command that lets the client ask for the set of rights the logged-in user has been granted on mailboxes, plus the other stuff LIST normally returns. 🦋

Status of This Memo

okay this part is the paperwork, but it matters 🧚 this is an Internet Standards Track document. it's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. more info on Internet Standards is in Section 2 of RFC 7841.

for the current status, errata, and feedback, check https://www.rfc-editor.org/info/rfc8440 💅

Copyright Notice

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stood on the publication date. read them carefully, bestie, because they explain your rights and restrictions. 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 with no warranty, as the Simplified BSD License describes.

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Conventions Used in This Document . . . . . . . . . . . . . .   2
3.  MYRIGHTS Return Option to LIST Command  . . . . . . . . . . .   2
4.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
5.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .   4
6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   4
8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
  8.1.  Registration of IMAP Capability LIST-MYRIGHTS . . . . . .   4
  8.2.  Registration of LIST-EXTENDED Option MYRIGHTS . . . . . .   4
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
  9.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
  9.2.  Informative References  . . . . . . . . . . . . . . . . .   6
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   6
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1. Introduction ✨

okay so IMAP clients [RFC3501] usually grab the rights on each mailbox so they can show the user what they're allowed to do. the annoying part is they have to run a LIST or LSUB to get every mailbox, and then run a separate MYRIGHTS command for each one they find 😭 this extension adds a "LIST-MYRIGHTS" capability to the LIST command, so the client can get the rights for the logged-in user on mailboxes along with the usual LIST info, all in one go. main character energy 👑

2. Conventions Used in This Document 🫶

in the examples, "C:" marks lines sent by a client connected to a server, and "S:" marks lines the server sends back to the client.

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as BCP 14 [RFC2119] [RFC8174] says, but only when they're in ALL CAPS like shown here 💜

3. MYRIGHTS Return Option to LIST Command 🦋

[RFC4314] defines the MYRIGHTS command. clients use it to figure out the rights the logged-in user has on one mailbox. the thing is, clients usually need to look up rights for a bunch of the mailboxes LIST returns, and doing that with lots of MYRIGHTS commands wastes bandwidth and can slow things down if the client doesn't pipeline the requests 😩

so this document adds a new "MYRIGHTS" return option [RFC5258] to LIST, which lets the client ask for everything it needs in a single command 🔥 for each listable mailbox that matches the list pattern and selection options, the server MUST return an untagged LIST response, and it SHOULD also return an untagged MYRIGHTS response with the set of rights the logged-in user has on that mailbox. the order only matters in one way: the server MUST NOT send a MYRIGHTS response for a mailbox before it sends that mailbox's LIST response 🌈

if the server can't look up the rights for a mailbox, it just doesn't send the MYRIGHTS reply for that one.

heads up, client authors! 🙈 making MYRIGHTS responses for a huge number of mailboxes can be really expensive for the server. clients SHOULD use a good match pattern and/or selection option so they only get the mailboxes whose rights they actually care about.

wait, I need to fix that: the SHOULD above is the one that counts. the sentence reads: Clients SHOULD use a suitable match pattern and/or selection option to limit the set of mailboxes returned to only those in whose rights they are interested. 💅

4. Examples 🧚

in this one, the "bar" mailbox doesn't exist, so there's no MYRIGHTS reply for it 💀

C: A01 LIST "" % RETURN (MYRIGHTS)
S: * LIST () "." "INBOX"
S: * MYRIGHTS "INBOX" lrswipkxtecda
S: * LIST () "." "foo"
S: * MYRIGHTS "foo" lrs
S: * LIST (\NonExistent) "." "bar"
S: A01 OK List completed.

this one's sneaky 👀 the LIST reply for "foo" still comes back because it has matching children, but there's no MYRIGHTS reply for "foo" itself, since "foo" doesn't match the selection criteria.

C: A02 LIST (SUBSCRIBED RECURSIVEMATCH) "" % RETURN (MYRIGHTS)
S: * LIST (\Subscribed) "." "INBOX"
S: * MYRIGHTS "INBOX" lrswipkxtecda
S: * LIST () "." "foo" (CHILDINFO ("SUBSCRIBED"))
S: A02 OK List completed.

5. Formal Syntax 🎀

the grammar here is written in the augmented Backus-Naur Form (BNF) from [RFC5234] 🤓 anything not defined here comes from [RFC5258].

return-option =/ "MYRIGHTS"

6. Security Considerations 🔥

okay bestie, this part is serious 😤 besides the security stuff in [RFC4314], this extension makes it a bit easier for clients to overload the server by asking for MYRIGHTS info on a huge pile of mailboxes. BUT (and this is the tea ☕) existing clients already do this, because they send a ton of MYRIGHTS commands, one for each mailbox they care about. still, when a server is doing MYRIGHTS lookups for big lists of mailboxes, it has to keep serving other IMAP connections and hand execution over to them when it needs to. don't let one greedy connection hog the whole server 🚨

7. Privacy Considerations 🌸

this spec doesn't add any privacy concerns beyond the ones in [RFC4314] 🫧

8. IANA Considerations 💜

8.1. Registration of IMAP Capability LIST-MYRIGHTS

this document defines the "LIST-MYRIGHTS" IMAP capability, which has been added to the "IMAP Capabilities" registry [CAPABILITIES]. 🍓

8.2. Registration of LIST-EXTENDED Option MYRIGHTS

this section registers the "MYRIGHTS" option, which has been added to the "LIST-EXTENDED options" registry [EXTENDED]. here's the full registration:

LIST-EXTENDED option name:  MYRIGHTS

LIST-EXTENDED option type:  RETURN

LIST-EXTENDED option description:  Causes the LIST command to return
   MYRIGHTS responses in addition to LIST responses.

Published specification:  RFC 8440, Section 3

Security considerations:  RFC 8440, Section 6
Intended usage:  COMMON

Person and email address to contact for further information:
   Kenneth Murchison <murch@fastmailteam.com>

Owner/Change controller:  IESG <iesg@ietf.org>

9. References 📚

9.1. Normative References

[CAPABILITIES]
           IANA, "Internet Message Access Protocol (IMAP)
           Capabilities Registry", <https://www.iana.org/assignments/
           imap-capabilities/imap-capabilities>.

[EXTENDED]
           IANA, "Internet Message Access Protocol (IMAP) LIST
           EXTENDED Registry",
           <https://www.iana.org/assignments/imap-list-extended>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
           4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
           <https://www.rfc-editor.org/info/rfc3501>.

[RFC4314]  Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
           RFC 4314, DOI 10.17487/RFC4314, December 2005,
           <https://www.rfc-editor.org/info/rfc4314>.

[RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
           Specifications: ABNF", STD 68, RFC 5234,
           DOI 10.17487/RFC5234, January 2008,
           <https://www.rfc-editor.org/info/rfc5234>.

[RFC5258]  Leiba, B. and A. Melnikov, "Internet Message Access
           Protocol version 4 - LIST Command Extensions", RFC 5258,
           DOI 10.17487/RFC5258, June 2008,
           <https://www.rfc-editor.org/info/rfc5258>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2. Informative References

[RFC5819]  Melnikov, A. and T. Sirainen, "IMAP4 Extension for
           Returning STATUS Information in Extended LIST", RFC 5819,
           DOI 10.17487/RFC5819, March 2010,
           <https://www.rfc-editor.org/info/rfc5819>.

Acknowledgments 🫶

this document is based a lot on [RFC5819]. the authors want to thank that document's authors for the inspiration and for some borrowed text 💖 they also want to thank Barry Leiba for his ideas and support while they were writing this spec.

Authors' Addresses 🌈

Kenneth Murchison
FastMail Pty Ltd.
Level 2, 114 William Street
Melbourne, VIC  3000
Australia

Email: murch@fastmailteam.com


Bron Gondwana
FastMail Pty Ltd.
Level 2, 114 William Street
Melbourne, VIC  3000
Australia

Email: brong@fastmailteam.com

📦 where this page comes from

ietf: rfc8440 2018-08
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms