rfc9979.original.xml   rfc9979.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="rfc7991bis.rnc"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
<!ENTITY mdash "&#x2014;">
]> ]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-i
etf-mailmaint-messageflag-mailboxattribute-14" ipr="trust200902" obsoletes="" up <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-i
dates="" submissionType="IETF" xml:lang="en" version="3"> etf-mailmaint-messageflag-mailboxattribute-14" number="9979" ipr="trust200902" o
bsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3" tocInclud
e="true" symRefs="true" sortRefs="true" consensus="true">
<front> <front>
<title abbrev="Further IMAP/JMAP keywords &amp; attributes">Registration of <title abbrev="Further IMAP/JMAP Keywords &amp; Attributes">Registration of
further IMAP/JMAP keywords and mailbox name attributes</title> Further IMAP/JMAP Keywords and Mailbox Name Attributes</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-mailmaint-messageflag-ma <seriesInfo name="RFC" value="9979"/>
ilboxattribute-14"/> <author fullname="Neil Jenkins" initials="N." surname="Jenkins">
<author fullname="Neil Jenkins" initials="N.M." surname="Jenkins">
<organization>Fastmail</organization> <organization>Fastmail</organization>
<address> <address>
<postal> <postal>
<street>PO Box 234, Collins St West</street> <street>PO Box 234, Collins St West</street>
<city>Melbourne</city> <city>Melbourne</city>
<code>VIC 8007</code> <code>VIC 8007</code>
<country>Australia</country> <country>Australia</country>
</postal> </postal>
<email>neilj@fastmailteam.com</email> <email>neilj@fastmailteam.com</email>
<uri>https://www.fastmail.com</uri> <uri>https://www.fastmail.com</uri>
</address> </address>
</author> </author>
<author fullname="Daniel Eggert" initials="D." surname="Eggert"> <author fullname="Daniel Eggert" initials="D." surname="Eggert">
<organization>Apple Inc</organization> <organization>Apple, Inc</organization>
<address> <address>
<postal> <postal>
<street>One Apple Park Way</street> <street>One Apple Park Way</street>
<city>Cupertino</city> <city>Cupertino</city>
<code>CA 95014</code> <region>CA</region><code>95014</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>deggert@apple.com</email> <email>deggert@apple.com</email>
<uri>https://www.apple.com</uri> <uri>https://www.apple.com</uri>
</address> </address>
</author> </author>
<date year="2026" month="1" day="5"/> <date year="2026" month="May"/>
<area>Art</area> <area>ART</area>
<workgroup>MailMaint</workgroup> <workgroup>mailmaint</workgroup>
<keyword>IMAP</keyword> <keyword>IMAP</keyword>
<keyword>JMAP</keyword> <keyword>JMAP</keyword>
<abstract> <abstract>
<t>This document defines a number of keywords and mailbox name attributes that have been in use across different server and client implementations. It def ines the intended use of these keywords and mailbox name attributes. This docume nt registers all of these with IANA to avoid name collisions.</t> <t>This document defines a number of keywords and mailbox name attributes that have been in use across different server and client implementations. It def ines the intended use of these keywords and mailbox name attributes. This docume nt registers all of these with IANA to avoid name collisions.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro"> <section anchor="intro">
<name>Introduction</name> <name>Introduction</name>
<t>The Internet Message Access Protocol (IMAP) specification <xref target= "RFC9051"/> defines the use of message keywords, and an "IMAP and JMAP Keywords" registry is created in <xref target="RFC5788"/>. Similarly <xref target="RFC845 7"/> creates an "IMAP Mailbox Name Attributes Registry". JMAP Mail <xref target= "RFC8621"/> updated these registries to apply to messages and mailboxes over the JMAP protocol as well.</t> <t>The Internet Message Access Protocol (IMAP) specification <xref target= "RFC9051"/> defines the use of message keywords, and <xref target="RFC5788"/> de scribes the creation of the "IMAP and JMAP Keywords" registry. Similarly, <xref target="RFC8457"/> describes the creation of the "IMAP Mailbox Name Attributes" registry. <xref target="RFC8621"/> updates these registries to apply to message s and mailboxes over the JMAP as well.</t>
<t>This document defines 17 message keywords:</t> <t>This document defines 17 message keywords:</t>
<ul empty="true" spacing="compact"> <ul spacing="normal">
<li><tt>$autosent</tt></li> <li><tt>$autosent</tt></li>
<li><tt>$canunsubscribe</tt></li> <li><tt>$canunsubscribe</tt></li>
<li><tt>$followed</tt></li> <li><tt>$followed</tt></li>
<li><tt>$hasattachment</tt></li> <li><tt>$hasattachment</tt></li>
<li><tt>$hasmemo</tt></li> <li><tt>$hasmemo</tt></li>
<li><tt>$hasnoattachment</tt></li> <li><tt>$hasnoattachment</tt></li>
<li><tt>$imported</tt></li> <li><tt>$imported</tt></li>
<li><tt>$istrusted</tt></li> <li><tt>$istrusted</tt></li>
<li><tt>$MailFlagBit0</tt></li> <li><tt>$MailFlagBit0</tt></li>
<li><tt>$MailFlagBit1</tt></li> <li><tt>$MailFlagBit1</tt></li>
<li><tt>$MailFlagBit2</tt></li> <li><tt>$MailFlagBit2</tt></li>
<li><tt>$maskedemail</tt></li> <li><tt>$maskedemail</tt></li>
<li><tt>$memo</tt></li> <li><tt>$memo</tt></li>
<li><tt>$muted</tt></li> <li><tt>$muted</tt></li>
<li><tt>$new</tt></li> <li><tt>$new</tt></li>
<li><tt>$notify</tt></li> <li><tt>$notify</tt></li>
<li><tt>$unsubscribed</tt></li> <li><tt>$unsubscribed</tt></li>
</ul> </ul>
<t>And defines 3 mailbox name attributes:</t> <t>And defines three mailbox name attributes:</t>
<ul empty="true" spacing="compact"> <ul spacing="normal">
<li><tt>Memos</tt></li> <li><tt>Memos</tt></li>
<li><tt>Scheduled</tt></li> <li><tt>Scheduled</tt></li>
<li><tt>Snoozed</tt></li> <li><tt>Snoozed</tt></li>
</ul> </ul>
<t>This document also registers these in the "IMAP and JMAP Keywords" regi stry and "IMAP Mailbox Name Attributes" registry.</t> <t>This document also registers these in the "IMAP and JMAP Keywords" regi stry and "IMAP Mailbox Name Attributes" registry.</t>
</section> </section>
<section> <section>
<name>Requirements Language</name> <name>Requirements Language</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 <t>
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bc IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
p14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14> NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
" in this document are to be interpreted as described in BCP 14 <xref target="RF RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
C2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capita "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
ls, as shown here.</t> be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section anchor="mailflagbits"> <section anchor="mailflagbits">
<name>Flag Color Keywords</name> <name>Flag Color Keywords</name>
<t>The Internet Message Access Protocol (IMAP) specification <xref target= "RFC9051"/> defines a <tt>\Flagged</tt> system flag to mark a message for urgent /special attention. The new keywords defined in <xref target="mailflagbits-defin ition" /> allow such a flagged message to have that flag be of one of 7 colors.< /t> <t>The Internet Message Access Protocol (IMAP) specification <xref target= "RFC9051"/> defines a <tt>\Flagged</tt> system flag to mark a message as urgent / in need of special attention. The new keywords defined in <xref target="mailfl agbits-definition" /> allow such a flagged message to have that flag be of one o f seven colors.</t>
<section anchor="mailflagbits-definition"> <section anchor="mailflagbits-definition">
<name>Definition of the <tt>$MailFlagBit_</tt> Message Keywords</name> <name>Definition of the <tt>$MailFlagBit_</tt> Message Keywords</name>
<t>The 3 flag color keywords</t> <t>The three flag color keywords:</t>
<ul empty="true" spacing="compact"> <ul spacing="normal">
<li> <li>
<tt>$MailFlagBit0</tt> <tt>$MailFlagBit0</tt>
</li> </li>
<li> <li>
<tt>$MailFlagBit1</tt> <tt>$MailFlagBit1</tt>
</li> </li>
<li> <li>
<tt>$MailFlagBit2</tt> <tt>$MailFlagBit2</tt>
</li> </li>
</ul> </ul>
skipping to change at line 158 skipping to change at line 165
<td>purple</td> <td>purple</td>
</tr> </tr>
<tr> <tr>
<td>0</td> <td>0</td>
<td>1</td> <td>1</td>
<td>1</td> <td>1</td>
<td>gray</td> <td>gray</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Note that the bit combination 111 (all three bits set) is not assigne <t>Note that the bit combination 111 (all three bits set) is not assigne
d a color, resulting in 7 distinct flag colors instead of 8 possible combination d a color, resulting in seven distinct flag colors instead of eight possible com
s.</t> binations.</t>
<t>These flags <bcp14>MUST</bcp14> be ignored if the <tt>\Flagged</tt> s <t>These flags <bcp14>MUST</bcp14> be ignored if the <tt>\Flagged</tt> s
ystem flag is not set. If the <tt>\Flagged</tt> system flag is set, the flagged ystem flag is not set. If the <tt>\Flagged</tt> system flag is set, the flagged
status <bcp14>MAY</bcp14> be presented to the user in the color corresponding to status <bcp14>MAY</bcp14> be presented to the user in the color corresponding to
the combination of the 3 flag color keywords.</t> the combination of the three flag color keywords.</t>
</section> </section>
<section> <section>
<name>Implementation Notes</name> <name>Implementation Notes</name>
<t>A mail client that is aware of these flag color keywords <bcp14>MUST< /bcp14> clear all 3 flag color keywords when the user unflags the message, i.e. when clearing the <tt>\Flagged</tt> system flag, all 3 flag color keywords <bcp1 4>MUST</bcp14> also be cleared.</t> <t>A mail client that is aware of these flag color keywords <bcp14>MUST< /bcp14> clear all three flag color keywords when the user unflags the message, i .e., when clearing the <tt>\Flagged</tt> system flag, all three flag color keywo rds <bcp14>MUST</bcp14> also be cleared.</t>
<t>A mail client <bcp14>MUST NOT</bcp14> set any of these flags unless t he <tt>\Flagged</tt> system flag is already set or is being set.</t> <t>A mail client <bcp14>MUST NOT</bcp14> set any of these flags unless t he <tt>\Flagged</tt> system flag is already set or is being set.</t>
<t>Servers <bcp14>MAY</bcp14> clear these flag color keywords when a cli ent clears the <tt>\Flagged</tt> system flag.</t> <t>Servers <bcp14>MAY</bcp14> clear these flag color keywords when a cli ent clears the <tt>\Flagged</tt> system flag.</t>
<t>While these keywords are defined in terms of colors, clients <bcp14>S HOULD</bcp14> provide alternatives for users who cannot perceive colors. This co uld include using different shapes, patterns, text labels, audio cues, or other distinguishing characteristics that convey the same semantic meaning as the colo r variations. The specific bit patterns can serve as identifiers for such altern ative representations.</t> <t>While these keywords are defined in terms of colors, clients <bcp14>S HOULD</bcp14> provide alternatives for users who cannot perceive colors. This co uld include using different shapes, patterns, text labels, audio cues, or other distinguishing characteristics that convey the same semantic meaning as the colo r variations. The specific bit patterns can serve as identifiers for such altern ative representations.</t>
</section> </section>
</section> </section>
<section anchor="attachment-detection"> <section anchor="attachment-detection">
<name>Attachment Detection Keywords</name> <name>Attachment Detection Keywords</name>
<t>The following keywords help clients determine whether a message contain s attachments without having to fetch and parse the entire message structure. Th is is particularly useful for displaying attachment indicators in message lists or implementing attachment-based filtering.</t> <t>The following keywords help clients determine whether a message contain s attachments without having to fetch and parse the entire message structure. Th is is particularly useful for displaying attachment indicators in message lists or implementing attachment-based filtering.</t>
<t>The <tt>$hasattachment</tt> and <tt>$hasnoattachment</tt> keywords are mutually exclusive. A message <bcp14>MUST NOT</bcp14> have both keywords set sim ultaneously.</t> <t>The <tt>$hasattachment</tt> and <tt>$hasnoattachment</tt> keywords are mutually exclusive. A message <bcp14>MUST NOT</bcp14> have both keywords set sim ultaneously.</t>
<section anchor="other_hasattachment"> <section anchor="other_hasattachment">
<name> <name>
<tt>$hasattachment</tt> <tt>$hasattachment</tt>
</name> </name>
<t>The <tt>$hasattachment</tt> keyword indicates that a message has one or more attachments. It is set by the server during message delivery, or by the client (if neither $hasattachment nor $hasnoattachment are currently set).</t> <t>The <tt>$hasattachment</tt> keyword indicates that a message has one or more attachments. It is set by the server during message delivery or by the c lient (if neither $hasattachment nor $hasnoattachment is currently set).</t>
<t>This keyword enables clients to indicate attachments (e.g., paperclip icons) in message lists without having to fetch the full MIME structure for eac h message. It also facilitates attachment-based filtering and search operations. </t> <t>This keyword enables clients to indicate attachments (e.g., paperclip icons) in message lists without having to fetch the full MIME structure for eac h message. It also facilitates attachment-based filtering and search operations. </t>
<t>When using JMAP, the "hasAttachment" Email property <bcp14>MUST</bcp1 4> reflect the same information as this keyword for consistency across protocols .</t> <t>When using JMAP, the "hasAttachment" Email property <bcp14>MUST</bcp1 4> reflect the same information as this keyword for consistency across protocols .</t>
</section> </section>
<section anchor="other_hasnoattachment"> <section anchor="other_hasnoattachment">
<name> <name>
<tt>$hasnoattachment</tt> <tt>$hasnoattachment</tt>
</name> </name>
<t>The <tt>$hasnoattachment</tt> keyword explicitly indicates that a mes sage does not have any attachments. It is set by the server during message deliv ery, or by the client (if neither $hasattachment nor $hasnoattachment are curren tly set).</t> <t>The <tt>$hasnoattachment</tt> keyword explicitly indicates that a mes sage does not have any attachments. It is set by the server during message deliv ery or by the client (if neither $hasattachment nor $hasnoattachment is currentl y set).</t>
<t>This keyword complements <tt>$hasattachment</tt> by providing definit ive information about messages that have been analyzed but found to contain no a ttachments. The absence of <tt>$hasattachment</tt> alone is inconclusive, as it might simply mean the message hasn't been processed for attachment detection.</t > <t>This keyword complements <tt>$hasattachment</tt> by providing definit ive information about messages that have been analyzed but found to contain no a ttachments. The absence of <tt>$hasattachment</tt> alone is inconclusive, as it might simply mean the message hasn't been processed for attachment detection.</t >
<t>This explicit distinction is important for clients that need to know whether attachment detection has been performed on a message. When using JMAP, t he "hasAttachment" Email property <bcp14>MUST</bcp14> reflect the same informati on as this keyword.</t> <t>This explicit distinction is important for clients that need to know whether attachment detection has been performed on a message. When using JMAP, t he "hasAttachment" Email property <bcp14>MUST</bcp14> reflect the same informati on as this keyword.</t>
</section> </section>
</section> </section>
<section anchor="memos-keywords"> <section anchor="memos-keywords">
<name>Memos Keywords</name> <name>Memos Keywords</name>
<t>The following keywords are used to support user-created annotations or memos attached to messages. They allow for contextual notes to be added to conve rsations while maintaining proper cross-referencing between messages and their a nnotations.</t> <t>The following keywords are used to support user-created annotations or memos attached to messages. They allow for contextual notes to be added to conve rsations while maintaining proper cross-referencing between messages and their a nnotations.</t>
<t>The <tt>$memo</tt> keyword is applied to the memo message itself (the n ote-to-self), while the <tt>$hasmemo</tt> keyword is applied to the original mes sage being annotated. This creates a bidirectional relationship that allows clie nts to efficiently locate memos and their associated messages.</t> <t>The <tt>$memo</tt> keyword is applied to the memo message itself (the n ote-to-self), while the <tt>$hasmemo</tt> keyword is applied to the original mes sage being annotated. This creates a bidirectional relationship that allows clie nts to efficiently locate memos and their associated messages.</t>
<t>The <tt>$memo</tt> and <tt>$hasmemo</tt> keywords are mutually exclusiv e. A message <bcp14>MUST NOT</bcp14> have both keywords set simultaneously.</t> <t>The <tt>$memo</tt> and <tt>$hasmemo</tt> keywords are mutually exclusiv e. A message <bcp14>MUST NOT</bcp14> have both keywords set simultaneously.</t>
<section anchor="other_hasmemo"> <section anchor="other_hasmemo">
skipping to change at line 208 skipping to change at line 215
</name> </name>
<t>The <tt>$hasmemo</tt> keyword indicates that a message has an associa ted memo (identified by the <tt>$memo</tt> keyword) in the same thread. This all ows clients to efficiently identify messages with annotations without having to examine all messages in a thread.</t> <t>The <tt>$hasmemo</tt> keyword indicates that a message has an associa ted memo (identified by the <tt>$memo</tt> keyword) in the same thread. This all ows clients to efficiently identify messages with annotations without having to examine all messages in a thread.</t>
<t>When a client creates a memo for a message, it <bcp14>MUST</bcp14> ad d this keyword to the message being annotated while adding the <tt>$memo</tt> ke yword to the memo message itself. Conversely, when a memo is deleted, the client <bcp14>MUST</bcp14> remove this keyword from the annotated message.</t> <t>When a client creates a memo for a message, it <bcp14>MUST</bcp14> ad d this keyword to the message being annotated while adding the <tt>$memo</tt> ke yword to the memo message itself. Conversely, when a memo is deleted, the client <bcp14>MUST</bcp14> remove this keyword from the annotated message.</t>
<t>This keyword enables several optimizations for clients. It allows for efficient searching for messages with annotations, enables indicators in messag e lists to indicate which messages have memos, and helps clients decide whether to fetch entire conversation threads when loading a mailbox to ensure memos are properly presented.</t> <t>This keyword enables several optimizations for clients. It allows for efficient searching for messages with annotations, enables indicators in messag e lists to indicate which messages have memos, and helps clients decide whether to fetch entire conversation threads when loading a mailbox to ensure memos are properly presented.</t>
</section> </section>
<section anchor="other_memo"> <section anchor="other_memo">
<name> <name>
<tt>$memo</tt> <tt>$memo</tt>
</name> </name>
<t>The <tt>$memo</tt> keyword identifies a message as a note-to-self cre ated by the user regarding another message in the same thread. It allows for con textual annotations to be added to conversations.</t> <t>The <tt>$memo</tt> keyword identifies a message as a note-to-self cre ated by the user regarding another message in the same thread. It allows for con textual annotations to be added to conversations.</t>
<t>Messages with this keyword should be constructed similar to a reply t o the message being annotated, with appropriate Subject and Reply-To headers set to maintain context and threading. Servers <bcp14>SHOULD</bcp14> store messages with this keyword in a mailbox with the "Memos" mailbox name attribute (see <xr ef target="memos-mailbox-name-attribute-registration"/>), if available.</t> <t>Messages with this keyword should be constructed similarly to a reply to the message being annotated, with appropriate Subject and Reply-To headers s et to maintain context and threading. Servers <bcp14>SHOULD</bcp14> store messag es with this keyword in a mailbox with the "Memos" mailbox name attribute (see < xref target="memos-mailbox-name-attribute-registration"/>), if available.</t>
<t>Supporting clients <bcp14>MUST</bcp14> present these messages differe ntly from regular emails. Rather than presenting them as standalone messages, th ey <bcp14>MUST</bcp14> be presented as annotations attached to the message they' re commenting on. Clients may provide special UI affordances for editing or dele ting these memos, which typically requires replacing the message since email mes sages are immutable.</t> <t>Supporting clients <bcp14>MUST</bcp14> present these messages differe ntly from regular emails. Rather than presenting them as standalone messages, th ey <bcp14>MUST</bcp14> be presented as annotations attached to the message they' re commenting on. Clients may provide special UI affordances for editing or dele ting these memos, which typically requires replacing the message since email mes sages are immutable.</t>
<t>When a client creates or removes a memo, it <bcp14>MUST</bcp14> also set or clear the related <tt>$hasmemo</tt> keyword on the message being annotate d to maintain proper cross-referencing.</t> <t>When a client creates or removes a memo, it <bcp14>MUST</bcp14> also set or clear the related <tt>$hasmemo</tt> keyword on the message being annotate d to maintain proper cross-referencing.</t>
</section> </section>
</section> </section>
<section anchor="subscription-management"> <section anchor="subscription-management">
<name>Subscription Management Keywords</name> <name>Subscription Management Keywords</name>
<t>The following keywords help clients manage mailing list subscriptions. They provide mechanisms for tracking unsubscription attempts and identifying mes sages with valid unsubscribe options.</t> <t>The following keywords help clients manage mailing list subscriptions. They provide mechanisms for tracking unsubscription attempts and identifying mes sages with valid unsubscribe options.</t>
<section anchor="other_canunsubscribe"> <section anchor="other_canunsubscribe">
<name> <name>
<tt>$canunsubscribe</tt> <tt>$canunsubscribe</tt>
</name> </name>
<t>The <tt>$canunsubscribe</tt> keyword indicates that a message contain <t>The <tt>$canunsubscribe</tt> keyword indicates that a message contain
s a valid, <xref target="RFC8058"/>-compliant List-Unsubscribe header that clien s a valid, List-Unsubscribe header compliant with <xref target="RFC8058"/> that
ts can use to provide one-click unsubscribe functionality.</t> clients can use to provide one-click unsubscribe functionality.</t>
<t>This keyword is set by servers during message delivery when they dete <t>This keyword is set by servers during message delivery when they dete
ct a valid List-Unsubscribe header and the message passes implementation-specifi ct a valid List-Unsubscribe header and the message passes implementation-specifi
c reputation checks. This pre-verification is important, as not all List-Unsubsc c reputation checks. This pre-verification is important, as not all List-Unsubsc
ribe headers are trustworthy, and some might lead to phishing sites or generate ribe headers are trustworthy: some might lead to phishing sites or generate addi
additional spam.</t> tional spam.</t>
<t>The primary benefit of this keyword is efficiency--clients can know w <t>The primary benefit of this keyword is efficiency: clients can know w
hether to offer unsubscribe functionality in their user interface without having hether to offer unsubscribe functionality in their user interface without having
to fetch and validate the List-Unsubscribe header for every message. It also pr to fetch and validate the List-Unsubscribe header for every message. It also pr
ovides an extra layer of safety since the server has already performed reputatio ovides an extra layer of safety since the server has already performed reputatio
n checks on the unsubscribe mechanism.</t> n checks on the unsubscribe mechanism.</t>
</section> </section>
<section anchor="other_unsubscribed"> <section anchor="other_unsubscribed">
<name> <name>
<tt>$unsubscribed</tt> <tt>$unsubscribed</tt>
</name> </name>
<t>The <tt>$unsubscribed</tt> keyword indicates that the user has attemp ted to unsubscribe from the mailing list associated with a message. It provides a persistent record of unsubscription attempts across multiple clients.</t> <t>The <tt>$unsubscribed</tt> keyword indicates that the user has attemp ted to unsubscribe from the mailing list associated with a message. It provides a persistent record of unsubscription attempts across multiple clients.</t>
<t>This keyword is set by a client after a user attempts to unsubscribe <t>This keyword is set by a client after a user attempts to unsubscribe
from a mailing list, typically via a one-click List-Unsubscribe action as define from a mailing list, typically via a one-click List-Unsubscribe action as define
d in <xref target="RFC8058"/>. It serves as a record that an unsubscription atte d in <xref target="RFC8058"/>. It serves as a record that an unsubscription atte
mpt has been made, even if confirmation of successful unsubscription hasn't been mpt has been made, even if confirmation of successful unsubscription hasn't been
received. It MUST NOT be set if the unsubscription attempt definitely failed.</ received. It <bcp14>MUST NOT</bcp14> be set if the unsubscription attempt defin
t> itely failed.</t>
<t>Supporting clients can use this to provide an indicator on messages w <t>Supporting clients can use this to provide an indicator on messages w
ith this keyword to remind the user they have previously attempted to unsubscrib ith this keyword to remind the user they have previously attempted to unsubscrib
e from this sender or mailing list. This can be helpful when users revisit old m e from this sender or mailing list. This can be helpful when users revisit old m
essages and might otherwise attempt to unsubscribe again, or when they receive a essages and might otherwise attempt to unsubscribe again or when they receive ad
dditional messages despite unsubscribing and need to take further action.</t> ditional messages despite unsubscribing and need to take further action.</t>
</section> </section>
</section> </section>
<section anchor="OtherMessageKeywords"> <section anchor="OtherMessageKeywords">
<name>Other Message Keywords</name> <name>Other Message Keywords</name>
<section anchor="other_autosent"> <section anchor="other_autosent">
<name> <name>
<tt>$autosent</tt> <tt>$autosent</tt>
</name> </name>
<t>The <tt>$autosent</tt> keyword identifies messages that were automati cally generated and sent by the system on behalf of the user, typically in respo nse to user-defined filtering rules or settings.</t> <t>The <tt>$autosent</tt> keyword identifies messages that were automati cally generated and sent by the system on behalf of the user, typically in respo nse to user-defined filtering rules or settings.</t>
<t>This keyword is set by the server on the user's copy of vacation auto -replies, automated responses, or other system-generated messages sent on behalf of the user. It allows clients to clearly distinguish these messages from those directly composed and sent by the user.</t> <t>This keyword is set by the server on the user's copy of vacation auto -replies, automated responses, or other system-generated messages sent on behalf of the user. It allows clients to clearly distinguish these messages from those directly composed and sent by the user.</t>
<!--[rfced] In the following, should "sent items folder" be made
"\Sent mailbox"?
Original:
Supporting clients can present these messages differently in the sent
items folder...
-->
<t>Supporting clients can present these messages differently in the sent items folder, such as with a distinct indicator (e.g., icon or label) indicatin g their automated nature. This helps prevent user confusion when they encounter messages they don't remember writing, particularly in the case of vacation respo nses or other automated replies that may have been configured and then forgotten .</t> <t>Supporting clients can present these messages differently in the sent items folder, such as with a distinct indicator (e.g., icon or label) indicatin g their automated nature. This helps prevent user confusion when they encounter messages they don't remember writing, particularly in the case of vacation respo nses or other automated replies that may have been configured and then forgotten .</t>
</section> </section>
<section anchor="other_followed"> <section anchor="other_followed">
<name> <name>
<tt>$followed</tt> <tt>$followed</tt>
</name> </name>
<t>The <tt>$followed</tt> keyword indicates that a user is particularly interested in future messages in a specific thread. This enables special handlin g to ensure these messages receive appropriate attention.</t> <t>The <tt>$followed</tt> keyword indicates that a user is particularly interested in future messages in a specific thread. This enables special handlin g to ensure these messages receive appropriate attention.</t>
<t>When a new message arrives in a thread where this keyword is present, <t>When a new message arrives in a thread where this keyword is present,
supporting servers <bcp14>MAY</bcp14> take actions to prioritize the message. T supporting servers <bcp14>MAY</bcp14> take actions to prioritize the message. T
his could include ensuring it is available in the inbox regardless of filtering his could include ensuring it is available in the inbox regardless of filtering
rules that might otherwise affect it, automatically adding the <tt>$notify</tt> rules that might otherwise affect it, automatically adding the <tt>$notify</tt>
keyword to ensure notifications, or applying other handling that increases its p keyword to ensure notifications, or applying other handling that increases its p
rominence. The specific actions taken and whether they can be configured by the rominence. The specific actions taken and whether they can be configured by the
user depends on the implementation.</t> user depend on the implementation.</t>
<t>Thread identification for this keyword follows the same definition as <t>Thread identification for this keyword follows the same definition as
described in <xref target="other_muted" format="title"/>.</t> described in <xref target="other_muted"/>.</t>
<t>This keyword is set or cleared by clients based on user actions to fo llow or unfollow a thread. When unfollowing a thread, clients <bcp14>MUST</bcp14 > remove this keyword from all messages in the thread that have it. The <tt>$fol lowed</tt> keyword is mutually exclusive with the <tt>$muted</tt> keyword. If bo th are present on messages in the same thread, servers <bcp14>MUST</bcp14> treat the thread as followed rather than muted.</t> <t>This keyword is set or cleared by clients based on user actions to fo llow or unfollow a thread. When unfollowing a thread, clients <bcp14>MUST</bcp14 > remove this keyword from all messages in the thread that have it. The <tt>$fol lowed</tt> keyword is mutually exclusive with the <tt>$muted</tt> keyword. If bo th are present on messages in the same thread, servers <bcp14>MUST</bcp14> treat the thread as followed rather than muted.</t>
</section> </section>
<section anchor="other_imported"> <section anchor="other_imported">
<name> <name>
<tt>$imported</tt> <tt>$imported</tt>
</name> </name>
<t>The <tt>$imported</tt> keyword identifies messages that were imported into the mailbox from another system rather than received through normal mail d elivery channels.</t> <t>The <tt>$imported</tt> keyword identifies messages that were imported into the mailbox from another system rather than received through normal mail d elivery channels.</t>
<t>This keyword is set by servers during import operations from other ma il systems, data migrations, or manual imports from local files. It helps distin guish messages that didn't arrive through normal mail delivery and may have diff erent characteristics or behaviors.</t> <t>This keyword is set by servers during import operations from other ma il systems, data migrations, or manual imports from local files. It helps distin guish messages that didn't arrive through normal mail delivery and may have diff erent characteristics or behaviors.</t>
<t>Supporting clients can provide an indicator for imported messages, es pecially if they have unusual properties such as unexpectedly old dates, unusual header structures, or other anomalies that might otherwise confuse users. Some clients might also offer filtering or search capabilities specifically for impor ted messages.</t> <t>Supporting clients can provide an indicator for imported messages, es pecially if they have unusual properties such as unexpectedly old dates, unusual header structures, or other anomalies that might otherwise confuse users. Some clients might also offer filtering or search capabilities specifically for impor ted messages.</t>
</section> </section>
<section anchor="other_istrusted"> <section anchor="other_istrusted">
<name> <name>
<tt>$istrusted</tt> <tt>$istrusted</tt>
</name> </name>
<t>The <tt>$istrusted</tt> keyword indicates that a message's sender ide ntity has been verified by the server with a high degree of confidence. It provi des an indication that the message is likely authentic.</t> <t>The <tt>$istrusted</tt> keyword indicates that a message's sender ide ntity has been verified by the server with a high degree of confidence. It provi des an indication that the message is likely authentic.</t>
<t>This advisory keyword is set by the server during message delivery wh en the authenticity of both the sender's name and email address can be verified with a high degree of confidence. This level of verification typically applies t o messages sent by the mailbox provider itself to its customers, where the provi der has strong evidence of the message's origin.</t> <t>This advisory keyword is set by the server during message delivery wh en the authenticity of both the sender's name and email address can be verified with a high degree of confidence. This level of verification typically applies t o messages sent by the mailbox provider itself to its customers, where the provi der has strong evidence of the message's origin.</t>
<t>Supporting clients can provide a verification indicator (e.g., checkm ark icon) for messages with this keyword, helping users identify legitimate comm unications from their service provider. This is particularly important for disti nguishing authentic provider messages from phishing attempts that impersonate th e provider.</t> <t>Supporting clients can provide a verification indicator (e.g., check mark icon) for messages with this keyword, helping users identify legitimate com munications from their service provider. This is particularly important for dist inguishing authentic provider messages from phishing attempts that impersonate t he provider.</t>
<t>Servers <bcp14>MUST</bcp14> exercise caution when applying this keywo rd, as it conveys trust to the user. If misapplied, it could lead users to trust fraudulent messages.</t> <t>Servers <bcp14>MUST</bcp14> exercise caution when applying this keywo rd, as it conveys trust to the user. If misapplied, it could lead users to trust fraudulent messages.</t>
<t>It <bcp14>MUST NOT</bcp14> be used for messages that have only passed standard authentication mechanisms like SPF, DKIM, or DMARC.</t> <t>It <bcp14>MUST NOT</bcp14> be used for messages that have only passed standard authentication mechanisms like Sender Policy Framework (SPF), DomainKe ys Identified Mail (DKIM), or Domain-based Message Authentication, Reporting, an d Conformance (DMARC).</t>
</section> </section>
<section anchor="other_maskedemail"> <section anchor="other_maskedemail">
<name> <name>
<tt>$maskedemail</tt> <tt>$maskedemail</tt>
</name> </name>
<t>The <tt>$maskedemail</tt> keyword indicates that a message was receiv ed through a masked email address--an alias created specifically for communicati ons with a particular sender to protect the user's primary email address.</t> <t>The <tt>$maskedemail</tt> keyword indicates that a message was receiv ed through a masked email address -- an alias created specifically for communica tions with a particular sender to protect the user's primary email address.</t>
<t>This advisory keyword is set by the server during message delivery on messages that arrive via such aliases. These might be automatically generated s ingle-use addresses, service-specific addresses, or user-created aliases for spe cific correspondents.</t> <t>This advisory keyword is set by the server during message delivery on messages that arrive via such aliases. These might be automatically generated s ingle-use addresses, service-specific addresses, or user-created aliases for spe cific correspondents.</t>
<t>Supporting clients can provide an indicator (e.g., mask icon) for mes sages with this keyword. This helps users understand that the message was receiv ed through a privacy-enhancing alias rather than their primary address. Clients might also provide related functionality, such as the ability to disable the spe cific alias used if it starts receiving unwanted messages.</t> <t>Supporting clients can provide an indicator (e.g., mask icon) for mes sages with this keyword. This helps users understand that the message was receiv ed through a privacy-enhancing alias rather than their primary address. Clients might also provide related functionality, such as the ability to disable the spe cific alias used if it starts receiving unwanted messages.</t>
</section> </section>
<section anchor="other_muted"> <section anchor="other_muted">
<name> <name>
<tt>$muted</tt> <tt>$muted</tt>
</name> </name>
<t>The <tt>$muted</tt> keyword provides a way for users to indicate they are not interested in future messages in a particular conversation thread. This enables automated processing of subsequent messages in that thread to reduce th eir prominence.</t> <t>The <tt>$muted</tt> keyword provides a way for users to indicate they are not interested in future messages in a particular conversation thread. This enables automated processing of subsequent messages in that thread to reduce th eir prominence.</t>
<t>When a new message arrives that belongs to the same thread as one mar ked with this keyword, supporting servers <bcp14>MAY</bcp14> automatically depri oritize the message. This could include moving it to an archive or trash folder, marking it as read, or applying other handling that reduces its prominence. The specific actions taken and whether they can be configured by the user depends o n the implementation.</t> <t>When a new message arrives that belongs to the same thread as one mar ked with this keyword, supporting servers <bcp14>MAY</bcp14> automatically depri oritize the message. This could include moving it to an archive or trash folder, marking it as read, or applying other handling that reduces its prominence. The specific actions taken and whether they can be configured by the user depends o n the implementation.</t>
<t>For thread identification purposes, messages are considered part of t he same thread when they share the same thread identifier as defined in <xref ta rget="RFC8474"/> Section 5.2 for IMAP or <xref target="RFC8621"/>, Section 3 for JMAP. This definition applies to all thread-related keywords in this document.< /t> <t>For thread identification purposes, messages are considered part of t he same thread when they share the same thread identifier as defined in <xref ta rget="RFC8474" section="5.2"/> for IMAP or <xref target="RFC8621" section="3"/> for JMAP. This definition applies to all thread-related keywords in this documen t.</t>
<t>This keyword is set or cleared by clients based on user actions to mu te or unmute a thread. When unmuting a thread, clients <bcp14>MUST</bcp14> remov e this keyword from all messages in the thread that have it. The <tt>$muted</tt> keyword is mutually exclusive with the <tt>$followed</tt> keyword. If both are present on messages in the same thread, both servers and clients <bcp14>MUST</bc p14> treat the thread as followed rather than muted.</t> <t>This keyword is set or cleared by clients based on user actions to mu te or unmute a thread. When unmuting a thread, clients <bcp14>MUST</bcp14> remov e this keyword from all messages in the thread that have it. The <tt>$muted</tt> keyword is mutually exclusive with the <tt>$followed</tt> keyword. If both are present on messages in the same thread, both servers and clients <bcp14>MUST</bc p14> treat the thread as followed rather than muted.</t>
<t>Implementers should note the security considerations in the IANA regi stration: if an attacker gains access to a user's account, they could mute threa ds to hide important communications. However, this represents only a small incre ase in risk since compromised accounts allow many other similar actions.</t> <t>Implementers should note the security considerations in the IANA regi stration: if an attacker gains access to a user's account, they could mute threa ds to hide important communications. However, this represents only a small incre ase in risk since compromised accounts allow many other similar actions.</t>
</section> </section>
<section anchor="other_new"> <section anchor="other_new">
<name> <name>
<tt>$new</tt> <tt>$new</tt>
</name> </name>
<t>The <tt>$new</tt> keyword indicates that a message should be emphasiz ed or made more prominent to the user due to a recent system action, even if the message itself is not new.</t> <t>The <tt>$new</tt> keyword indicates that a message should be emphasiz ed or made more prominent to the user due to a recent system action, even if the message itself is not new.</t>
<t>This advisory keyword is typically set by servers when a previously s noozed message "awakens" and returns to the inbox after its snooze period has el apsed. It signals to clients that although this message might have an older date , it should be treated as effectively new in terms of user attention.</t> <t>This advisory keyword is typically set by servers when a previously s noozed message "awakens" and returns to the inbox after its snooze period has el apsed. It signals to clients that, although this message might have an older dat e, it should be treated as effectively new in terms of user attention.</t>
<t>Supporting clients can present these messages with special treatment to draw user attention, such as emphasizing, bolding, or placing them at the top of the message list, even if strict date sorting would place them elsewhere.</t > <t>Supporting clients can present these messages with special treatment to draw user attention, such as emphasizing, bolding, or placing them at the top of the message list, even if strict date sorting would place them elsewhere.</t >
<t>Clients <bcp14>MUST</bcp14> clear this keyword when the user interact s with the message, such as by opening, replying to, or otherwise acknowledging it. This prevents the message from remaining emphasized indefinitely after the u ser has accessed it.</t> <t>Clients <bcp14>MUST</bcp14> clear this keyword when the user interact s with the message, such as by opening, replying to, or otherwise acknowledging it. This prevents the message from remaining emphasized indefinitely after the u ser has accessed it.</t>
</section> </section>
<section anchor="other_notify"> <section anchor="other_notify">
<name> <name>
<tt>$notify</tt> <tt>$notify</tt>
</name> </name>
<t>The <tt>$notify</tt> keyword indicates that a client should present a notification for a message. This provides a mechanism for more selective notifi cations than the common approach of notifying for every message arriving in the inbox.</t> <t>The <tt>$notify</tt> keyword indicates that a client should present a notification for a message. This provides a mechanism for more selective notifi cations than the common approach of notifying for every message arriving in the inbox.</t>
<t>When a message with this keyword is delivered to a mailstore, support ing clients <bcp14>SHOULD</bcp14> present a notification to the user unless conf igured otherwise by the user. This notification may occur alongside other messag e notifications according to user preferences.</t> <t>When a message with this keyword is delivered to a mailstore, support ing clients <bcp14>SHOULD</bcp14> present a notification to the user unless conf igured otherwise by the user. This notification may occur alongside other messag e notifications according to user preferences.</t>
<t>This keyword enables both users (through filtering rules) and servers (through automated processing) to identify specific messages that warrant user attention, even if they might otherwise be filtered or sorted in a way that woul dn't normally trigger a notification.</t> <t>This keyword enables both users (through filtering rules) and servers (through automated processing) to identify specific messages that warrant user attention, even if they might otherwise be filtered or sorted in a way that woul dn't normally trigger a notification.</t>
<t>Servers typically set this keyword during message delivery when a mes sage meets certain criteria indicating importance to the user. Clients may clear the keyword when the user interacts with the message by opening it, archiving i t, or performing other actions. When one client clears this keyword, other clien ts connected to the same account may choose to automatically dismiss their corre sponding notification.</t> <t>Servers typically set this keyword during message delivery when a mes sage meets certain criteria indicating importance to the user. Clients may clear the keyword when the user interacts with the message by opening it, archiving i t, or performing other actions. When one client clears this keyword, other clien ts connected to the same account may choose to automatically dismiss their corre sponding notification.</t>
</section> </section>
</section> </section>
<section anchor="MailboxNameAttributes"> <section anchor="MailboxNameAttributes">
<name>Mailbox Name Attributes</name> <name>Mailbox Name Attributes</name>
<section anchor="mailbox_snoozed"> <section anchor="mailbox_snoozed">
<name> <name>
<tt>Snoozed</tt> <tt>Snoozed</tt>
</name> </name>
<t>The <tt>Snoozed</tt> mailbox name attribute identifies a mailbox that is used to store messages that have been temporarily removed from the user's at tention and scheduled to reappear at a later time.</t> <t>The <tt>Snoozed</tt> mailbox name attribute identifies a mailbox that is used to store messages that have been temporarily removed from the user's at tention and scheduled to reappear at a later time.</t>
<t>When a user chooses to "snooze" a message, the supporting server will move the message to a mailbox with this attribute. At the specified "awaken" ti me, the server will automatically move the message back to its original location (typically the inbox) and may mark it with the <tt>$new</tt> keyword to ensure it receives proper attention.</t> <t>When a user chooses to "snooze" a message, the supporting server move s the message to a mailbox with this attribute. At the specified "awaken" time, the server automatically moves the message back to its original location (typica lly the inbox) and may mark it with the <tt>$new</tt> keyword to ensure it recei ves proper attention.</t>
<t>This attribute standardizes the location of snoozed messages across c lients, allowing them to identify and manage snoozed messages consistently. Howe ver, this attribute merely identifies the storage location for snoozed messages and does not itself define the snoozing mechanism or interface.</t> <t>This attribute standardizes the location of snoozed messages across c lients, allowing them to identify and manage snoozed messages consistently. Howe ver, this attribute merely identifies the storage location for snoozed messages and does not itself define the snoozing mechanism or interface.</t>
<t>Supporting clients may present the contents of this mailbox different ly from regular mailboxes, such as organizing messages by their scheduled "awake n" time rather than received date, or providing specialized interfaces for adjus ting the snooze duration.</t> <t>Supporting clients may present the contents of this mailbox different ly from regular mailboxes, such as organizing messages by their scheduled "awake n" time rather than received date or providing specialized interfaces for adjust ing the snooze duration.</t>
</section> </section>
<section anchor="mailbox_scheduled"> <section anchor="mailbox_scheduled">
<name> <name>
<tt>Scheduled</tt> <tt>Scheduled</tt>
</name> </name>
<t>The <tt>Scheduled</tt> mailbox name attribute identifies a mailbox th at contains messages that have been composed but are scheduled to be sent at a f uture time rather than immediately.</t> <t>The <tt>Scheduled</tt> mailbox name attribute identifies a mailbox th at contains messages that have been composed but are scheduled to be sent at a f uture time rather than immediately.</t>
<t>When a user composes a message and chooses to send it at a later date or time, the supporting server will store the message in a mailbox with this at tribute until the scheduled sending time. Once that time is reached, the server will send the message and typically move it to the \Sent mailbox or delete it ac cording to server policy.</t> <t>When a user composes a message and chooses to send it at a later date or time, the supporting server stores the message in a mailbox with this attrib ute until the scheduled sending time. Once that time is reached, the server send s the message and typically moves it to the \Sent mailbox or delete it according to server policy.</t>
<t>This attribute standardizes the location of scheduled messages across clients, enabling users to review, edit, or cancel scheduled messages before th ey are sent, regardless of which client was used to schedule them.</t> <t>This attribute standardizes the location of scheduled messages across clients, enabling users to review, edit, or cancel scheduled messages before th ey are sent, regardless of which client was used to schedule them.</t>
<t>Supporting clients may present the contents of this mailbox in a way that highlights the scheduled sending time and allow users to modify or cancel s cheduled messages before they are sent.</t> <t>Supporting clients may present the contents of this mailbox in a way that highlights the scheduled sending time and allows users to modify or cancel scheduled messages before they are sent.</t>
</section> </section>
<section anchor="mailbox_memos"> <section anchor="mailbox_memos">
<name> <name>
<tt>Memos</tt> <tt>Memos</tt>
</name> </name>
<t>The <tt>Memos</tt> mailbox name attribute identifies a mailbox design ated for storing messages that have the <tt>$memo</tt> keyword. These messages a re user-created notes or annotations related to other messages.</t> <t>The <tt>Memos</tt> mailbox name attribute identifies a mailbox design ated for storing messages that have the <tt>$memo</tt> keyword. These messages a re user-created notes or annotations related to other messages.</t>
<t>When a user creates a memo (a note-to-self regarding another message) , clients <bcp14>SHOULD</bcp14> store these messages in a mailbox with this attr ibute. This separation allows clients to handle memos differently from regular m essages, presenting them as annotations rather than standalone communications.</ t> <t>When a user creates a memo (a note-to-self regarding another message) , clients <bcp14>SHOULD</bcp14> store these messages in a mailbox with this attr ibute. This separation allows clients to handle memos differently from regular m essages, presenting them as annotations rather than standalone communications.</ t>
<t>Storing memos in a designated mailbox helps prevent them from clutter ing the user's inbox or other message folders, while still maintaining them as p roper email messages for compatibility and synchronization purposes.</t> <t>Storing memos in a designated mailbox helps prevent them from clutter ing the user's inbox or other message folders, while still maintaining them as p roper email messages for compatibility and synchronization purposes.</t>
<t>Supporting clients <bcp14>MUST NOT</bcp14> present the contents of th is mailbox as regular messages in their interface, but instead <bcp14>MUST</bcp1 4> present them contextually alongside the messages they annotate when those mes sages are accessed.</t> <t>Supporting clients <bcp14>MUST NOT</bcp14> present the contents of th is mailbox as regular messages in their interface; instead, they <bcp14>MUST</bc p14> present them contextually alongside the messages they annotate when those m essages are accessed.</t>
</section> </section>
</section> </section>
<section anchor="IANA"> <section anchor="IANA">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>The following 17 IMAP/JMAP keywords are registered in the <em>IMAP and JMAP Keywords</em> registry, as established in <xref target="RFC5788"/>.</t> <t>The following 17 IMAP/JMAP keywords have been registered in the "IMAP a nd JMAP Keywords" registry, as established in <xref target="RFC5788"/>.</t>
<section anchor="imap-jmap-keyword-registrations"> <section anchor="imap-jmap-keyword-registrations">
<name>IMAP/JMAP Keyword Registrations</name> <name>IMAP/JMAP Keyword Registrations</name>
<!--[rfced] We had a few questions related to the IANA keyword
registrations:
a) We note that the template in RFC 5788 includes "Person & email
address to contact for further information:". This document does not
include this for any of the subsections of Section 9.1. We assume
this has been left off intentionally. If not, please let us know any
desired updates.
b) The template in RFC 5788 does not list "Scope". RFC 8621 lists it
before "Purpose (description)". Please let us know if any updates are
desirable to placement (i.e., should it be moved before Purpose or
follow Owner/Change controller?).
c) Related to the above, should "Purpose" be made "Purpose
(description)"?
d) The template in RFC 5788 contains the following:
Related keywords: (for example, "mutually exclusive with keywords Y
and Z")
We see the following in this document:
Section 4:
The $hasattachment and $hasnoattachment keywords are mutually
exclusive.
and Section 9.1.4 lists $hasnoattachment as a related keyword for
$hasattachment.
Please let us know if any updates should be made to either Section
9.1.4 to mention the mutual exclusivity or to Section 9.1.6 where
$hasnoattachment lists "Related keywords: None".
e) We see that the template in RFC 5788 lists "LIMITED USE" as a
possible value for Intended usage. Sections 9.1.12 and 9.1.15 use
"LIMITED" without "USE". Please let us know if an update should be
made.
f) The heading "Is it an advisory keyword or may it cause an automatic
action:" sounds like it must be one of those options (i.e., advisory
or automatic action). However, we see "No" for the following:
$MailFlagBit0
$MailFlagBit1
$MailFlagBit2
Please review and let us know if any updates are necessary.
g) In the following text, does the client also set the keyword during
message delivery (note that similar text occurs more than once):
Original:
When/by whom the keyword is set/cleared: It is set by the server
during message delivery, or by the client (if neither
$hasattachment nor $hasnoattachment are currently set).
Perhaps A:
When/by whom the keyword is set/cleared: It is set during message
delivery by the server or the client (if neither $hasattachment nor
$hasnoattachment is currently set).
Perhaps B:
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 are currently set).
-->
<section anchor="autosent-keyword-registration"> <section anchor="autosent-keyword-registration">
<name><tt>$autosent</tt> keyword registration</name> <name><tt>$autosent</tt> Keyword Registration</name>
<dl newline="false" spacing="compact">
<dl newline="false">
<dt>IMAP/JMAP keyword name:</dt> <dt>IMAP/JMAP keyword name:</dt>
<dd> <dd>
<tt>$autosent</tt> <tt>$autosent</tt>
</dd> </dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>Indicate to the client that a message was sent automatically as a response due to a user rule or setting.</dd> <dd>Indicate to the client that a message was sent automatically as a response due to a user rule or setting.</dd>
<dt>Private or Shared on a server:</dt> <dt>Private or Shared on a server:</dt>
<dd>SHARED</dd> <dd>SHARED</dd>
<dt>Is it an advisory keyword or may it cause an automatic action:</ dt> <dt>Is it an advisory keyword or may it cause an automatic action:</ dt>
<dd>This keyword is advisory.</dd> <dd>This keyword is advisory.</dd>
<dt>When/by whom the keyword is set/cleared:</dt> <dt>When/by whom the keyword is set/cleared:</dt>
<dd>This keyword is set by the server on delivery.</dd> <dd>This keyword is set by the server on delivery.</dd>
<dt>Related keywords:</dt> <dt>Related keywords:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Related IMAP capabilities:</dt> <dt>Related IMAP capabilities:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd>This document</dd> <dd>RFC 9979</dd>
<dt>Intended usage:</dt> <dt>Intended usage:</dt>
<dd>COMMON</dd> <dd>COMMON</dd>
<dt>Scope:</dt> <dt>Scope:</dt>
<dd>BOTH</dd> <dd>BOTH</dd>
<dt>Owner/Change controller:</dt> <dt>Owner/Change controller:</dt>
<dd>IESG</dd> <dd>IESG</dd>
</dl> </dl>
</section> </section>
<section anchor="canunsubscribe-keyword-registration"> <section anchor="canunsubscribe-keyword-registration">
<name><tt>$canunsubscribe</tt> keyword registration</name> <name><tt>$canunsubscribe</tt> Keyword Registration</name>
<dl newline="false" spacing="compact"> <dl newline="false">
<dt>IMAP/JMAP keyword name:</dt> <dt>IMAP/JMAP keyword name:</dt>
<dd> <dd>
<tt>$canunsubscribe</tt> <tt>$canunsubscribe</tt>
</dd> </dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>Indicate to the client that this message has an <xref target="RF C8058"/>-compliant List-Unsubscribe header.</dd> <dd>Indicate to the client that this message has a List-Unsubscribe header that is compliant with <xref target="RFC8058"/>.</dd>
<dt>Private or Shared on a server:</dt> <dt>Private or Shared on a server:</dt>
<dd>SHARED</dd> <dd>SHARED</dd>
<dt>Is it an advisory keyword or may it cause an automatic action:</ dt> <dt>Is it an advisory keyword or may it cause an automatic action:</ dt>
<dd>This keyword is advisory.</dd> <dd>This keyword is advisory.</dd>
<dt>When/by whom the keyword is set/cleared:</dt> <dt>When/by whom the keyword is set/cleared:</dt>
<dd>This keyword is set by the server on delivery.</dd> <dd>This keyword is set by the server on delivery.</dd>
<dt>Related keywords:</dt> <dt>Related keywords:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Related IMAP capabilities:</dt> <dt>Related IMAP capabilities:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd>This document</dd> <dd>RFC 9979</dd>
<dt>Intended usage:</dt> <dt>Intended usage:</dt>
<dd>COMMON</dd> <dd>COMMON</dd>
<dt>Scope:</dt> <dt>Scope:</dt>
<dd>BOTH</dd> <dd>BOTH</dd>
<dt>Owner/Change controller:</dt> <dt>Owner/Change controller:</dt>
<dd>IESG</dd> <dd>IESG</dd>
</dl> </dl>
</section> </section>
<section anchor="followed-keyword-registration"> <section anchor="followed-keyword-registration">
<name><tt>$followed</tt> keyword registration</name> <name><tt>$followed</tt> Keyword Registration</name>
<dl newline="false" spacing="compact"> <dl newline="false">
<dt>IMAP/JMAP keyword name:</dt> <dt>IMAP/JMAP keyword name:</dt>
<dd> <dd>
<tt>$followed</tt> <tt>$followed</tt>
</dd> </dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>Indicate to the server that the user is particularly interested in future replies to a particular thread.</dd> <dd>Indicate to the server that the user is particularly interested in future replies to a particular thread.</dd>
<dt>Private or Shared on a server:</dt> <dt>Private or Shared on a server:</dt>
<dd>SHARED</dd> <dd>SHARED</dd>
<dt>Is it an advisory keyword or may it cause an automatic action:</ dt> <dt>Is it an advisory keyword or may it cause an automatic action:</ dt>
<dd>This keyword can cause automatic action.</dd> <dd>This keyword can cause automatic action.</dd>
<dt>When/by whom the keyword is set/cleared:</dt> <dt>When/by whom the keyword is set/cleared:</dt>
<dd>This keyword is set and cleared by the client.</dd> <dd>This keyword is set and cleared by the client.</dd>
<dt>Related keywords:</dt> <dt>Related keywords:</dt>
<dd>Mutually exclusive with <tt>$muted</tt>. If both are specified o n a thread, servers MUST behave as though only <tt>$followed</tt> were set.</dd> <dd>Mutually exclusive with <tt>$muted</tt>. If both are specified o n a thread, servers <bcp14>MUST</bcp14> behave as though only <tt>$followed</tt> were set.</dd>
<dt>Related IMAP capabilities:</dt> <dt>Related IMAP capabilities:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd>This document</dd> <dd>RFC 9979</dd>
<dt>Intended usage:</dt> <dt>Intended usage:</dt>
<dd>COMMON</dd> <dd>COMMON</dd>
<dt>Scope:</dt> <dt>Scope:</dt>
<dd>BOTH</dd> <dd>BOTH</dd>
<dt>Owner/Change controller:</dt> <dt>Owner/Change controller:</dt>
<dd>IESG</dd> <dd>IESG</dd>
</dl> </dl>
</section> </section>
<section anchor="hasattachment-keyword-registration"> <section anchor="hasattachment-keyword-registration">
<name><tt>$hasattachment</tt> keyword registration</name> <name><tt>$hasattachment</tt> Keyword Registration</name>
<dl newline="false" spacing="compact"> <dl newline="false">
<dt>IMAP/JMAP keyword name:</dt> <dt>IMAP/JMAP keyword name:</dt>
<dd> <dd>
<tt>$hasattachment</tt> <tt>$hasattachment</tt>
</dd> </dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>Indicate to the client that a message has an attachment.</dd> <dd>Indicate to the client that a message has an attachment.</dd>
<dt>Private or Shared on a server:</dt> <dt>Private or Shared on a server:</dt>
<dd>SHARED</dd> <dd>SHARED</dd>
<dt>Is it an advisory keyword or may it cause an automatic action:</ dt> <dt>Is it an advisory keyword or may it cause an automatic action:</ dt>
<dd>This keyword is advisory.</dd> <dd>This keyword is advisory.</dd>
<dt>When/by whom the keyword is set/cleared:</dt> <dt>When/by whom the keyword is set/cleared:</dt>
<dd>It is set by the server during message delivery, or by the clien t (if neither $hasattachment nor $hasnoattachment are currently set).</dd> <dd>It is set by the server during message delivery or by the client (if neither $hasattachment nor $hasnoattachment is currently set).</dd>
<dt>Related keywords:</dt> <dt>Related keywords:</dt>
<dd> <dd>
<tt>$hasnoattachment</tt> <tt>$hasnoattachment</tt>
</dd> </dd>
<dt>Related IMAP capabilities:</dt> <dt>Related IMAP capabilities:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd>This document</dd> <dd>RFC 9979</dd>
<dt>Intended usage:</dt> <dt>Intended usage:</dt>
<dd>COMMON</dd> <dd>COMMON</dd>
<dt>Scope:</dt> <dt>Scope:</dt>
<dd>BOTH</dd> <dd>BOTH</dd>
<dt>Owner/Change controller:</dt> <dt>Owner/Change controller:</dt>
<dd>IESG</dd> <dd>IESG</dd>
</dl> </dl>
</section> </section>
<section anchor="hasmemo-keyword-registration"> <section anchor="hasmemo-keyword-registration">
<name><tt>$hasmemo</tt> keyword registration</name> <name><tt>$hasmemo</tt> Keyword Registration</name>
<dl newline="false" spacing="compact"> <dl newline="false">
<dt>IMAP/JMAP keyword name:</dt> <dt>IMAP/JMAP keyword name:</dt>
<dd> <dd>
<tt>$hasmemo</tt> <tt>$hasmemo</tt>
</dd> </dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>Indicate to the client that a message has an associated memo wit h the <tt>$memo</tt> keyword.</dd> <dd>Indicate to the client that a message has an associated memo wit h the <tt>$memo</tt> keyword.</dd>
<dt>Private or Shared on a server:</dt> <dt>Private or Shared on a server:</dt>
<dd>SHARED</dd> <dd>SHARED</dd>
<dt>Is it an advisory keyword or may it cause an automatic action:</ dt> <dt>Is it an advisory keyword or may it cause an automatic action:</ dt>
<dd>This keyword is advisory.</dd> <dd>This keyword is advisory.</dd>
<dt>When/by whom the keyword is set/cleared:</dt> <dt>When/by whom the keyword is set/cleared:</dt>
<dd>This keyword is set and cleared by the client based on user inte raction.</dd> <dd>This keyword is set and cleared by the client based on user inte raction.</dd>
<dt>Related keywords:</dt> <dt>Related keywords:</dt>
<dd>The <tt>$memo</tt> and <tt>$hasmemo</tt> keywords are mutually e xclusive.</dd> <dd>The <tt>$memo</tt> and <tt>$hasmemo</tt> keywords are mutually e xclusive.</dd>
<dt>Related IMAP capabilities:</dt> <dt>Related IMAP capabilities:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd>This document</dd> <dd>RFC 9979</dd>
<dt>Intended usage:</dt> <dt>Intended usage:</dt>
<dd>COMMON</dd> <dd>COMMON</dd>
<dt>Scope:</dt> <dt>Scope:</dt>
<dd>BOTH</dd> <dd>BOTH</dd>
<dt>Owner/Change controller:</dt> <dt>Owner/Change controller:</dt>
<dd>IESG</dd> <dd>IESG</dd>
</dl> </dl>
</section> </section>
<section anchor="hasnoattachment-keyword-registration"> <section anchor="hasnoattachment-keyword-registration">
<name><tt>$hasnoattachment</tt> keyword registration</name> <name><tt>$hasnoattachment</tt> Keyword Registration</name>
<dl newline="false" spacing="compact"> <dl newline="false">
<dt>IMAP/JMAP keyword name:</dt> <dt>IMAP/JMAP keyword name:</dt>
<dd> <dd>
<tt>$hasnoattachment</tt> <tt>$hasnoattachment</tt>
</dd> </dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>Indicate to the client that a message does not have an attachmen t.</dd> <dd>Indicate to the client that a message does not have an attachmen t.</dd>
<dt>Private or Shared on a server:</dt> <dt>Private or Shared on a server:</dt>
<dd>SHARED</dd> <dd>SHARED</dd>
<dt>Is it an advisory keyword or may it cause an automatic action:</ dt> <dt>Is it an advisory keyword or may it cause an automatic action:</ dt>
<dd>This keyword is advisory.</dd> <dd>This keyword is advisory.</dd>
<dt>When/by whom the keyword is set/cleared:</dt> <dt>When/by whom the keyword is set/cleared:</dt>
<dd>It is set by the server during message delivery, or by the clien t (if neither $hasattachment nor $hasnoattachment are currently set).</dd> <dd>It is set by the server during message delivery, or by the clien t (if neither $hasattachment nor $hasnoattachment is currently set).</dd>
<dt>Related keywords:</dt> <dt>Related keywords:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Related IMAP capabilities:</dt> <dt>Related IMAP capabilities:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd>This document</dd> <dd>RFC 9979</dd>
<dt>Intended usage:</dt> <dt>Intended usage:</dt>
<dd>COMMON</dd> <dd>COMMON</dd>
<dt>Scope:</dt> <dt>Scope:</dt>
<dd>BOTH</dd> <dd>BOTH</dd>
<dt>Owner/Change controller:</dt> <dt>Owner/Change controller:</dt>
<dd>IESG</dd> <dd>IESG</dd>
</dl> </dl>
</section> </section>
<section anchor="imported-keyword-registration"> <section anchor="imported-keyword-registration">
<name><tt>$imported</tt> keyword registration</name> <name><tt>$imported</tt> Keyword Registration</name>
<dl newline="false" spacing="compact"> <dl newline="false">
<dt>IMAP/JMAP keyword name:</dt> <dt>IMAP/JMAP keyword name:</dt>
<dd> <dd>
<tt>$imported</tt> <tt>$imported</tt>
</dd> </dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>Indicate to the client that this message was imported from anoth er mailbox.</dd> <dd>Indicate to the client that this message was imported from anoth er mailbox.</dd>
<dt>Private or Shared on a server:</dt> <dt>Private or Shared on a server:</dt>
<dd>SHARED</dd> <dd>SHARED</dd>
<dt>Is it an advisory keyword or may it cause an automatic action:</ dt> <dt>Is it an advisory keyword or may it cause an automatic action:</ dt>
<dd>This keyword is advisory.</dd> <dd>This keyword is advisory.</dd>
<dt>When/by whom the keyword is set/cleared:</dt> <dt>When/by whom the keyword is set/cleared:</dt>
<dd>This keyword is set by the server on delivery.</dd> <dd>This keyword is set by the server on delivery.</dd>
<dt>Related keywords:</dt> <dt>Related keywords:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Related IMAP capabilities:</dt> <dt>Related IMAP capabilities:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd>This document</dd> <dd>RFC 9979</dd>
<dt>Intended usage:</dt> <dt>Intended usage:</dt>
<dd>COMMON</dd> <dd>COMMON</dd>
<dt>Scope:</dt> <dt>Scope:</dt>
<dd>BOTH</dd> <dd>BOTH</dd>
<dt>Owner/Change controller:</dt> <dt>Owner/Change controller:</dt>
<dd>IESG</dd> <dd>IESG</dd>
</dl> </dl>
</section> </section>
<section anchor="istrusted-keyword-registration"> <section anchor="istrusted-keyword-registration">
<name><tt>$istrusted</tt> keyword registration</name> <name><tt>$istrusted</tt> Keyword Registration</name>
<dl newline="false" spacing="compact"> <dl newline="false">
<dt>IMAP/JMAP keyword name:</dt> <dt>IMAP/JMAP keyword name:</dt>
<dd> <dd>
<tt>$istrusted</tt> <tt>$istrusted</tt>
</dd> </dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>Indicate to the client that the authenticity of the from name an d email address have been verified by the server.</dd> <dd>Indicate to the client that the authenticity of the from name an d email address have been verified by the server.</dd>
<dt>Private or Shared on a server:</dt> <dt>Private or Shared on a server:</dt>
<dd>SHARED</dd> <dd>SHARED</dd>
<dt>Is it an advisory keyword or may it cause an automatic action:</ dt> <dt>Is it an advisory keyword or may it cause an automatic action:</ dt>
<dd>This keyword is advisory.</dd> <dd>This keyword is advisory.</dd>
<dt>When/by whom the keyword is set/cleared:</dt> <dt>When/by whom the keyword is set/cleared:</dt>
<dd>This keyword is set by the server on delivery.</dd> <dd>This keyword is set by the server on delivery.</dd>
<dt>Related keywords:</dt> <dt>Related keywords:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Related IMAP capabilities:</dt> <dt>Related IMAP capabilities:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd>Servers should make sure this keyword is only set for messages t hat really are trusted.</dd> <dd>Servers should make sure this keyword is only set for messages t hat really are trusted.</dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd>This document</dd> <dd>RFC 9979</dd>
<dt>Intended usage:</dt> <dt>Intended usage:</dt>
<dd>COMMON</dd> <dd>COMMON</dd>
<dt>Scope:</dt> <dt>Scope:</dt>
<dd>BOTH</dd> <dd>BOTH</dd>
<dt>Owner/Change controller:</dt> <dt>Owner/Change controller:</dt>
<dd>IESG</dd> <dd>IESG</dd>
</dl> </dl>
</section> </section>
<section anchor="mailflagbit0-keyword-registration"> <section anchor="mailflagbit0-keyword-registration">
<name><tt>$MailFlagBit0</tt> keyword registration</name> <name><tt>$MailFlagBit0</tt> Keyword Registration</name>
<dl newline="false" spacing="compact"> <dl newline="false">
<dt>IMAP/JMAP keyword name:</dt> <dt>IMAP/JMAP keyword name:</dt>
<dd> <dd>
<tt>$MailFlagBit0</tt> <tt>$MailFlagBit0</tt>
</dd> </dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>Bit 0 part of a 3-bit bitmask that defines the color of the flag when the message has the system flag <tt>\Flagged</tt> set. See <xref target="m ailflagbits"/> for details.</dd> <dd>Bit 0 part of a 3-bit bitmask that defines the color of the flag when the message has the system flag <tt>\Flagged</tt> set. See <xref target="m ailflagbits"/> for details.</dd>
<dt>Private or Shared on a server:</dt> <dt>Private or Shared on a server:</dt>
<dd>SHARED</dd> <dd>SHARED</dd>
<dt>Is it an advisory keyword or may it cause an automatic action:</ dt> <dt>Is it an advisory keyword or may it cause an automatic action:</ dt>
<dd>No</dd> <dd>No</dd>
<dt>When/by whom the keyword is set/cleared:</dt> <dt>When/by whom the keyword is set/cleared:</dt>
<dd>This keyword is set by a client as the result of a user action t o "flag" a message for urgent/special attention.</dd> <dd>This keyword is set by a client as the result of a user action t o "flag" a message as urgent / in need of special attention.</dd>
<dt>Related keywords:</dt> <dt>Related keywords:</dt>
<dd><tt>$MailFlagBit1</tt>, <tt>$MailFlagBit2</tt></dd> <dd><tt>$MailFlagBit1</tt>, <tt>$MailFlagBit2</tt></dd>
<dt>Related IMAP capabilities:</dt> <dt>Related IMAP capabilities:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd>This document</dd> <dd>RFC 9979</dd>
<dt>Intended usage:</dt> <dt>Intended usage:</dt>
<dd>COMMON</dd> <dd>COMMON</dd>
<dt>Scope:</dt> <dt>Scope:</dt>
<dd>BOTH</dd> <dd>BOTH</dd>
<dt>Owner/Change controller:</dt> <dt>Owner/Change controller:</dt>
<dd>IESG</dd> <dd>IESG</dd>
</dl> </dl>
</section> </section>
<section anchor="mailflagbit1-keyword-registration"> <section anchor="mailflagbit1-keyword-registration">
<name><tt>$MailFlagBit1</tt> keyword registration</name> <name><tt>$MailFlagBit1</tt> Keyword Registration</name>
<dl newline="false" spacing="compact"> <dl newline="false">
<dt>IMAP/JMAP keyword name:</dt> <dt>IMAP/JMAP keyword name:</dt>
<dd> <dd>
<tt>$MailFlagBit1</tt> <tt>$MailFlagBit1</tt>
</dd> </dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>Bit 1 part of a 3-bit bitmask that defines the color of the flag when the message has the system flag <tt>\Flagged</tt> set. See <xref target="m ailflagbits"/> for details.</dd> <dd>Bit 1 part of a 3-bit bitmask that defines the color of the flag when the message has the system flag <tt>\Flagged</tt> set. See <xref target="m ailflagbits"/> for details.</dd>
<dt>Private or Shared on a server:</dt> <dt>Private or Shared on a server:</dt>
<dd>SHARED</dd> <dd>SHARED</dd>
<dt>Is it an advisory keyword or may it cause an automatic action:</ dt> <dt>Is it an advisory keyword or may it cause an automatic action:</ dt>
<dd>No</dd> <dd>No</dd>
<dt>When/by whom the keyword is set/cleared:</dt> <dt>When/by whom the keyword is set/cleared:</dt>
<dd>This keyword is set by a client as the result of a user action t o "flag" a message for urgent/special attention.</dd> <dd>This keyword is set by a client as the result of a user action t o "flag" a message as urgent / in need of special attention.</dd>
<dt>Related keywords:</dt> <dt>Related keywords:</dt>
<dd><tt>$MailFlagBit0</tt>, <tt>$MailFlagBit2</tt></dd> <dd><tt>$MailFlagBit0</tt>, <tt>$MailFlagBit2</tt></dd>
<dt>Related IMAP capabilities:</dt> <dt>Related IMAP capabilities:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd>This document</dd> <dd>RFC 9979</dd>
<dt>Intended usage:</dt> <dt>Intended usage:</dt>
<dd>COMMON</dd> <dd>COMMON</dd>
<dt>Scope:</dt> <dt>Scope:</dt>
<dd>BOTH</dd> <dd>BOTH</dd>
<dt>Owner/Change controller:</dt> <dt>Owner/Change controller:</dt>
<dd>IESG</dd> <dd>IESG</dd>
</dl> </dl>
</section> </section>
<section anchor="mailflagbit2-keyword-registration"> <section anchor="mailflagbit2-keyword-registration">
<name><tt>$MailFlagBit2</tt> keyword registration</name> <name><tt>$MailFlagBit2</tt> Keyword Registration</name>
<dl newline="false" spacing="compact"> <dl newline="false">
<dt>IMAP/JMAP keyword name:</dt> <dt>IMAP/JMAP keyword name:</dt>
<dd> <dd>
<tt>$MailFlagBit2</tt> <tt>$MailFlagBit2</tt>
</dd> </dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>Bit 2 part of a 3-bit bitmask that defines the color of the flag when the message has the system flag <tt>\Flagged</tt> set. See <xref target="m ailflagbits"/> for details.</dd> <dd>Bit 2 part of a 3-bit bitmask that defines the color of the flag when the message has the system flag <tt>\Flagged</tt> set. See <xref target="m ailflagbits"/> for details.</dd>
<dt>Private or Shared on a server:</dt> <dt>Private or Shared on a server:</dt>
<dd>SHARED</dd> <dd>SHARED</dd>
<dt>Is it an advisory keyword or may it cause an automatic action:</ dt> <dt>Is it an advisory keyword or may it cause an automatic action:</ dt>
<dd>No</dd> <dd>No</dd>
<dt>When/by whom the keyword is set/cleared:</dt> <dt>When/by whom the keyword is set/cleared:</dt>
<dd>This keyword is set by a client as the result of a user action t o "flag" a message for urgent/special attention.</dd> <dd>This keyword is set by a client as the result of a user action t o "flag" a message as urgent / in need of special attention.</dd>
<dt>Related keywords:</dt> <dt>Related keywords:</dt>
<dd><tt>$MailFlagBit0</tt>, <tt>$MailFlagBit1</tt></dd> <dd><tt>$MailFlagBit0</tt>, <tt>$MailFlagBit1</tt></dd>
<dt>Related IMAP capabilities:</dt> <dt>Related IMAP capabilities:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd>This document</dd> <dd>RFC 9979</dd>
<dt>Intended usage:</dt> <dt>Intended usage:</dt>
<dd>COMMON</dd> <dd>COMMON</dd>
<dt>Scope:</dt> <dt>Scope:</dt>
<dd>BOTH</dd> <dd>BOTH</dd>
<dt>Owner/Change controller:</dt> <dt>Owner/Change controller:</dt>
<dd>IESG</dd> <dd>IESG</dd>
</dl> </dl>
</section> </section>
<section anchor="maskedemail-keyword-registration"> <section anchor="maskedemail-keyword-registration">
<name><tt>$maskedemail</tt> keyword registration</name> <name><tt>$maskedemail</tt> Keyword Registration</name>
<dl newline="false" spacing="compact"> <dl newline="false">
<dt>IMAP/JMAP keyword name:</dt> <dt>IMAP/JMAP keyword name:</dt>
<dd> <dd>
<tt>$maskedemail</tt> <tt>$maskedemail</tt>
</dd> </dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>Indicate to the client that the message was received via an alia s created for an individual sender.</dd> <dd>Indicate to the client that the message was received via an alia s created for an individual sender.</dd>
<dt>Private or Shared on a server:</dt> <dt>Private or Shared on a server:</dt>
<dd>SHARED</dd> <dd>SHARED</dd>
<dt>Is it an advisory keyword or may it cause an automatic action:</ dt> <dt>Is it an advisory keyword or may it cause an automatic action:</ dt>
<dd>This keyword is advisory.</dd> <dd>This keyword is advisory.</dd>
<dt>When/by whom the keyword is set/cleared:</dt> <dt>When/by whom the keyword is set/cleared:</dt>
<dd>This keyword is set by the server on delivery.</dd> <dd>This keyword is set by the server on delivery.</dd>
<dt>Related keywords:</dt> <dt>Related keywords:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Related IMAP capabilities:</dt> <dt>Related IMAP capabilities:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd>This document</dd> <dd>RFC 9979</dd>
<dt>Intended usage:</dt> <dt>Intended usage:</dt>
<dd>LIMITED</dd> <dd>LIMITED</dd>
<dt>Scope:</dt> <dt>Scope:</dt>
<dd>BOTH</dd> <dd>BOTH</dd>
<dt>Owner/Change controller:</dt> <dt>Owner/Change controller:</dt>
<dd>IESG</dd> <dd>IESG</dd>
</dl> </dl>
</section> </section>
<section anchor="memo-keyword-registration"> <section anchor="memo-keyword-registration">
<name><tt>$memo</tt> keyword registration</name> <name><tt>$memo</tt> Keyword Registration</name>
<dl newline="false" spacing="compact"> <dl newline="false">
<dt>IMAP/JMAP keyword name:</dt> <dt>IMAP/JMAP keyword name:</dt>
<dd> <dd>
<tt>$memo</tt> <tt>$memo</tt>
</dd> </dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>Indicate to the client that a message is a note-to-self from the user regarding another message in the same thread.</dd> <dd>Indicate to the client that a message is a note-to-self from the user regarding another message in the same thread.</dd>
<dt>Private or Shared on a server:</dt> <dt>Private or Shared on a server:</dt>
<dd>SHARED</dd> <dd>SHARED</dd>
<dt>Is it an advisory keyword or may it cause an automatic action:</ dt> <dt>Is it an advisory keyword or may it cause an automatic action:</ dt>
<dd>This keyword is advisory.</dd> <dd>This keyword is advisory.</dd>
<dt>When/by whom the keyword is set/cleared:</dt> <dt>When/by whom the keyword is set/cleared:</dt>
<dd>This keyword is set and cleared by the client based on user inte raction.</dd> <dd>This keyword is set and cleared by the client based on user inte raction.</dd>
<dt>Related keywords:</dt> <dt>Related keywords:</dt>
<dd>The <tt>$memo</tt> and <tt>$hasmemo</tt> keywords are mutually e xclusive.</dd> <dd>The <tt>$memo</tt> and <tt>$hasmemo</tt> keywords are mutually e xclusive.</dd>
<dt>Related IMAP capabilities:</dt> <dt>Related IMAP capabilities:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd>This document</dd> <dd>RFC 9979</dd>
<dt>Intended usage:</dt> <dt>Intended usage:</dt>
<dd>COMMON</dd> <dd>COMMON</dd>
<dt>Scope:</dt> <dt>Scope:</dt>
<dd>BOTH</dd> <dd>BOTH</dd>
<dt>Owner/Change controller:</dt> <dt>Owner/Change controller:</dt>
<dd>IESG</dd> <dd>IESG</dd>
</dl> </dl>
</section> </section>
<section anchor="muted-keyword-registration"> <section anchor="muted-keyword-registration">
<name><tt>$muted</tt> keyword registration</name> <name><tt>$muted</tt> Keyword Registration</name>
<dl newline="false" spacing="compact"> <dl newline="false">
<dt>IMAP/JMAP keyword name:</dt> <dt>IMAP/JMAP keyword name:</dt>
<dd> <dd>
<tt>$muted</tt> <tt>$muted</tt>
</dd> </dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>Indicate to the server that the user is not interested in future replies to a particular thread.</dd> <dd>Indicate to the server that the user is not interested in future replies to a particular thread.</dd>
<dt>Private or Shared on a server:</dt> <dt>Private or Shared on a server:</dt>
<dd>SHARED</dd> <dd>SHARED</dd>
<dt>Is it an advisory keyword or may it cause an automatic action:</ dt> <dt>Is it an advisory keyword or may it cause an automatic action:</ dt>
<dd>This keyword can cause an automatic action.</dd> <dd>This keyword can cause an automatic action.</dd>
<dt>When/by whom the keyword is set/cleared:</dt> <dt>When/by whom the keyword is set/cleared:</dt>
<dd>This keyword is set and cleared by the client.</dd> <dd>This keyword is set and cleared by the client.</dd>
<dt>Related keywords:</dt> <dt>Related keywords:</dt>
<dd>Mutually exclusive with <tt>$followed</tt>. If both are specifie d on a thread, servers MUST behave as though only <tt>$followed</tt> were set.</ dd> <dd>Mutually exclusive with <tt>$followed</tt>. If both are specifie d on a thread, servers <bcp14>MUST</bcp14> behave as though only <tt>$followed</ tt> were set.</dd>
<dt>Related IMAP capabilities:</dt> <dt>Related IMAP capabilities:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd>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 wa nt the user to be notified of the reply, for example when sending phishing to th e user's contacts. There are many other ways an attacker with access to the user 's mailbox can also achieve this however, 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/revert mute actions that may have been taken by the attacker.</dd> <dd>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 wa nt the user to be notified of the reply, for example, when sending phishing to t he user's contacts. However, there are many other ways an attacker with access t o the user's mailbox can also achieve this, so this is not greatly increasing th e attack surface. When restoring legitimate access to a stolen account, care mus t be taken to find and confirm or revert mute actions that may have been taken b y the attacker.</dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd>This document</dd> <dd>RFC 9979</dd>
<dt>Intended usage:</dt> <dt>Intended usage:</dt>
<dd>COMMON</dd> <dd>COMMON</dd>
<dt>Scope:</dt> <dt>Scope:</dt>
<dd>BOTH</dd> <dd>BOTH</dd>
<dt>Owner/Change controller:</dt> <dt>Owner/Change controller:</dt>
<dd>IESG</dd> <dd>IESG</dd>
</dl> </dl>
</section> </section>
<section anchor="new-keyword-registration"> <section anchor="new-keyword-registration">
<name><tt>$new</tt> keyword registration</name> <name><tt>$new</tt> Keyword Registration</name>
<dl newline="false" spacing="compact"> <dl newline="false">
<dt>IMAP/JMAP keyword name:</dt> <dt>IMAP/JMAP keyword name:</dt>
<dd> <dd>
<tt>$new</tt> <tt>$new</tt>
</dd> </dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>Indicate to the client that a message should be made more promin ent to the user due to a recent action.</dd> <dd>Indicate to the client that a message should be made more promin ent to the user due to a recent action.</dd>
<dt>Private or Shared on a server:</dt> <dt>Private or Shared on a server:</dt>
<dd>SHARED</dd> <dd>SHARED</dd>
<dt>Is it an advisory keyword or may it cause an automatic action:</ dt> <dt>Is it an advisory keyword or may it cause an automatic action:</ dt>
<dd>This keyword is advisory.</dd> <dd>This keyword is advisory.</dd>
<dt>When/by whom the keyword is set/cleared:</dt> <dt>When/by whom the keyword is set/cleared:</dt>
<dd>This keyword is set by the server. Clients can clear the keyword based on user interaction.</dd> <dd>This keyword is set by the server. Clients can clear the keyword based on user interaction.</dd>
<dt>Related keywords:</dt> <dt>Related keywords:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Related IMAP capabilities:</dt> <dt>Related IMAP capabilities:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd>This document</dd> <dd>RFC 9979</dd>
<dt>Intended usage:</dt> <dt>Intended usage:</dt>
<dd>LIMITED</dd> <dd>LIMITED</dd>
<dt>Scope:</dt> <dt>Scope:</dt>
<dd>BOTH</dd> <dd>BOTH</dd>
<dt>Owner/Change controller:</dt> <dt>Owner/Change controller:</dt>
<dd>IESG</dd> <dd>IESG</dd>
</dl> </dl>
</section> </section>
<section anchor="notify-keyword-registration"> <section anchor="notify-keyword-registration">
<name><tt>$notify</tt> keyword registration</name> <name><tt>$notify</tt> Keyword Registration</name>
<dl newline="false" spacing="compact"> <dl newline="false">
<dt>IMAP/JMAP keyword name:</dt> <dt>IMAP/JMAP keyword name:</dt>
<dd> <dd>
<tt>$notify</tt> <tt>$notify</tt>
</dd> </dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>Indicate to the client that a notification should be presented f or this message.</dd> <dd>Indicate to the client that a notification should be presented f or this message.</dd>
<dt>Private or Shared on a server:</dt> <dt>Private or Shared on a server:</dt>
<dd>SHARED</dd> <dd>SHARED</dd>
<dt>Is it an advisory keyword or may it cause an automatic action:</ dt> <dt>Is it an advisory keyword or may it cause an automatic action:</ dt>
<dd>This keyword can cause an automatic action.</dd> <dd>This keyword can cause an automatic action.</dd>
<dt>When/by whom the keyword is set/cleared:</dt> <dt>When/by whom the keyword is set/cleared:</dt>
<dd>This keyword is set by the server on delivery when a message mee ts certain criteria. It may be cleared by a client when the user interacts with the message.</dd> <dd>This keyword is set by the server on delivery when a message mee ts certain criteria. It may be cleared by a client when the user interacts with the message.</dd>
<dt>Related keywords:</dt> <dt>Related keywords:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Related IMAP capabilities:</dt> <dt>Related IMAP capabilities:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd>This document</dd> <dd>RFC 9979</dd>
<dt>Intended usage:</dt> <dt>Intended usage:</dt>
<dd>COMMON</dd> <dd>COMMON</dd>
<dt>Scope:</dt> <dt>Scope:</dt>
<dd>BOTH</dd> <dd>BOTH</dd>
<dt>Owner/Change controller:</dt> <dt>Owner/Change controller:</dt>
<dd>IESG</dd> <dd>IESG</dd>
</dl> </dl>
</section> </section>
<section anchor="unsubscribed-keyword-registration"> <section anchor="unsubscribed-keyword-registration">
<name><tt>$unsubscribed</tt> keyword registration</name> <name><tt>$unsubscribed</tt> Keyword Registration</name>
<dl newline="false" spacing="compact"> <dl newline="false">
<dt>IMAP/JMAP keyword name:</dt> <dt>IMAP/JMAP keyword name:</dt>
<dd> <dd>
<tt>$unsubscribed</tt> <tt>$unsubscribed</tt>
</dd> </dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>Indicate the client has attempted to unsubscribe from the mailin g list this message is from.</dd> <dd>Indicate the client has attempted to unsubscribe from the mailin g list this message is from.</dd>
<dt>Private or Shared on a server:</dt> <dt>Private or Shared on a server:</dt>
<dd>SHARED</dd> <dd>SHARED</dd>
<dt>Is it an advisory keyword or may it cause an automatic action:</ dt> <dt>Is it an advisory keyword or may it cause an automatic action:</ dt>
<dd>This keyword is advisory.</dd> <dd>This keyword is advisory.</dd>
<dt>When/by whom the keyword is set/cleared:</dt> <dt>When/by whom the keyword is set/cleared:</dt>
<dd>This keyword is set by the client based on user interaction.</dd > <dd>This keyword is set by the client based on user interaction.</dd >
<dt>Related keywords:</dt> <dt>Related keywords:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Related IMAP capabilities:</dt> <dt>Related IMAP capabilities:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd>None</dd> <dd>None</dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd>This document</dd> <dd>RFC 9979</dd>
<dt>Intended usage:</dt> <dt>Intended usage:</dt>
<dd>COMMON</dd> <dd>COMMON</dd>
<dt>Scope:</dt> <dt>Scope:</dt>
<dd>BOTH</dd> <dd>BOTH</dd>
<dt>Owner/Change controller:</dt> <dt>Owner/Change controller:</dt>
<dd>IESG</dd> <dd>IESG</dd>
</dl> </dl>
</section> </section>
</section> </section>
<section anchor="imap-jmap-mailbox-name-registrations"> <section anchor="imap-jmap-mailbox-name-registrations">
<name>IMAP Mailbox Name Attributes Registrations</name> <name>IMAP Mailbox Name Attributes Registrations</name>
<t>The following 3 IMAP/JMAP mailbox name attributes are registered in t he IMAP Mailbox Name Attributes Registry, as established in <xref target="RFC845 7"/>.</t> <t>The following three IMAP/JMAP mailbox name attributes have been regis tered in the "IMAP Mailbox Name Attributes" registry, as established by <xref ta rget="RFC8457"/>.</t>
<t>Note that none of the attributes in this section have an implied back slash. This sets them apart from those specified in <xref target="RFC6154" secti onFormat="of" section="2"/>.</t> <t>Note that none of the attributes in this section have an implied back slash. This sets them apart from those specified in <xref target="RFC6154" secti onFormat="of" section="2"/>.</t>
<section anchor="snoozed-mailbox-name-attribute-registration"> <section anchor="snoozed-mailbox-name-attribute-registration">
<name><tt>Snoozed</tt> mailbox name attribute registration</name> <name><tt>Snoozed</tt> Mailbox Name Attribute Registration</name>
<dl newline="false" spacing="compact"> <dl newline="false">
<dt>Attribute Name:</dt> <dt>Attribute Name:</dt>
<dd>Snoozed</dd> <dd>Snoozed</dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd>Identifies the mailbox where temporarily snoozed messages are st ored.</dd> <dd>Identifies the mailbox where temporarily snoozed messages are st ored.</dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd>This document.</dd> <dd>RFC 9979</dd>
</dl> </dl>
</section> </section>
<section anchor="scheduled-mailbox-name-attribute-registration"> <section anchor="scheduled-mailbox-name-attribute-registration">
<name><tt>Scheduled</tt> mailbox name attribute registration</name> <name><tt>Scheduled</tt> Mailbox Name Attribute Registration</name>
<dl newline="false" spacing="compact"> <dl newline="false">
<dt>Attribute Name:</dt> <dt>Attribute Name:</dt>
<dd>Scheduled</dd> <dd>Scheduled</dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd>Identifies the mailbox where messages scheduled to be sent at a later time are stored.</dd> <dd>Identifies the mailbox where messages scheduled to be sent at a later time are stored.</dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd>This document.</dd> <dd>RFC 9979</dd>
</dl> </dl>
</section> </section>
<section anchor="memos-mailbox-name-attribute-registration"> <section anchor="memos-mailbox-name-attribute-registration">
<name><tt>Memos</tt> mailbox name attribute registration</name> <name><tt>Memos</tt> Mailbox Name Attribute Registration</name>
<dl newline="false" spacing="compact"> <dl newline="false">
<dt>Attribute Name:</dt> <dt>Attribute Name:</dt>
<dd>Memos</dd> <dd>Memos</dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd>Identifies the mailbox where user-created memo messages are stor ed.</dd> <dd>Identifies the mailbox where user-created memo messages are stor ed.</dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd>This document.</dd> <dd>RFC 9979</dd>
</dl> </dl>
</section> </section>
</section> </section>
</section> </section>
<section anchor="Security"> <section anchor="Security">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The security considerations for the <tt>$istrusted</tt> and <tt>$muted< /tt> keywords are described in <t>The security considerations for the <tt>$istrusted</tt> and <tt>$muted< /tt> keywords are described in
<xref target="istrusted-keyword-registration"/>, <xref target="other_i strusted" />, and <xref target="muted-keyword-registration"/> respectively.</t> Sections <xref target="istrusted-keyword-registration" format="counter" />, <xref target="other_istrusted" format="counter"/>, and <xref target="muted-k eyword-registration" format="counter"/>, respectively.</t>
<t>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 coul d set these keywords incorrectly or manipulate them to mislead users. For additi onal security considerations related to IMAP, refer to <xref target="RFC9051"/>. </t> <t>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 coul d set these keywords incorrectly or manipulate them to mislead users. For additi onal security considerations related to IMAP, refer to <xref target="RFC9051"/>. </t>
<t>Besides that this document should not affect the security of the Intern et.</t> <t>Otherwise, this document should not affect the security of the Internet .</t>
</section> </section>
</middle> </middle>
<back> <back>
<references>
<name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5 788.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5 788.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6 154.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6 154.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 058.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 058.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 457.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 457.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 474.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 474.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 621.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 621.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 051.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 051.xml"/>
</references> </references>
</references>
<!--[rfced] We had the following questions/comments related to
abbreviation use throughout the document:
a) We have expanded abbreviations upon first use. Please review for accuracy.
-->
<!--[rfced] We had the following questions related to special text
marking throughout the file:
We see both <tt>$hasnoattachment</tt> and $hasnoattachment.
We see both <tt>$hasattachment</tt> and $hasattachment.
Note: the unmarked version appears in the (recurring) sentence "if neither $hasa
ttachment nor $hasnoattachment is currently set".
Please review and confirm that these appear as desired.
-->
<!--[rfced] We had the following question regarding terminology used
throughout the document:
We see "hasAttachment" Email property. Please confirm that the capping
scheme here should not match other uses (i.e., it should not be
"hasattachment"). -->
<!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this
nature typically result in more precise language, which is
helpful for readers.
Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice.
-->
<!--[rfced] A note to Neil: we have updated your initials in the
header to simply your first initial to match use in RFC 9670.
Please let us know if you'd prefer otherwise. -->
</back> </back>
</rfc> </rfc>
 End of changes. 88 change blocks. 
165 lines changed or deleted 289 lines changed or added

This html diff was produced by rfcdiff 1.48.