RFC 5464
The IMAP METADATA Extension
RFC 5464: The IMAP METADATA Extension ✨
Okay so, the title block is giving RFC 5464 🎀, and it's called "The IMAP METADATA Extension." C. Daboo from Apple, Inc. wrote it, it's dated February 2009, and the category is Standards Track 💅. It doesn't list any RFCs it obsoletes or updates, so nothing gets replaced or patched here 🫶.
Status of This Memo 📜
This is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💖. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈.
Abstract 🦋
The METADATA extension to the Internet Message Access Protocol lets clients and servers keep "annotations" or "metadata" on IMAP servers ✨. You can have annotations on a per-mailbox basis or on the server as a whole. For example, a comment about what a mailbox is for can be "attached" to that mailbox, or there can be a "message of the day" with server status info that anyone logging in can see 🍓.
Table of Contents 🗂️
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Namespace of Entries . . . . . . . . . . . . . . . . . . . 4
3.2.1. Entry Names . . . . . . . . . . . . . . . . . . . . . 5
3.3. Private versus Shared and Access Control . . . . . . . . . 6
4. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 7
4.1. General Considerations . . . . . . . . . . . . . . . . . . 7
4.2. GETMETADATA Command . . . . . . . . . . . . . . . . . . . 8
4.2.1. MAXSIZE GETMETADATA Command Option . . . . . . . . . . 9
4.2.2. DEPTH GETMETADATA Command Option . . . . . . . . . . . 10
4.3. SETMETADATA Command . . . . . . . . . . . . . . . . . . . 10
4.4. METADATA Response . . . . . . . . . . . . . . . . . . . . 12
4.4.1. METADATA Response with Values . . . . . . . . . . . . 13
4.4.2. Unsolicited METADATA Response without Values . . . . . 13
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.1. Entry and Attribute Registration Template . . . . . . . . 16
6.2. Server Entry Registrations . . . . . . . . . . . . . . . . 16
6.2.1. /shared/comment . . . . . . . . . . . . . . . . . . . 17
6.2.2. /shared/admin . . . . . . . . . . . . . . . . . . . . 17
6.3. Mailbox Entry Registrations . . . . . . . . . . . . . . . 17
6.3.1. /shared/comment . . . . . . . . . . . . . . . . . . . 18
6.3.2. /private/comment . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Normative References . . . . . . . . . . . . . . . . . . . . . 19
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 191. Introduction and Overview 🌸
The whole point of METADATA is to give clients a way to set and grab "annotations" or "metadata" on an IMAP server 🧚. Annotations can hang off specific mailboxes or the server as a whole. A server can choose to support only server annotations, or both server and mailbox annotations.
If a server supports both, it shows it has this extension by returning "METADATA" as one of its capabilities in the CAPABILITY command response 💅. If it only does server annotations, it returns "METADATA-SERVER" in that same spot instead ✨.
A server that supports unsolicited annotation change responses MUST support the "ENABLE" [RFC5161] extension so clients can turn that feature on 🔥.
METADATA adds two new commands and one new untagged response to the IMAP base protocol 💖. Here's the full list of what changes:
- adds a new
SETMETADATAcommand - adds a new
GETMETADATAcommand - adds a new
METADATAuntagged response - adds a new
METADATAresponse code
The rest of the doc gets more rigorous about the data model and the protocol changes 🤓.
2. Conventions Used in This Document 💜
In examples, C: and S: mean lines sent by the client and the server, respectively 🫶.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🎀.
Whitespace and line breaks have been added to the examples to make them easier to read 🌈.
3. Data Model 🧚
3.1. Overview 🎀
Mailboxes or the server as a whole can have zero or more annotations attached to them 💖. Each annotation has a uniquely named entry, and that entry has a value ✨. You can add annotations to a mailbox by giving its name as the first argument to SETMETADATA. To hit the server as a whole, you pass the empty string as that first argument instead 🍓.
For example, a general comment on a mailbox might have an entry name of /comment with a value of "Really useful mailbox" 💅.
The protocol changes described below let a client access or change the value of any annotation entry, as long as it has enough access rights 🔐.
3.2. Namespace of Entries 🍓
Each annotation is an entry with a hierarchical name, and the components of that name are separated by a slash ("/") 🌷. An entry name MUST NOT contain two consecutive "/" characters, and it MUST NOT end with a "/" character 🙅♀️.
The value of an entry is NIL (no value), or a string or binary data of zero or more octets 💜. A string MAY contain multiple lines of text. Clients MUST use the CRLF (0x0D 0x0A) octet sequence for line ends in a multi-line string value 🫶.
Entry names MUST NOT contain asterisk ("*") or percent ("%") characters 🚫. They also MUST NOT contain non-ASCII characters or characters with octet values in the range 0x00 to 0x19 🚫. If an entry name is invalid, the server gives a BAD response to any IMAP command that uses it 💀.
Entry names are case-insensitive 🌈. Using control or punctuation characters in entry names is strongly discouraged, so please don't 🙈.
This spec defines an initial set of entry names for mailbox and server annotations. It also describes an extension mechanism so more names can be added later 🦋.
The first component of an entry name defines the scope of the annotation. Right now, only the prefixes /private and /shared are defined ✨. /private means the annotation is stored per user and isn't visible to other users 🔒. /shared means the annotation is shared between authorized users, with a single value that authorized users with the right access can read and change 🤝. See Section 3.3 for the details 👑.
Entry names can have any number of components, starting at 2 🌸. The exception is the vendor namespaces (names with a /shared/vendor/<vendor-token> or /private/vendor/<vendor-token> prefix, as described below). Those MUST... no wait, they have at least 4 components instead 🧩.
3.2.1. Entry Names 💖
Entry names MUST be specified in a Standards Track or IESG-approved Experimental RFC, or fall under the vendor namespace. For the registration template, see Section 6.1 📝.
3.2.1.1. Server Entries 🖥️
These entries are set or retrieved when the mailbox name argument to the new SETMETADATA or GETMETADATA command is the empty string 🫧.
/shared/comment
Defines a comment or note associated with the server, shared with authorized users of the server 💬.
/shared/admin
Indicates a way to contact the server administrator. The value MUST be a URI (e.g., a mailto: or tel: URL) 📮. This entry is always read-only, so clients can't change it 🔒. It's visible to authorized users of the system 👀.
/shared/vendor/<vendor-token>
Defines the top level of shared entries associated with the server, as created by a particular product from some vendor 🏭. Vendors can use this entry to provide server- or client-specific annotations 🎁. The vendor-token MUST be registered with IANA, using the Application Configuration Access Protocol (ACAP) [RFC2244] vendor subtree registry 📚.
/private/vendor/<vendor-token>
Defines the top level of private entries associated with the server, as created by a particular product from some vendor 🏭. Vendors can use this entry to provide server- or client-specific annotations 🎁. The vendor-token MUST be registered with IANA, using the ACAP [RFC2244] vendor subtree registry 📚.
3.2.1.2. Mailbox Entries 📬
These entries are set or retrieved when the mailbox name argument to the new SETMETADATA or GETMETADATA command is not the empty string 💌.
/shared/comment
Defines a shared comment or note associated with a mailbox 💬.
/private/comment
Defines a private (per-user) comment or note associated with a mailbox 🤫.
/shared/vendor/<vendor-token>
Defines the top level of shared entries associated with a specific mailbox, as created by a particular product from some vendor 🏭. Vendors can use this entry to provide client-specific annotations 🎁. The vendor-token MUST be registered with IANA, using the ACAP [RFC2244] vendor subtree registry 📚.
/private/vendor/<vendor-token>
Defines the top level of private entries associated with a specific mailbox, as created by a particular product from some vendor 🏭. Vendors can use this entry to provide client-specific annotations 🎁. The vendor-token MUST be registered with IANA, using the ACAP [RFC2244] vendor subtree registry 📚.
3.3. Private versus Shared and Access Control 🔐
Without the ACL (Access Control List) extension [RFC4314], users can only set and retrieve private or shared mailbox annotations on a mailbox that exists and that they can see through a LIST or LSUB command 👀. They also need read or write access to the actual message content of the mailbox. That's decided by the READ-ONLY and READ-WRITE response codes, as described in Section 5.2 of [RFC4314] ✨.
When the ACL extension [RFC4314] is present, users can only set and retrieve private or shared mailbox annotations on a mailbox where they have the "l" right and any one of the "r", "s", "w", "i", or "p" rights 🎀.
If a client tries to set or retrieve annotations on mailboxes that don't meet the conditions above, the server MUST respond with a NO response 🙅♀️.
Users can always retrieve private or shared server annotations if they exist 🌸. Servers MAY restrict the creation of private or shared server annotations as appropriate 🧱. When that restriction applies, the server MUST return a NO response whenever SETMETADATA is used to try to create a server annotation 🚫.
If the METADATA extension is present, support for shared annotations is REQUIRED, whilst support for private annotations is OPTIONAL 🫶. This is because private annotations can add a lot more complexity to a server, like tracking who owns each annotation and figuring out how quota works for each user's own annotations, etc. 🧠💅
4.1. General Considerations 💅
okay so the new SETMETADATA command and the METADATA response both take a mailbox name argument 🎀 an empty string means server annotations, and a non-empty string means mailbox annotations on that specific mailbox 🦋
Servers SHOULD make sure mailbox annotations move with their mailbox when it gets renamed 🌸 the annotations follow the mailbox, bestie. INBOX is the exception with extra drama: when it's renamed, the annotations are copied from the original INBOX to the new name, so the annotations stay on INBOX itself 👑
Servers SHOULD also delete a mailbox's annotations when that mailbox is deleted 🧹 that way, if someone makes a new mailbox with the same name later, it doesn't inherit the old annotations. no ghost annotations allowed 💀
Servers SHOULD allow annotations on every kind of mailbox, including the ones that report \Noselect in their LIST response 🍓 Servers can implicitly remove a \Noselect mailbox once all of its child mailboxes are gone, and at that moment any annotations on the \Noselect mailbox SHOULD be removed too ✨
Servers are allowed to put limits on how big any one annotation can be, or how many annotations a mailbox (or the whole server) can have 🧁 BUT the server MUST accept an annotation data size of at least 1024 bytes, and an annotation count per server or mailbox of at least 10. that's the floor, no cap 🫶
Some annotations are read-only, which means the server sets them and the client can't change them 🔒 Some are also computed, meaning the value changes based on the mailbox or server's underlying stuff. for example, an annotation with the total size of all messages in a mailbox changes whenever messages get added or removed 📦 and an annotation holding an IMAP URL for a mailbox changes if that mailbox gets renamed 🔗
Servers MAY send unsolicited responses when annotations get changed by a "third-party" (see Section 4.4) 🦋 To do that, servers MUST support the ENABLE command [RFC5161] and MUST only send unsolicited responses if the client turned on the ENABLE [RFC5161] extension with the capability string "METADATA" or "METADATA-SERVER" earlier in the session. which one depends on which of those capabilities the server supports 🧚
4.2. GETMETADATA Command 🔍
this extension adds the GETMETADATA command, and it's how clients grab server or mailbox annotations 🎀
this command is only available in authenticated or selected state [RFC3501] 💜
Arguments: mailbox-name
options
entry-specifier
Responses: required METADATA response
Result: OK - command completed
NO - command failure: can't access annotations on
the server
BAD - command unknown or arguments invalidWhen the mailbox name is the empty string, GETMETADATA goes for server annotations 🖥️ When the mailbox name isn't empty, it goes for annotations on that mailbox 📬
Options MAY be included with this command, and they're defined below 🌈
Example:
C: a GETMETADATA "" /shared/comment
S: * METADATA "" (/shared/comment "Shared comment")
S: a OK GETMETADATA completein this one, the client asks for the value of the "/shared/comment" server entry, and the server sends it right back 💖
Example:
C: a GETMETADATA "INBOX" /private/comment
S: * METADATA "INBOX" (/private/comment "My own comment")
S: a OK GETMETADATA completehere the client wants the value of the "/private/comment" mailbox entry for "INBOX", and the server returns it 🌸
Entry specifiers can be lists of atomic specifiers, so one GETMETADATA command can grab a bunch of annotations at once 🧺
Example:
C: a GETMETADATA "INBOX" (/shared/comment /private/comment)
S: * METADATA "INBOX" (/shared/comment "Shared comment"
/private/comment "My own comment")
S: a OK GETMETADATA completethis is the two-for-one special 🎁 the values of both "/shared/comment" and "/private/comment" on "INBOX" come back in one go ✨
4.2.1. MAXSIZE GETMETADATA Command Option 📏
when you add the MAXSIZE option to GETMETADATA, it filters which entry values come back 🙅♀️ Only entry values with an octet size less than or equal to the MAXSIZE limit get returned. if any requested entries are bigger than the MAXSIZE limit, the server MUST include the METADATA LONGENTRIES response code in the tagged OK response for the GETMETADATA command 🫣 That response code tells you the size of the biggest requested entry value that went over the limit.
Example:
C: a GETMETADATA "INBOX" (MAXSIZE 1024)
(/shared/comment /private/comment)
S: * METADATA "INBOX" (/private/comment "My own comment")
S: a OK [METADATA LONGENTRIES 2199] GETMETADATA completeso here the client asks for both "/shared/comment" and "/private/comment" on "INBOX", but only wants values up to 1024 octets 🙈 The "/shared/comment" value is 2199 octets, so it gets left out, and the LONGENTRIES code in the OK tells the client that 2199 is the size it skipped 💅
4.2.2. DEPTH GETMETADATA Command Option 🌳
the DEPTH option makes GETMETADATA return more entries 🌲 For each entry name in the command, the server returns that entry's value (if it exists) plus every entry below it, up to the DEPTH you asked for. There are three DEPTH values:
"0"- no entries below the specified entry are returned"1"- only entries immediately below the specified entry are returned"infinity"- all entries below the specified entry are returned
so "depth 1" for an entry "/a" matches "/a" plus its kids like "/a/b", but it won't match grandkids like "/a/b/c" 👶➡️🧒 not the vibe for grandchildren 🙅♀️
If the DEPTH option isn't specified, it's the same as writing "DEPTH 0" ✨
Example:
C: a GETMETADATA "INBOX" (DEPTH 1)
(/private/filters/values)
S: * METADATA "INBOX" (/private/filters/values/small
"SMALLER 5000" /private/filters/values/boss
"FROM \"boss@example.com\"")
S: a OK GETMETADATA completein the example above, there are 2 entries below "/private/filters/values" on "INBOX": "/private/filters/values/small" and "/private/filters/values/boss" 🎀
4.3. SETMETADATA Command ✏️
this extension adds the SETMETADATA command, which lets clients set annotations 💕
this command is only available in authenticated or selected state [RFC3501] 🔐
Arguments: mailbox-name
entry
value
list of entry, values
Responses: no specific responses for this command
Result: OK - command completed
NO - command failure: can't set annotations,
or annotation too big or too many
BAD - command unknown or arguments invalidSETMETADATA sets the listed entries by adding or replacing the values you give it 🧁 It works on existing mailboxes named in the mailbox argument, or on the server itself if the mailbox argument is the empty string. Clients can send NIL as the value to remove an entry 🗑️ The server SHOULD NOT send back a METADATA response with the updated annotation data, and clients MUST NOT assume one is coming. what clients MUST assume instead is that if the command succeeds, the annotation has been changed 🫶
If the server can't set an annotation because the value is too big, it MUST send a tagged NO response with a "[METADATA MAXSIZE NNN]" response code, where NNN is the biggest octet count it's willing to accept 📏
If the server can't add a new annotation because it's already hit the maximum number of allowed annotations, it MUST send a tagged NO response with a "[METADATA TOOMANY]" response code 🚫
If the server can't set a new annotation because it doesn't support private annotations on one of the mailboxes you named, it MUST send a tagged NO response with a "[METADATA NOPRIVATE]" response code 🔒
when any single annotation fails and the server sends a tagged NO response, the server MUST NOT change the values of the other annotations in that SETMETADATA command. it's all or nothing, babe 💅
Example:
C: a SETMETADATA INBOX (/private/comment {33}
S: + ready for data
My new comment across
two lines.
)
S: a OK SETMETADATA completehere, the "/private/comment" entry for "INBOX" gets created (if it isn't already there) and set to a multi-line string 📝
Example:
C: a SETMETADATA INBOX (/private/comment NIL)
S: a OK SETMETADATA completein this one, "/private/comment" gets removed from "INBOX" 👋
You can set multiple entries in one SETMETADATA command by listing entry-value pairs in the list 🧺
Example:
C: a SETMETADATA INBOX (/private/comment "My new comment"
/shared/comment "This one is for you!")
S: a OK SETMETADATA completeso "/private/comment" and "/shared/comment" on "INBOX" both get created (if they aren't already there) and set to the values given 💜
Example:
C: a SETMETADATA INBOX (/private/comment "My new comment")
S: a NO [METADATA TOOMANY] SETMETADATA failedthe server can't set this new annotation because it's already at its limit on how many annotations it supports for that mailbox 🥲
4.4. METADATA Response 📨
the METADATA response shows the results of a GETMETADATA command 📋 It can also show up as an unsolicited response whenever the server feels like it, when a server or mailbox annotation changes 🔔
When the ENABLE [RFC5161] command turns on unsolicited responses for this extension, servers MUST send unsolicited METADATA responses whenever a third-party changes server or mailbox annotations, so clients stay up to date 🦋
Unsolicited METADATA responses MUST only contain entry names, not the values 🙅♀️ If the client wants to refresh any cached values, it has to explicitly fetch them with a GETMETADATA command 🔄
A METADATA response can contain multiple entries at once, but the server is free to send several responses, each covering one entry or a group of entries, if it wants 🧚
this response is only available in authenticated or selected state [RFC3501] 🌸
4.4.1. METADATA Response with Values 🎀
okay so the server's reply is basically a list of entry-value pairs, bestie. here's what that looks like 💅
C: a GETMETADATA "" /shared/comment
S: * METADATA "" (/shared/comment "My comment")
S: a OK GETMETADATA completeone entry, one value, served up nicely ✨
C: a GETMETADATA "INBOX" /private/comment /shared/comment
S: * METADATA "INBOX" (/private/comment "My comment"
/shared/comment "Its sunny outside!")
S: a OK GETMETADATA completehere we asked for two entries on INBOX and the server gave us both values back in one list 🧚
C: a GETMETADATA "INBOX" /private/comment /shared/comment
S: * METADATA "INBOX" (/private/comment "My comment")
S: * METADATA "INBOX" (/shared/comment "Its sunny outside!")
S: a OK GETMETADATA completeand this one is giving split responses 🦋 the server sends a separate response for each of the two entries we asked for. same info, different wrapping, iconic 💖
4.4.2. Unsolicited METADATA Response without Values 🔔
so this is the server basically tapping you on the shoulder 🫶 the response is a list of entries that have changed on the server or on a mailbox, and it doesn't include any values.
C: a NOOP
S: * METADATA "" /shared/comment
S: a OK NOOP completethe server is telling you that the /shared/comment server entry changed. bestie just knows 👀
C: a NOOP
S: * METADATA "INBOX" /shared/comment /private/comment
S: a OK NOOP completeand here the server flags two mailbox entries as changed. no values, just a heads up 💅
5. Formal Syntax 🧩
okay the grammar part is where we get really precise 🤓 this spec uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234].
Any non-terminals that are referenced but not defined below are defined by [RFC3501], and the new definitions in [RFC4466] supersede the ones in [RFC3501].
Except where noted otherwise, all alphabetic characters are case-insensitive. Using upper or lower case to write the token strings is just for editorial clarity, not a rule. Implementations MUST accept these strings in a case-insensitive way ✨
capability =/ "METADATA" / "METADATA-SERVER"
; defines the capabilities for this extension.
command-auth =/ setmetadata / getmetadata
; adds to original IMAP command
entries = entry /
"(" entry *(SP entry) ")"
; entry specifiers
entry = astring
; slash-separated path to entry
; MUST NOT contain "*" or "%"
entry-value = entry SP value
entry-values = "(" entry-value *(SP entry-value) ")"
entry-list = entry *(SP entry)
; list of entries used in unsolicited
; METADATA response
getmetadata = "GETMETADATA" [SP getmetadata-options]
SP mailbox SP entries
; empty string for mailbox implies
; server annotation.
getmetadata-options = "(" getmetadata-option
*(SP getmetadata-option) ")"
getmetadata-option = tagged-ext-label [SP tagged-ext-val]
; tagged-ext-label and tagged-ext-val
; are defined in [RFC4466].
maxsize-opt = "MAXSIZE" SP number
; Used as a getmetadata-option
metadata-resp = "METADATA" SP mailbox SP
(entry-values / entry-list)
; empty string for mailbox implies
; server annotation.
response-payload =/ metadata-resp
; adds to original IMAP data responses
resp-text-code =/ "METADATA" SP "LONGENTRIES" SP number
; new response codes for GETMETADATA
resp-text-code =/ "METADATA" SP ("MAXSIZE" SP number /
"TOOMANY" / "NOPRIVATE")
; new response codes for SETMETADATA
; failures
scope-opt = "DEPTH" SP ("0" / "1" / "infinity")
; Used as a getmetadata-option
setmetadata = "SETMETADATA" SP mailbox
SP entry-values
; empty string for mailbox implies
; server annotation.
value = nstring / literal86. IANA Considerations 🌸
time for the registry stuff 📋 every entry MUST have either "/shared" or "/private" as its prefix. Entry names MUST be specified in a Standards Track or IESG-approved Experimental RFC, or they fall under the vendor namespace, which means they use /shared/vendor/<vendor-token> or /private/vendor/<vendor-token> as the prefix.
Every entry registration MUST include a content-type that tells you what kind of annotation value it is. And where that applies, a charset parameter MUST be included with the content-type 💖
6.1. Entry and Attribute Registration Template 📝
To: iana@iana.org
Subject: IMAP METADATA Entry Registration
Type: [Either "Mailbox" or "Server"]
Name: [the name of the entry]
Description: [a description of what the entry is for]
Content-type: [MIME Content-Type and charset for the entry value]
RFC Number: [for entries published as RFCs]
Contact: [email and/or physical address to contact for
additional information]6.2. Server Entry Registrations 🖥️
these templates are the official IANA registrations for the annotation entries this document specifies 🫶
6.2.1. /shared/comment 💬
To: iana@iana.org
Subject: IMAP METADATA Entry Registration
Type: Server
Name: /shared/comment
Description: Defines a comment or note that is associated
with the server and that is shared with
authorized users of the server.
Content-type: text/plain; charset=utf-8
RFC Number: RFC 5464
Contact: IMAP Extensions mailto:ietf-imapext@imc.org6.2.2. /shared/admin 🧑💻
To: iana@iana.org
Subject: IMAP METADATA Entry Registration
Type: Server
Name: /shared/admin
Description: Indicates a method for contacting the server
administrator. The value MUST be a URI (e.g., a
mailto: or tel: URL). This entry is always
read-only -- clients cannot change it. It is visible
to authorized users of the system.
Content-type: text/plain; charset=utf-8
RFC Number: RFC 5464
Contact: IMAP Extensions mailto:ietf-imapext@imc.org6.3. Mailbox Entry Registrations 📮
same deal here: these templates are the IANA registrations for the annotation entries this document specifies, just for mailboxes this time 🦋
6.3.1. /shared/comment 💬
To: iana@iana.org
Subject: IMAP METADATA Entry Registration
Type: Mailbox
Name: /shared/comment
Description: Defines a shared comment or note associated with a
mailbox.
Content-type: text/plain; charset=utf-8
RFC Number: RFC 5464
Contact: IMAP Extensions mailto:ietf-imapext@imc.org6.3.2. /private/comment 🔒
To: iana@iana.org
Subject: IMAP METADATA Entry Registration
Type: Mailbox
Name: /private/comment
Description: Defines a private comment or note associated with a
mailbox.
Content-type: text/plain; charset=utf-8
RFC Number: RFC 5464
Contact: IMAP Extensions mailto:ietf-imapext@imc.org7. Security Considerations 🚨
okay this one is SERIOUS bestie, read it slowly 🙈
the security considerations in Section 11 of [RFC3501] apply here when it comes to keeping annotations safe from snooping. Servers MAY choose to only support the METADATA and/or METADATA-SERVER extensions after the client has negotiated a privacy layer 🔐
annotations can hold arbitrary data of pretty much any size, so servers MUST enforce size limits. otherwise one user could eat up all the space on a server and leave nothing for everyone else 💀 and clients MUST treat annotation data values as an "untrusted" source of data, because they could contain malicious content 🫣
annotations whose values are meant to stay private MUST be stored only in entries that have the "/private" prefix on the entry name 🔒
apart from the issues above, the METADATA extension doesn't raise any security considerations that aren't already in the base IMAP protocol. those are discussed in [RFC3501] 🧚
8. Normative References 📚
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2244] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November 1997.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
RFC 4314, December 2005.
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
ABNF", RFC 4466, April 2006.
[RFC5161] Gulbrandsen, A. and A. Melnikov, "The IMAP ENABLE
Extension", RFC 5161, March 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.Appendix A. Acknowledgments 🙏
the ideas in this document are based on the message annotation document that was co-authored by Randall Gellens. The author would like to thank the following people for contributing their ideas and support for writing this spec: Dave Cridland, Arnt Gulbrandsen, Dan Karp, Alexey Melnikov, Ken Murchison, Chris Newman, and Michael Wener 🫶💜
Author's Address 📮
Cyrus Daboo
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
USA
EMail: cyrus@daboo.name
URI: http://www.apple.com/Full Copyright Statement ©️
the legal bit, but still iconic 💅 this is the copyright notice exactly as written:
Copyright (C) The IETF Trust (2009).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Intellectual Property ✨
Okay bestie, the IETF is staying totally neutral here 🫶 It doesn't take a position on whether any intellectual property rights that someone might claim over the tech in this document are valid, or how far they reach. It also doesn't say whether any license under those rights is available or not. And it hasn't made any independent effort to find out what rights are out there 💅 If you want the rules for rights in RFC documents, check out BCP 78 and BCP 79 🎀
Copies of IPR disclosures sent to the IETF Secretariat are available, along with any assurances of licenses that will be offered. The same goes for the results of any attempt to get a general license or permission for implementers or users to use these proprietary rights. You can find all of that in the IETF online IPR repository at http://www.ietf.org/ipr 🦋
The IETF invites anyone interested to flag any copyrights, patents or patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send it to the IETF at ietf-ipr@ietf.org 📬✨
📦 where this page comes from
- ietf: rfc5464 2009-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms