RFC 9979
Registration of Further IMAP/JMAP Keywords and Mailbox Name Attributes
RFC 9979: Registration of Further IMAP/JMAP Keywords and Mailbox Name Attributes 💖
Okay bestie, this is RFC 9979 🎀 It's the IETF's big "hey, don't use these names for something else" list for email keywords and mailbox attributes. It's part 1 of 4, so more is coming!
The title block tea ☕
- Authors: N. Jenkins (Fastmail) and D. Eggert (Apple, Inc)
- Category: Informational, so it's published for info and isn't a Standards Track spec 📚
- Date: May 2026
- ISSN: 2070-1721
- Stream: Internet Engineering Task Force (IETF)
- Obsoletes / Updates: the header doesn't list any, so this one doesn't obsolete or update anything else 🙌
Abstract ✨
So this doc defines a bunch of keywords and mailbox name attributes that servers and clients have already been using in the wild 🌸 It explains what each one is meant for, and then it registers all of them with IANA so nobody accidentally steps on anyone else's names. Iconic, honestly.
Status of This Memo 📝
Let's get the official stuff out of the way 🙈 This doc is not an Internet Standards Track specification. It's published for informational purposes, period.
It's still a product of the IETF, and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not everything the IESG approves is a candidate for any level of Internet Standard, though. See Section 2 of RFC 7841 for the deets.
If you want the current status, any errata, or a way to send feedback, head to https://www.rfc-editor.org/info/rfc9979 💌
Copyright Notice ©️
Copyright (c) 2026 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 (https://trustee.ietf.org/license-info) as they're in effect on the date of publication. Please read those carefully, because they spell out your rights and restrictions for this document 📜 Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Revised BSD License.
Table of Contents 🗺️
1. Introduction
2. Requirements Language
3. Flag Color Keywords
3.1. Definition of the $MailFlagBit_ Message Keywords
3.2. Implementation Notes
4. Attachment Detection Keywords
4.1. $hasattachment
4.2. $hasnoattachment
5. Memos Keywords
5.1. $hasmemo
5.2. $memo
6. Subscription Management Keywords
6.1. $canunsubscribe
6.2. $unsubscribed
7. Other Message Keywords
7.1. $autosent
7.2. $followed
7.3. $imported
7.4. $istrusted
7.5. $maskedemail
7.6. $muted
7.7. $new
7.8. $notify
8. Mailbox Name Attributes
8.1. Snoozed
8.2. Scheduled
8.3. Memos
9. IANA Considerations
9.1. IMAP/JMAP Keyword Registrations
9.1.1. $autosent Keyword Registration
9.1.2. $canunsubscribe Keyword Registration
9.1.3. $followed Keyword Registration
9.1.4. $hasattachment Keyword Registration
9.1.5. $hasmemo Keyword Registration
9.1.6. $hasnoattachment Keyword Registration
9.1.7. $imported Keyword Registration
9.1.8. $istrusted Keyword Registration
9.1.9. $MailFlagBit0 Keyword Registration
9.1.10. $MailFlagBit1 Keyword Registration
9.1.11. $MailFlagBit2 Keyword Registration
9.1.12. $maskedemail Keyword Registration
9.1.13. $memo Keyword Registration
9.1.14. $muted Keyword Registration
9.1.15. $new Keyword Registration
9.1.16. $notify Keyword Registration
9.1.17. $unsubscribed Keyword Registration
9.2. IMAP Mailbox Name Attributes Registrations
9.2.1. Snoozed Mailbox Name Attribute Registration
9.2.2. Scheduled Mailbox Name Attribute Registration
9.2.3. Memos Mailbox Name Attribute Registration
10. Security Considerations
11. Normative References
Authors' Addresses1. Introduction 🦋
Okay so the IMAP spec [RFC9051] is where message keywords get defined, and [RFC5788] is where the "IMAP and JMAP Keywords" registry gets created. Similarly, [RFC8457] sets up the "IMAP Mailbox Name Attributes" registry. Then [RFC8621] updates these registries so they cover messages and mailboxes over JMAP too. Main character registry energy 👑
This doc defines 17 message keywords 💅
$autosent$canunsubscribe$followed$hasattachment$hasmemo$hasnoattachment$imported$istrusted$MailFlagBit0$MailFlagBit1$MailFlagBit2$maskedemail$memo$muted$new$notify$unsubscribed
It also defines three mailbox name attributes 📬
- Memos
- Scheduled
- Snoozed
And this doc registers all of them in the "IMAP and JMAP Keywords" registry and the "IMAP Mailbox Name Attributes" registry. Registration era 🫶
2. Requirements Language 📖
Real talk, this is the boring-but-important bit 🤓 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 described in BCP 14 [RFC2119] [RFC8174]. They only count when they show up in ALL CAPS, just like here.
3. Flag Color Keywords 🌈
The IMAP spec [RFC9051] has a \Flagged system flag that marks a message as urgent or in need of special attention 🚩 The new keywords from Section 3.1 let that flagged message come in one of seven colors. Ooh, pretty.
3.1. Definition of the $MailFlagBit_ Message Keywords 🎨
The three flag color keywords:
$MailFlagBit0$MailFlagBit1$MailFlagBit2
work together as a bit pattern that decides the flag's color, like this:
+=======+=======+=======+========+
| Bit 0 | Bit 1 | Bit 2 | Color |
+=======+=======+=======+========+
| 0 | 0 | 0 | red |
+-------+-------+-------+--------+
| 1 | 0 | 0 | orange |
+-------+-------+-------+--------+
| 0 | 1 | 0 | yellow |
+-------+-------+-------+--------+
| 1 | 1 | 0 | green |
+-------+-------+-------+--------+
| 0 | 0 | 1 | blue |
+-------+-------+-------+--------+
| 1 | 0 | 1 | purple |
+-------+-------+-------+--------+
| 0 | 1 | 1 | gray |
+-------+-------+-------+--------+
Table 1: Flag ColorsNote that the bit combination 111 (all three bits set) doesn't get a color. So you end up with seven distinct flag colors instead of eight possible combos 🙃
Now the rules 🚨 These flags MUST be ignored if the \Flagged system flag isn't set. If \Flagged is set, the flagged status MAY be presented to the user in the color that matches the combo of the three flag color keywords.
3.2. Implementation Notes 🛠️
Okay, client devs, listen up 👂 A mail client that knows about these flag color keywords MUST clear all three of them when the user unflags the message. That means when \Flagged gets cleared, all three flag color keywords MUST also be cleared.
A mail client MUST NOT set any of these flags unless \Flagged is already set or is being set right now.
Servers MAY clear these flag color keywords when a client clears the \Flagged system flag.
Also, since these keywords are all about colors, clients SHOULD provide alternatives for users who can't perceive colors 🫶 That could be different shapes, patterns, text labels, audio cues, or other distinguishing traits that carry the same meaning as the color differences. The specific bit patterns can work as identifiers for those alternative representations.
4. Attachment Detection Keywords 📎
These keywords help clients figure out whether a message has attachments without having to fetch and parse the whole message structure ⚡ They're super handy for showing attachment indicators in message lists or for attachment-based filtering.
The $hasattachment and $hasnoattachment keywords are mutually exclusive. A message MUST NOT have both of them set at the same time 🚫
4.1. $hasattachment 📎
The $hasattachment keyword says that a message has one or more attachments. The server sets it during message delivery. Otherwise, the client sets it, but only if neither $hasattachment nor $hasnoattachment is currently set.
This lets clients show attachment indicators (like paperclip icons) in message lists without fetching the full MIME structure for every single message. It also makes attachment-based filtering and search work better 🔍
When using JMAP, the hasAttachment Email property MUST reflect the same information as this keyword, so everything stays consistent across protocols 🫶
4.2. $hasnoattachment 🙅
The $hasnoattachment keyword explicitly says that a message does not have any attachments. The server sets it during message delivery. Otherwise, the client sets it, but only if neither $hasattachment nor $hasnoattachment is currently set.
This one complements $hasattachment by giving definitive info about messages that have been analyzed and found to have no attachments 💡 Just not having $hasattachment doesn't tell you much, since the message might simply not have been checked for attachments yet.
That explicit distinction matters for clients that need to know whether attachment detection has actually been done on a message. When using JMAP, the hasAttachment Email property MUST reflect the same information as this keyword.
5. Memos Keywords 📝
These keywords support user-made annotations, or memos, attached to messages. They let contextual notes get added to conversations while keeping proper cross-references between messages and their annotations 💜
Here's how the pair works: the $memo keyword goes on the memo message itself (the note-to-self), and the $hasmemo keyword goes on the original message being annotated. That makes a two-way relationship, so clients can quickly find memos and the messages they belong to 🔁
The $memo and $hasmemo keywords are mutually exclusive. A message MUST NOT have both of them set at once 🙅♀️
5.1. $hasmemo 🧚
The $hasmemo keyword says that a message has an associated memo (the one identified by the $memo keyword) in the same thread. Clients can use it to spot messages with annotations without checking every message in a thread 👀
When a client creates a memo for a message, it MUST add this keyword to the message being annotated, and it MUST ALSO add the $memo keyword to the memo message itself. Going the other way, when a memo gets deleted, the client MUST remove this keyword from the annotated message.
This keyword opens up a few optimizations for clients. It makes searching for annotated messages faster, lets message lists show which messages have memos, and helps clients decide whether to fetch whole conversation threads when loading a mailbox, so the memos get shown properly 🍓
5.2. $memo 📝
okay so $memo is the keyword for a note-to-self the user writes about another message in the same thread 🫶 It's giving contextual annotations on conversations, and I'm obsessed.
Messages with this keyword should be built kind of like a reply to the message being annotated, with the right Subject and Reply-To headers so everything stays in context and threads together 🧵 Servers SHOULD store these messages in a mailbox with the "Memos" mailbox name attribute (see Section 9.2.3), if that's available 📂
Supporting clients MUST present these messages differently from regular emails 💅 They're not standalone messages. They MUST be presented as annotations attached to the message they're commenting on. Clients can have special UI for editing or deleting memos, which usually means replacing the message, since email messages are immutable 🙈
When a client creates or removes a memo, it MUST also set or clear the related $hasmemo keyword on the message being annotated, so the cross-referencing stays accurate 🔗✨
6. Subscription Management Keywords 📬
these keywords help clients manage mailing list subscriptions 💌 They help track unsubscription attempts and spot messages that have a valid unsubscribe option. Main character energy for your inbox 👑
6.1. $canunsubscribe 🚪
$canunsubscribe means a message has a valid List-Unsubscribe header that's compliant with [RFC8058], so clients can offer one-click unsubscribe 🖱️✨
The server sets this during delivery when it detects a valid List-Unsubscribe header and the message passes implementation-specific reputation checks. This pre-verification matters because not every List-Unsubscribe header is trustworthy 😭 Some can lead to phishing sites or generate extra spam, so it's not a vibe to just trust them blindly 🚩
The big win here is efficiency 🏃♀️ Clients can decide whether to show an unsubscribe option in the UI without fetching and validating the List-Unsubscribe header for every single message. It's also an extra layer of safety, since the server has already done reputation checks on the unsubscribe mechanism 🛡️
6.2. $unsubscribed 🫠
$unsubscribed means the user has tried to unsubscribe from the mailing list tied to a message 🙅♀️ It's a persistent record of unsubscription attempts across multiple clients, so nobody has to re-live that moment 💀
A client sets this after a user attempts to unsubscribe from a mailing list, usually with a one-click List-Unsubscribe action as defined in [RFC8058] 🖱️ It's a record that an attempt was made, even if no confirmation of a successful unsubscription has come back yet. It MUST NOT be set if the unsubscription attempt definitely failed ❌
Supporting clients can use this to show an indicator on messages with this keyword, reminding the user they already tried to unsubscribe from this sender or mailing list 🔔 This is super helpful when users revisit old messages and might otherwise try to unsubscribe again, or when they keep getting messages even after unsubscribing and need to take further action 😤
7. Other Message Keywords 🌈
7.1. $autosent 🤖
$autosent identifies messages that were automatically generated and sent by the system on the user's behalf, usually because of user-defined filtering rules or settings 🪄
The server sets this on the user's copy of vacation auto-replies, automated responses, or other system-generated messages sent for the user 📨 It lets clients clearly tell these apart from messages the user actually wrote and sent themselves.
Supporting clients can show these messages differently in the \Sent mailbox, like with a distinct indicator (an icon or label) that says they're automated 🏷️ This helps stop user confusion when they find a message they don't remember writing, especially with vacation responses or other automated replies that got configured and then forgotten 🫣
7.2. $followed 🔔
$followed means a user is especially interested in future messages in a specific thread 👀 It turns on special handling so these messages get the attention they deserve 💖
When a new message arrives in a thread with this keyword, supporting servers MAY take actions to prioritize it ✨ That could mean making sure it lands in the inbox no matter what filtering rules might otherwise do to it, automatically adding $notify so the user gets notifications, or applying other handling that boosts its prominence 📈 The exact actions, and whether the user can configure them, depend on the implementation 🧚
Thread identification for this keyword follows the same definition as described in Section 7.6 🧵
Clients set or clear this keyword based on user actions to follow or unfollow a thread 🎀 When unfollowing a thread, clients MUST remove this keyword from all messages in the thread that have it 🧹 The $followed keyword is mutually exclusive with the $muted keyword. If both are present on messages in the same thread, servers MUST treat the thread as followed rather than muted 💜
7.3. $imported 📦
$imported identifies messages that were imported into the mailbox from another system, rather than arriving through normal mail delivery channels 🧳
The server sets this during import operations from other mail systems, data migrations, or manual imports from local files 🗂️ It helps tell apart messages that didn't come through normal delivery, which might have different characteristics or behaviours 🤔
Supporting clients can show an indicator for imported messages, especially if they have weird properties like unexpectedly old dates, unusual header structures, or other anomalies that could confuse users 🙃 Some clients might also offer filtering or search just for imported messages 🔍
7.4. $istrusted ✅
$istrusted means a message's sender identity has been verified by the server with a high degree of confidence 🪪 It's a sign that the message is likely authentic 💫
This advisory keyword is set by the server during delivery when both the sender's name and email address can be verified with a high degree of confidence 🔐 This level of verification usually applies to messages the mailbox provider sends to its own customers, where the provider has strong evidence of where the message came from 📮
Supporting clients can show a verification indicator (like a check mark icon) on messages with this keyword, helping users spot legit messages from their service provider ✔️ This matters a LOT for telling authentic provider messages apart from phishing attempts that pretend to be the provider 😱
Servers MUST exercise caution when applying this keyword, because it hands trust to the user. If it's misapplied, it could lead users to trust fraudulent messages. Be careful, bestie 🚨
It MUST NOT be used for messages that have only passed standard authentication mechanisms like Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), or Domain-based Message Authentication, Reporting, and Conformance (DMARC) 🙅♀️ Passing those alone is not enough, no cap.
7.5. $maskedemail 🎭
$maskedemail means a message was received through a masked email address, which is an alias made specifically for communicating with a particular sender to protect the user's primary email address 🦹♀️
This advisory keyword is set by the server during delivery on messages that arrive through such aliases 📬 These might be automatically generated single-use addresses, service-specific addresses, or user-created aliases for specific correspondents 🪞
Supporting clients can show an indicator (like a mask icon) on messages with this keyword 😷 It helps users understand the message came through a privacy-enhancing alias instead of their primary address 🔒 Clients might also offer related features, like disabling the specific alias if it starts getting unwanted messages 🚫
7.6. $muted 🔇
$muted lets users say they're not interested in future messages in a particular conversation thread 🙉 It enables automated processing of later messages in that thread so they don't take up as much prominence 🫥
When a new message arrives that belongs to the same thread as one marked with this keyword, supporting servers MAY automatically deprioritise it 📉 This could mean moving it to an archive or trash folder, marking it as read, or applying other handling that reduces its prominence 🗑️ The specific actions, and whether the user can configure them, depend on the implementation 🧩
For thread identification, messages are considered part of the same thread when they share the same thread identifier as defined in Section 5.2 of [RFC8474] for IMAP, or Section 3 of [RFC8621] for JMAP 🆔 This definition applies to all thread-related keywords in this document 📖
This keyword is set or cleared by clients based on user actions to mute or unmute a thread 🎚️ When unmuting a thread, clients MUST remove this keyword from all messages in the thread that have it 🧽 The $muted keyword is mutually exclusive with the $followed keyword. If both are present on messages in the same thread, both servers and clients MUST treat the thread as followed rather than muted 💅
Implementers should note the security considerations in the IANA registration 🔐 If an attacker gains access to a user's account, they could mute threads to hide important communications 😨 However, this is only a small increase in risk, since compromised accounts already allow lots of other similar actions 🤷♀️
7.7. $new ✨
$new means a message should be emphasised or made more prominent to the user because of a recent system action, even if the message itself isn't new 🌟
This advisory keyword is typically set by servers when a previously snoozed message "awakens" and returns to the inbox after its snooze period has passed ⏰ It tells clients that, even though the message might have an older date, it should be treated as effectively new when it comes to user attention 👀
Supporting clients can show these messages with special treatment to grab the user's attention, like emphasising or bolding them, or placing them at the top of the message list 🎉 This works even if strict date sorting would put them somewhere else 🫠
Clients MUST clear this keyword when the user interacts with the message, like by opening, replying to, or otherwise acknowledging it 🧹 That way the message doesn't stay glowing forever after the user has already seen it 💖
7.8. $notify 🔔
okay so $notify is basically the keyword that says "hey, this one actually matters, tell the user" 🫶. Instead of pinging for literally every email that lands in the inbox (chaotic, no thank u 💀), it lets people and servers flag the specific messages that deserve attention ✨.
When a message with this keyword gets delivered to a mailstore, supporting clients SHOULD show the user a notification, unless the user has set things up differently 🌸. That notification can show up alongside other message notifications, depending on the user's preferences.
This is giving both users (through filtering rules) and servers (through automated processing) a way to spot messages that are worth attention 👀. Even if a message would otherwise get filtered or sorted somewhere quiet, $notify makes sure it can still break through 🔥.
Servers usually set this keyword during delivery when a message meets certain criteria that show it's important to the user 💜. Clients may clear the keyword when the user interacts with the message, like opening it, archiving it, or doing other stuff with it 🧚. When one client clears this keyword, other clients connected to the same account may choose to automatically dismiss their matching notification 💅.
8. Mailbox Name Attributes 📬
8.1. Snoozed
The Snoozed mailbox name attribute identifies a mailbox that stores messages which have been temporarily taken off the user's radar and scheduled to come back later 😴⏰.
When a user "snoozes" a message, the supporting server moves it into a mailbox with this attribute 🛌. At the scheduled "awaken" time, the server automatically moves the message back to where it came from (usually the inbox) and may mark it with $new so it gets proper attention 🌅.
This attribute gives snoozed messages a standard location across clients, so everyone can find and manage them consistently 🗂️. Just know that it only identifies where snoozed messages are stored. It doesn't define the snoozing mechanism or the interface for it 🙈.
Supporting clients may show this mailbox's contents differently from regular mailboxes 🎀. For example, they might sort messages by their scheduled "awaken" time instead of received date, or give users a special way to change how long a snooze lasts ⏳.
8.2. Scheduled
The Scheduled mailbox name attribute identifies a mailbox that holds messages which have been written but are set to send at a later time instead of right away 📅✈️.
When a user writes a message and picks a later date or time to send it, the supporting server keeps it in a mailbox with this attribute until that scheduled time 🕰️. Once the time arrives, the server sends the message and usually moves it to the \Sent mailbox, or deletes it, depending on server policy 📤.
This attribute gives scheduled messages a standard location across clients 🌈. That means users can review, edit, or cancel them before they go out, no matter which client was used to schedule them 💖.
Supporting clients may show this mailbox's contents in a way that highlights the scheduled send time and lets users change or cancel messages before they're sent 🫧.
8.3. Memos
The Memos mailbox name attribute identifies a mailbox meant for storing messages that have the $memo keyword 📝🍓. These are user-written notes or annotations about other messages.
When a user creates a memo (a note-to-self about another message), clients SHOULD store it in a mailbox with this attribute 💜. This keeps memos separate, so clients can treat them as annotations instead of standalone conversations 🧠.
Keeping memos in their own mailbox helps stop them from cluttering the inbox or other folders 🧹. They still count as proper email messages, though, so they stay compatible and sync like everything else 🔄.
Supporting clients MUST NOT present this mailbox's contents as regular messages in their interface. Instead, they MUST show memos in context, right next to the messages they annotate whenever those messages are opened 🫶🔍.
9. IANA Considerations 🧾
The following 17 IMAP/JMAP keywords have been registered in the "IMAP and JMAP Keywords" registry, as established in [RFC5788] 🎉.
9.1. IMAP/JMAP Keyword Registrations
9.1.1. $autosent Keyword Registration
Here's the $autosent registration 💌:
IMAP/JMAP keyword name: $autosent
Purpose: Indicate to the client that a message was sent
automatically as a response due to a user rule or setting.
Private or Shared on a server: SHARED
Is it an advisory keyword or may it cause an automatic action: This
keyword is advisory.
When/by whom the keyword is set/cleared: This keyword is set by the
server on delivery.
Related keywords: None
Related IMAP capabilities: None
Security considerations: None
Published specification: RFC 9979
Intended usage: COMMON
Scope: BOTH
Owner/Change controller: IESG9.1.2. $canunsubscribe Keyword Registration
Next up is $canunsubscribe 🫧:
IMAP/JMAP keyword name: $canunsubscribe
Purpose: Indicate to the client that this message has a List-
Unsubscribe header that is compliant with [RFC8058].
Private or Shared on a server: SHARED
Is it an advisory keyword or may it cause an automatic action: This
keyword is advisory.
When/by whom the keyword is set/cleared: This keyword is set by the
server on delivery.
Related keywords: None
Related IMAP capabilities: None
Security considerations: None
Published specification: RFC 9979
Intended usage: COMMON
Scope: BOTH
Owner/Change controller: IESG9.1.3. $followed Keyword Registration
Here's $followed 🧵💖:
IMAP/JMAP keyword name: $followed
Purpose: Indicate to the server that the user is particularly
interested in future replies to a particular thread.
Private or Shared on a server: SHARED
Is it an advisory keyword or may it cause an automatic action: This
keyword can cause automatic action.
When/by whom the keyword is set/cleared: This keyword is set and
cleared by the client.
Related keywords: Mutually exclusive with $muted. If both are
specified on a thread, servers MUST behave as though only
$followed were set.
Related IMAP capabilities: None
Security considerations: None
Published specification: RFC 9979
Intended usage: COMMON
Scope: BOTH
Owner/Change controller: IESG9.1.4. $hasattachment Keyword Registration
Now $hasattachment 📎:
IMAP/JMAP keyword name: $hasattachment
Purpose: Indicate to the client that a message has an attachment.
Private or Shared on a server: SHARED
Is it an advisory keyword or may it cause an automatic action: This
keyword is advisory.
When/by whom the keyword is set/cleared: It is set by the server
during message delivery; otherwise, it is set by the client (if
neither $hasattachment nor $hasnoattachment is currently set).
Related keywords: Mutually exclusive with $hasnoattachment
Related IMAP capabilities: None
Security considerations: None
Published specification: RFC 9979
Intended usage: COMMON
Scope: BOTH
Owner/Change controller: IESG9.1.5. $hasmemo Keyword Registration
Here's $hasmemo 📝:
IMAP/JMAP keyword name: $hasmemo
Purpose: Indicate to the client that a message has an associated
memo with the $memo keyword.
Private or Shared on a server: SHARED
Is it an advisory keyword or may it cause an automatic action: This
keyword is advisory.
When/by whom the keyword is set/cleared: This keyword is set and
cleared by the client based on user interaction.
Related keywords: The $memo and $hasmemo keywords are mutually
exclusive.
Related IMAP capabilities: None
Security considerations: None
Published specification: RFC 9979
Intended usage: COMMON
Scope: BOTH
Owner/Change controller: IESG9.1.6. $hasnoattachment Keyword Registration
Next is $hasnoattachment 🙅♀️:
IMAP/JMAP keyword name: $hasnoattachment
Purpose: Indicate to the client that a message does not have an
attachment.
Private or Shared on a server: SHARED
Is it an advisory keyword or may it cause an automatic action: This
keyword is advisory.
When/by whom the keyword is set/cleared: It is set by the server
during message delivery; otherwise, it is set by the client (if
neither $hasattachment nor $hasnoattachment is currently set).
Related keywords: Mutually exclusive with $hasattachment
Related IMAP capabilities: None
Security considerations: None
Published specification: RFC 9979
Intended usage: COMMON
Scope: BOTH
Owner/Change controller: IESG9.1.7. $imported Keyword Registration
Here's $imported 📥:
IMAP/JMAP keyword name: $imported
Purpose: Indicate to the client that this message was imported from
another mailbox.
Private or Shared on a server: SHARED
Is it an advisory keyword or may it cause an automatic action: This
keyword is advisory.
When/by whom the keyword is set/cleared: This keyword is set by the
server on delivery.
Related keywords: None
Related IMAP capabilities: None
Security considerations: None
Published specification: RFC 9979
Intended usage: COMMON
Scope: BOTH
Owner/Change controller: IESG9.1.8. $istrusted Keyword Registration
Now $istrusted 🛡️✨:
IMAP/JMAP keyword name: $istrusted
Purpose: Indicate to the client that the authenticity of the from
name and email address have been verified by the server.
Private or Shared on a server: SHARED
Is it an advisory keyword or may it cause an automatic action: This
keyword is advisory.
When/by whom the keyword is set/cleared: This keyword is set by the
server on delivery.
Related keywords: None
Related IMAP capabilities: None
Security considerations: Servers should make sure this keyword is
only set for messages that really are trusted.
Published specification: RFC 9979
Intended usage: COMMON
Scope: BOTH
Owner/Change controller: IESG9.1.9. $MailFlagBit0 Keyword Registration
Last one in this batch is $MailFlagBit0 🚩:
IMAP/JMAP keyword name: $MailFlagBit0
Purpose: Bit 0 part of a 3-bit bitmask that defines the color of the
flag when the message has the system flag \Flagged set. See
Section 3 for details.
Private or Shared on a server: SHARED
Is it an advisory keyword or may it cause an automatic action: This
keyword is advisory.
When/by whom the keyword is set/cleared: This keyword is set by a
client as the result of a user action to "flag" a message as
urgent / in need of special attention.
Related keywords: $MailFlagBit1, $MailFlagBit2
Related IMAP capabilities: None
Security considerations: None
Published specification: RFC 9979
Intended usage: COMMON
Scope: BOTH
Owner/Change controller: IESG9.1.10. $MailFlagBit1 Keyword Registration 🎀
Okay bestie, $MailFlagBit1 is up next. It's one of the bits that helps pick the color of a flag. ✨
IMAP/JMAP keyword name: $MailFlagBit1
Purpose: Bit 1 part of a 3-bit bitmask that defines the color of the
flag when the message has the system flag \Flagged set. See
Section 3 for details.
Private or Shared on a server: SHARED
Is it an advisory keyword or may it cause an automatic action: This
keyword is advisory.
When/by whom the keyword is set/cleared: This keyword is set by a
client as the result of a user action to "flag" a message as
urgent / in need of special attention.
Related keywords: $MailFlagBit0, $MailFlagBit2
Related IMAP capabilities: None
Security considerations: None
Published specification: RFC 9979
Intended usage: COMMON
Scope: BOTH
Owner/Change controller: IESG9.1.11. $MailFlagBit2 Keyword Registration 🦋
$MailFlagBit2 is the other half of the same little 3-bit crew. 💜
IMAP/JMAP keyword name: $MailFlagBit2
Purpose: Bit 2 part of a 3-bit bitmask that defines the color of the
flag when the message has the system flag \Flagged set. See
Section 3 for details.
Private or Shared on a server: SHARED
Is it an advisory keyword or may it cause an automatic action: This
keyword is advisory.
When/by whom the keyword is set/cleared: This keyword is set by a
client as the result of a user action to "flag" a message as
urgent / in need of special attention.
Related keywords: $MailFlagBit0, $MailFlagBit1
Related IMAP capabilities: None
Security considerations: None
Published specification: RFC 9979
Intended usage: COMMON
Scope: BOTH
Owner/Change controller: IESG9.1.12. $maskedemail Keyword Registration 🎭
This one is giving secret-alias energy. 🙈
IMAP/JMAP keyword name: $maskedemail
Purpose: Indicate to the client that the message was received via an
alias created for an individual sender.
Private or Shared on a server: SHARED
Is it an advisory keyword or may it cause an automatic action: This
keyword is advisory.
When/by whom the keyword is set/cleared: This keyword is set by the
server on delivery.
Related keywords: None
Related IMAP capabilities: None
Security considerations: None
Published specification: RFC 9979
Intended usage: LIMITED USE
Scope: BOTH
Owner/Change controller: IESG9.1.13. $memo Keyword Registration 📝
$memo is the note-to-self keyword, so it's basically a sticky note in your inbox. 🌸
IMAP/JMAP keyword name: $memo
Purpose: Indicate to the client that a message is a note-to-self
from the user regarding another message in the same thread.
Private or Shared on a server: SHARED
Is it an advisory keyword or may it cause an automatic action: This
keyword is advisory.
When/by whom the keyword is set/cleared: This keyword is set and
cleared by the client based on user interaction.
Related keywords: The $memo and $hasmemo keywords are mutually
exclusive.
Related IMAP capabilities: None
Security considerations: None
Published specification: RFC 9979
Intended usage: COMMON
Scope: BOTH
Owner/Change controller: IESG9.1.14. $muted Keyword Registration 🔕
Muting a thread is lowkey a power move, but the security notes here are seriously important, so read them carefully. 🚨
IMAP/JMAP keyword name: $muted
Purpose: Indicate to the server that the user is not interested in
future replies to a particular thread.
Private or Shared on a server: SHARED
Is it an advisory keyword or may it cause an automatic action: This
keyword can cause an automatic action.
When/by whom the keyword is set/cleared: This keyword is set and
cleared by the client.
Related keywords: Mutually exclusive with $followed. If both are
specified on a thread, servers MUST behave as though only
$followed were set.
Related IMAP capabilities: None
Security considerations: Muting a thread can mean a user won't be
notified of a reply. If someone compromises a user's account,
they may mute threads where they don't want the user to be
notified of the reply, for example, when sending phishing to the
user's contacts. However, there are many other ways an attacker
with access to the user's mailbox can also achieve this, so this
is not greatly increasing the attack surface. When restoring
legitimate access to a stolen account, care must be taken to find
and confirm or revert mute actions that may have been taken by the
attacker.
Published specification: RFC 9979
Intended usage: COMMON
Scope: BOTH
Owner/Change controller: IESG🚨 Bestie, the security note above is serious. If an account gets compromised, the attacker might mute threads so the user never hears about replies, for example while phishing the user's contacts. Once you're restoring access to a stolen account, go check for mute actions the attacker may have made and confirm or revert them. 😭
9.1.15. $new Keyword Registration ✨
$new means "hey, look at me, this just happened." 👀
IMAP/JMAP keyword name: $new
Purpose: Indicate to the client that a message should be made more
prominent to the user due to a recent action.
Private or Shared on a server: SHARED
Is it an advisory keyword or may it cause an automatic action: This
keyword is advisory.
When/by whom the keyword is set/cleared: This keyword is set by the
server. Clients can clear the keyword based on user interaction.
Related keywords: None
Related IMAP capabilities: None
Security considerations: None
Published specification: RFC 9979
Intended usage: LIMITED USE
Scope: BOTH
Owner/Change controller: IESG9.1.16. $notify Keyword Registration 🔔
This is the keyword that says "ping the user about this one" 🔥
IMAP/JMAP keyword name: $notify
Purpose: Indicate to the client that a notification should be
presented for this message.
Private or Shared on a server: SHARED
Is it an advisory keyword or may it cause an automatic action: This
keyword can cause an automatic action.
When/by whom the keyword is set/cleared: This keyword is set by the
server on delivery when a message meets certain criteria. It may
be cleared by a client when the user interacts with the message.
Related keywords: None
Related IMAP capabilities: None
Security considerations: None
Published specification: RFC 9979
Intended usage: COMMON
Scope: BOTH
Owner/Change controller: IESG9.1.17. $unsubscribed Keyword Registration 📭
And the last one in this group: $unsubscribed, for when the client has tried to leave a mailing list. Bye bye, list! 👋
IMAP/JMAP keyword name: $unsubscribed
Purpose: Indicate the client has attempted to unsubscribe from the
mailing list this message is from.
Private or Shared on a server: SHARED
Is it an advisory keyword or may it cause an automatic action: This
keyword is advisory.
When/by whom the keyword is set/cleared: This keyword is set by the
client based on user interaction.
Related keywords: None
Related IMAP capabilities: None
Security considerations: None
Published specification: RFC 9979
Intended usage: COMMON
Scope: BOTH
Owner/Change controller: IESG9.2. IMAP Mailbox Name Attributes Registrations 📫
Now we're onto the mailbox name attributes. Three of them got registered in the "IMAP Mailbox Name Attributes" registry, all thanks to [RFC8457]. 🌈
Heads up: none of these attributes have an implied backslash. That's what makes them different from the ones in Section 2 of [RFC6154]. 🧚
9.2.1. Snoozed Mailbox Name Attribute Registration ⏰
Attribute Name: Snoozed
Description: Identifies the mailbox where temporarily snoozed
messages are stored.
Reference: RFC 99799.2.2. Scheduled Mailbox Name Attribute Registration 🗓️
Attribute Name: Scheduled
Description: Identifies the mailbox where messages scheduled to be
sent at a later time are stored.
Reference: RFC 99799.2.3. Memos Mailbox Name Attribute Registration 🗒️
Attribute Name: Memos
Description: Identifies the mailbox where user-created memo messages
are stored.
Reference: RFC 997910. Security Considerations 🔐
The security considerations for the $istrusted and $muted keywords are described in Sections 9.1.8, 7.4, and 9.1.14, respectively. 💅
The use and interpretation of the keywords and mailbox name attributes defined in this document depend on the client's and user's ability to trust the IMAP server. Clients should be aware that a compromised or malicious server could set these keywords incorrectly or manipulate them to mislead users. For additional security considerations related to IMAP, refer to [RFC9051]. 🫣
Otherwise, this document should not affect the security of the Internet. 🌍
11. Normative References 📚
[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>.
[RFC5788] Melnikov, A. and D. Cridland, "IMAP4 Keyword Registry",
RFC 5788, DOI 10.17487/RFC5788, March 2010,
<https://www.rfc-editor.org/info/rfc5788>.
[RFC6154] Leiba, B. and J. Nicolson, "IMAP LIST Extension for
Special-Use Mailboxes", RFC 6154, DOI 10.17487/RFC6154,
March 2011, <https://www.rfc-editor.org/info/rfc6154>.
[RFC8058] Levine, J. and T. Herkula, "Signaling One-Click
Functionality for List Email Headers", RFC 8058,
DOI 10.17487/RFC8058, January 2017,
<https://www.rfc-editor.org/info/rfc8058>.
[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>.
[RFC8457] Leiba, B., Ed., "IMAP "$Important" Keyword and
"\Important" Special-Use Attribute", RFC 8457,
DOI 10.17487/RFC8457, September 2018,
<https://www.rfc-editor.org/info/rfc8457>.
[RFC8474] Gondwana, B., Ed., "IMAP Extension for Object
Identifiers", RFC 8474, DOI 10.17487/RFC8474, September
2018, <https://www.rfc-editor.org/info/rfc8474>.
[RFC8621] Jenkins, N. and C. Newman, "The JSON Meta Application
Protocol (JMAP) for Mail", RFC 8621, DOI 10.17487/RFC8621,
August 2019, <https://www.rfc-editor.org/info/rfc8621>.
[RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
Access Protocol (IMAP) - Version 4rev2", RFC 9051,
DOI 10.17487/RFC9051, August 2021,
<https://www.rfc-editor.org/info/rfc9051>.Authors' Addresses 🫶
Neil Jenkins
Fastmail
PO Box 234, Collins St West
Melbourne VIC 8007
Australia
Email: neilj@fastmailteam.com
URI: https://www.fastmail.com
Daniel Eggert
Apple, Inc
One Apple Park Way
Cupertino, CA 95014
United States of America
Email: deggert@apple.com
URI: https://www.apple.com📦 where this page comes from
- ietf: rfc9979 2026-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms