7Internet Engineering Task Force (IETF) B. Leiba, Ed.
8Request for Comments: 8457 Huawei Technologies
9Category: Standards Track September 2018
13 IMAP "$Important" Keyword and "\Important" Special-Use Attribute
17 RFC 6154 created an IMAP special-use LIST extension and defined an
18 initial set of attributes. This document defines a new attribute,
19 "\Important", and establishes a new IANA registry for IMAP folder
20 attributes, which include the attributes defined in RFCs 5258, 3501,
21 and 6154. This document also defines a new IMAP keyword,
22 "$Important", and registers it in the registry defined in RFC 5788.
26 This is an Internet Standards Track document.
28 This document is a product of the Internet Engineering Task Force
29 (IETF). It represents the consensus of the IETF community. It has
30 received public review and has been approved for publication by the
31 Internet Engineering Steering Group (IESG). Further information on
32 Internet Standards is available in Section 2 of RFC 7841.
34 Information about the current status of this document, any errata,
35 and how to provide feedback on it may be obtained at
36 https://www.rfc-editor.org/info/rfc8457.
40 Copyright (c) 2018 IETF Trust and the persons identified as the
41 document authors. All rights reserved.
43 This document is subject to BCP 78 and the IETF Trust's Legal
44 Provisions Relating to IETF Documents
45 (https://trustee.ietf.org/license-info) in effect on the date of
46 publication of this document. Please review these documents
47 carefully, as they describe your rights and restrictions with respect
48 to this document. Code Components extracted from this document must
49 include Simplified BSD License text as described in Section 4.e of
50 the Trust Legal Provisions and are provided without warranty as
51 described in the Simplified BSD License.
58Leiba Standards Track [Page 1]
60RFC 8457 IMAP "Important" Keyword and Attribute September 2018
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
66 1.1. Conventions Used in This Document . . . . . . . . . . . . . 3
67 2. Definition of the "$Important" Message Keyword . . . . . . . 3
68 3. Definition of the 'Important' Mailbox Attribute . . . . . . . 3
69 3.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 4
70 3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4
71 3.2.1. Example of a LIST Response . . . . . . . . . . . . . . . 4
72 3.2.2. Examples of Creating a New Mailbox Using "\Important" . . 4
73 4. Implementation Notes . . . . . . . . . . . . . . . . . . . . 5
74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
76 6.1. Registration of the "$Important" Keyword . . . . . . . . . 6
77 6.2. Creation of the IMAP Mailbox Name Attributes Registry . . . 7
78 6.2.1. Instructions to the Designated Expert . . . . . . . . . . 8
79 6.3. Initial Entries for the IMAP Mailbox Name Attributes
80 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 9
81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
82 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
83 7.2. Informative References . . . . . . . . . . . . . . . . . . 10
84 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11
85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
89 The Internet Message Access Protocol (IMAP) specification [RFC3501]
90 defines the use of message keywords, and an "IMAP Keywords" registry
91 is created in [RFC5788]. [RFC6154] defines an extension to the IMAP
92 LIST command for special-use mailboxes. The extension allows servers
93 to provide extra information (attributes) about the purpose of a
94 mailbox and defines an initial set of special-use attributes.
96 This document does the following:
98 o defines a new message keyword, "$Important", to apply to messages
99 that are considered important for the user by some externally
102 o registers the "$Important" keyword in the "IMAP Keywords"
105 o defines a new special-use attribute, "\Important", to designate a
106 mailbox that will hold messages that are considered important for
107 the user by some externally defined criteria; and
114Leiba Standards Track [Page 2]
116RFC 8457 IMAP "Important" Keyword and Attribute September 2018
119 o creates a registry for IMAP mailbox attributes and registers the
120 new attribute and those defined in [RFC5258], [RFC3501], and
1231.1. Conventions Used in This Document
125 In the examples used in this document, "C:" indicates lines sent by a
126 client that is connected to a server, and "S:" indicates lines sent
127 by the server to the client.
1292. Definition of the "$Important" Message Keyword
131 The "$Important" keyword is a signal that a message is likely
132 important to the user. The keyword is generally expected to be set
133 automatically by the system based on available signals (such as who
134 the message is from, who else the message is addressed to, evaluation
135 of the subject or content, or other heuristics). While the keyword
136 also can be set by the user, that is not expected to be the primary
139 This is distinct from the "\Flagged" system flag in two ways:
141 1. "$Important" carries a meaning of general importance, as opposed
142 to follow-up or urgency. It is meant to be used for a form of
143 triage, with "\Flagged" remaining as a designation of special
144 attention, need for follow-up, or time sensitivity. In
145 particular, the sense of "$Important" is that other messages that
146 are "like this one" according to some server-applied heuristics
147 will also be considered "$Important".
149 2. The setting of "$Important" is expected to be based at least
150 partly on heuristics (generally set automatically by the server),
151 whereas "\Flagged" is only intended to be set by the user with
152 some sort of "flag this message" or "put a star on this message"
1553. Definition of the 'Important' Mailbox Attribute
157 The "\Important" mailbox attribute is a signal that the mailbox
158 contains messages that are likely important to the user. In an
159 implementation that also supports the "$Important" keyword, this
160 special use is likely to represent a virtual mailbox collecting
161 messages (from other mailboxes) that are marked with the "$Important"
162 keyword. In other implementations, the system might automatically
163 put messages there based on the same sorts of heuristics that are
164 noted for the "$Important" keyword (see Section 2). The distinctions
165 between "\Important" and "\Flagged" for mailboxes are similar to
166 those between "$Important" and "\Flagged" for messages.
170Leiba Standards Track [Page 3]
172RFC 8457 IMAP "Important" Keyword and Attribute September 2018
177 The following syntax specification adds to the one in Section 6 of
178 [RFC6154] using Augmented Backus-Naur Form (ABNF) as described in
179 [RFC5234]. Be sure to see the ABNF notes at the beginning of
180 Section 9 of [RFC3501].
182 use-attr =/ "\Important"
1863.2.1. Example of a LIST Response
188 In the following example, the mailbox called "Important Messages" is
189 the one designated with the "\Important" attribute.
192 S: * LIST (\HasNoChildren \Important) "/" "Important Messages"
193 S: * LIST (\HasNoChildren) "/" "Imported Wine"
1963.2.2. Examples of Creating a New Mailbox Using "\Important"
198 In the following example, the mailbox called "Important Messages" is
199 created with the "\Important" attribute on a server that advertises
200 the "CREATE-SPECIAL-USE" capability string.
202 C: t1 CREATE "Important Messages" (USE (\Important))
203 S: t1 OK Mailbox created
205 The following example is similar to the previous one, but the server
206 is not able to assign the "\Important" attribute to the new mailbox.
208 C: t1 CREATE "Important Messages" (USE (\Important))
209 S: t1 NO [USEATTR] An \Important mailbox already exists
211 The following example is similar to the previous one, but the server
212 does not support this extension.
214 C: t1 CREATE "Important Messages" (USE (\Important))
215 S: t1 NO [USEATTR] Mailbox not created; unsupported use \Important
217 In both of the failure-mode examples, the "USEATTR" response code
218 lets the client know that the problem is in the "USE" parameters.
219 Note that the same response code is given in both cases, and the
220 human-readable text is the only way to tell the difference. That
221 text is not parsable by the client (it can only be logged and/or
222 reported to the user).
226Leiba Standards Track [Page 4]
228RFC 8457 IMAP "Important" Keyword and Attribute September 2018
2314. Implementation Notes
233 This section is non-normative and is intended to describe the
234 intended (and current as of this publication) usage of "$Important"
235 in contrast with "\Flagged" on a message.
239 o "\Flagged" is set or cleared in response to an explicit command
242 o "$Important" is set via a heuristic process performed by the
243 server and usually involves analysis of header fields, what
244 mailbox the message is filed in, perhaps message content,
245 attachments, and such. It may then be set or cleared in response
246 to an explicit command from the client, and the server may use
247 that to adjust the heuristics in the future. It's also possible
248 that the server will re-evaluate this and make a message
249 "$Important" later if the user accesses the message frequently,
254 o Typically, an icon such as a flag or a star (or an indication,
255 such as red or bold text) is associated with "\Flagged", and the
256 UI provides a way for the user to turn that icon or indication on
257 or off. Manipulation of this results in a command to the server.
259 o Typically, a lesser indication is used for "$Important". The
260 client might or might not provide the user with a way to
261 manipulate it. If it does, manipulation results in a command to
2645. Security Considerations
266 The security considerations in Section 7 of [RFC6154] apply equally
267 to this extension, in particular, "Conveying special-use information
268 to a client exposes a small bit of extra information that could be of
269 value to an attacker." Moreover, identifying important messages or a
270 place where important messages are kept could give an attacker a
271 strategic starting point. If the algorithm by which messages are
272 determined to be important is well known, still more information is
273 exposed -- perhaps, for example, there is an implication that the
274 senders of these messages are particularly significant to the mailbox
275 owner, and perhaps that is information that should not be made
282Leiba Standards Track [Page 5]
284RFC 8457 IMAP "Important" Keyword and Attribute September 2018
287 As noted in RFC 6154, it is wise to protect the IMAP channel from
288 passive eavesdropping and to defend against unauthorized discernment
289 of the identity of a user's "\Important" mailbox or of a user's
290 "$Important" messages. See Section 11 of [RFC3501] for security
291 considerations about using the IMAP STARTTLS command to protect the
2946. IANA Considerations
296 IANA has completed three actions, which are specified in the sections
299 1. registration of the "$Important" keyword;
301 2. creation of a new "IMAP Mailbox Name Attributes" registry; and
303 3. registration of initial entries in the "IMAP Mailbox Name
304 Attributes" registry.
3066.1. Registration of the "$Important" Keyword
308 IANA has registered the "$Important" keyword in the "IMAP Keywords"
309 registry, as follows, using the template in [RFC5788].
311 IMAP keyword name: $Important
313 Purpose (description): The "$Important" keyword is a signal that a
314 message is likely important to the user.
316 Private or Shared on a server: PRIVATE
318 Is it an advisory keyword or may it cause an automatic action:
319 Advisory (but see the reference for details).
321 When/by whom the keyword is set/cleared: The keyword can be set by
322 the user, or automatically by the system based on available
323 signals (such as who the message is from, who else the message
324 is addressed to, evaluation of the subject or content, or other
327 Related keywords: None (see the reference for the related mailbox
330 Related IMAP capabilities: None.
332 Security considerations: See Section 5 of RFC 8457.
334 Published specification: RFC 8457
338Leiba Standards Track [Page 6]
340RFC 8457 IMAP "Important" Keyword and Attribute September 2018
343 Person & email address to contact for further information:
344 IETF Applications and Real-Time Area <art@ietf.org>
346 Intended usage: COMMON
348 Owner/Change controller: IESG
3526.2. Creation of the IMAP Mailbox Name Attributes Registry
354 IANA has created a new registry in the group "Internet Message Access
355 Protocol (IMAP)". It is called "IMAP Mailbox Name Attributes", and
356 it has two references: "RFC 3501, Section 7.2.2", and "RFC 8457,
357 Section 6". This registry will be shared with the JSON Meta
358 Application Protocol (JMAP) for Mail [JMAP-MAIL].
360 The registry entries contain the following fields:
367 IANA keeps this list in alphabetical order by Attribute Name, which
368 is registered without the initial backslash ("\"). The names are
369 generally registered with initial capital letters but are treated as
370 case-insensitive US-ASCII strings.
372 The "Usage Notes" field is free-form US-ASCII text that will normally
373 be empty (and is empty if it's not specified in the registration
374 request). It is intended to hold things such as "not used by JMAP"
375 and "JMAP only". The field is for human use, and there is no need
376 for a registry of strings that may appear here.
378 The registration policy for the new registry is listed as "IETF
379 Review" or "Expert Review" [RFC8126], and new registrations will be
380 accepted in one of two ways:
382 1. For registrations requested in an IETF consensus document, the
383 registration policy will be IETF Review, and the request will be
384 made in the IANA Considerations section of the document, which
385 gives the requested values for each of the fields.
387 2. For other registrations, the policy will be Expert Review policy
388 (see Section 6.2.1), and the request will be made by sending
389 email to IANA asking for a new IMAP Mailbox Name Attribute and
390 giving the requested values for each of the fields. While a
394Leiba Standards Track [Page 7]
396RFC 8457 IMAP "Important" Keyword and Attribute September 2018
399 formal specification is not required, the reference document
400 should provide a description of the proposed attribute sufficient
401 for building interoperable implementations. An Informational RFC
402 (submitted, for example, through the IETF or Independent stream)
403 is a fine way to publish a reference document (see also
4066.2.1. Instructions to the Designated Expert
408 The expert reviewer, who will be designated by the IESG, is expected
409 to provide only a general review of the requested registration,
410 checking that the reference and description are adequate for
411 understanding the intent of the registered attribute. Efforts should
412 also be made to generalize the intent of an attribute so that
413 multiple implementations with the same requirements may reuse
414 existing attributes. Except for this check, this is intended to be
415 very close to a first come first served policy, and the expert should
416 not block serious registration requests with a reasonable reference.
417 The reference may be to any form of documentation, including a web
418 page, but consideration should be given to providing one that is
419 expected to be long-lived and stable.
450Leiba Standards Track [Page 8]
452RFC 8457 IMAP "Important" Keyword and Attribute September 2018
4556.3. Initial Entries for the IMAP Mailbox Name Attributes Registry
457 The registry initially contains these entries:
459 +===============+===================================+===========+
460 | Attribute | Description | Reference |
462 +===============+===================================+===========+
463 | All | All messages | [RFC6154] |
464 +---------------+-----------------------------------+-----------+
465 | Archive | Archived messages | [RFC6154] |
466 +---------------+-----------------------------------+-----------+
467 | Drafts | Messages that are working drafts | [RFC6154] |
468 +---------------+-----------------------------------+-----------+
469 | Flagged | Messages with the \Flagged flag | [RFC6154] |
470 +---------------+-----------------------------------+-----------+
471 | HasChildren | Has accessible child mailboxes | [RFC5258] | *
472 +---------------+-----------------------------------+-----------+
473 | HasNoChildren | Has no accessible child mailboxes | [RFC5258] | *
474 +---------------+-----------------------------------+-----------+
475 | Important | Messages deemed important to user | RFC 8457 |
476 +---------------+-----------------------------------+-----------+
477 | Junk | Messages identified as Spam/Junk | [RFC6154] |
478 +---------------+-----------------------------------+-----------+
479 | Marked | Server has marked the mailbox as | [RFC3501] | *
480 | | "interesting" | |
481 +---------------+-----------------------------------+-----------+
482 | NoInferiors | No hierarchy under this name | [RFC3501] | *
483 +---------------+-----------------------------------+-----------+
484 | NonExistent | The mailbox name doesn't actually | [RFC5258] | *
486 +---------------+-----------------------------------+-----------+
487 | Noselect | The mailbox is not selectable | [RFC3501] | *
488 +---------------+-----------------------------------+-----------+
489 | Remote | The mailbox exists on a remote | [RFC5258] | *
491 +---------------+-----------------------------------+-----------+
492 | Sent | Sent mail | [RFC6154] |
493 +---------------+-----------------------------------+-----------+
494 | Subscribed | The mailbox is subscribed to | [RFC5258] |
495 +---------------+-----------------------------------+-----------+
496 | Trash | Messages the user has discarded | [RFC6154] |
497 +---------------+-----------------------------------+-----------+
498 | Unmarked | No new messages since last select | [RFC3501] | *
499 +===============+===================================+===========+
501 The rows marked with "*" at the end have their Usage Notes field set
502 to "not used by JMAP".
506Leiba Standards Track [Page 9]
508RFC 8457 IMAP "Important" Keyword and Attribute September 2018
5137.1. Normative References
515 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
516 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
517 <https://www.rfc-editor.org/info/rfc3501>.
519 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
520 Specifications: ABNF", STD 68, RFC 5234,
521 DOI 10.17487/RFC5234, January 2008,
522 <https://www.rfc-editor.org/info/rfc5234>.
524 [RFC6154] Leiba, B. and J. Nicolson, "IMAP LIST Extension for
525 Special-Use Mailboxes", RFC 6154, DOI 10.17487/RFC6154,
526 March 2011, <https://www.rfc-editor.org/info/rfc6154>.
528 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
529 Writing an IANA Considerations Section in RFCs", BCP 26,
530 RFC 8126, DOI 10.17487/RFC8126, June 2017,
531 <https://www.rfc-editor.org/info/rfc8126>.
5337.2. Informative References
536 Jenkins, N. and C. Newman, "JMAP for Mail", Work in
537 Progress, draft-ietf-jmap-mail-07, August 2018.
539 [RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access
540 Protocol version 4 - LIST Command Extensions", RFC 5258,
541 DOI 10.17487/RFC5258, June 2008,
542 <https://www.rfc-editor.org/info/rfc5258>.
544 [RFC5788] Melnikov, A. and D. Cridland, "IMAP4 Keyword Registry",
545 RFC 5788, DOI 10.17487/RFC5788, March 2010,
546 <https://www.rfc-editor.org/info/rfc5788>.
562Leiba Standards Track [Page 10]
564RFC 8457 IMAP "Important" Keyword and Attribute September 2018
569 The following author was an original contributor to this document in
570 addition to the editor.
574 Email: iceman@google.com
581 Phone: +1 646 827 0648
582 Email: barryleiba@computer.org
583 URI: http://internetmessagingtechnology.org/
618Leiba Standards Track [Page 11]