Internet Draft: Common IMAP keywords A. Melnikov
Document: draft-melnikov-imap-keywords-03.txt Isode Ltd.
Expires: February 2006 August 2005
Intended category: Informational
Common IMAP keywords
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
A revised version of this draft document will be submitted to the RFC
editor as an Informational document. Discussion and suggestions for
improvement are requested, and should be sent to the IMAP4 Mailing
list (imap@CAC.Washington.EDU) <<?>>. To subscribe to the list, send
email to <listproc@u.washington.edu> with the text "subscribe imap
YourName" in the body of the message. Distribution of this memo is
unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The aim of this document is to document some common [IMAP4] keywords
for the purpose of improving interoperability between different IMAP
mail clients. The document both documents some keywords already in use,
as well as introduces several new ones.
Melnikov Expires: February 2006 [Page 1]
INTERNET DRAFT Common IMAP keywords August 2005
This document also establishes a new IANA registry for IMAP keywords
and defines a procedure for keyword registration.
Table of Contents
Abstract .................................................... 2
0. To do ....................................................... 1
1. Conventions Used in this Document ........................... 2
2. IMAP keyword registrations .................................. 3
2.1 $Forwarded .................................................. 3
2.2 Keywords related to junk filtering .......................... X
2.3 $Work ....................................................... X
2.4 $Personal ................................................... X
2.5 $ShouldReply ................................................ X
2.6 $ToDo ....................................................... X
2.7 $Important .................................................. X
3. Security Considerations ..................................... X
4. Known issues with mail clients .............................. X
5. Formal Syntax ............................................... X
6. IANA Considerations ......................................... X
7. Acknowledgments ............................................. X
8. Normative References ........................................ X
9. Author's Addresses .......................................... X
10. Intellectual Property ....................................... X
11. Full Copyright Statement .................................... X
1. Conventions Used in this Document
"C:" and "S:" in examples show lines sent by the client and server
respectively.
The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in
this document when typed in uppercase are to be interpreted as
defined in "Key words for use in RFCs to Indicate Requirement Levels"
[KEYWORDS].
<<Irreversible action - any action that causes alteration of the
message, its deletion or move to a different mailbox, generation of
an automatic reply based on the message (bouncing to sender,
notifying administrator, etc.). Actions like hiding the message,
grouping messages or displaying different icon(s) are not considered
to be "irreversible actions".>>
Melnikov Expires: February 2006 [Page 2]
INTERNET DRAFT Common IMAP keywords August 2005
2. IMAP keyword registrations
2.1 $Forwarded
Purpose: $Forwarded is used by several IMAP clients to specify that
the message was resent to another email address, embedded within or
attached to a new message. This keyword is set by the mail client
when it successfully forwards the message to another email address.
Typical usage of this keyword is to show a different (or additional)
icon for a message that has been forwarded.
Private or Shared on a server: either
Is it an advisory keyword or may it cause an automatic action:
advisory
When/by whom the keyword is set/cleared: This keyword can be set
either by a delivery agent or a mail client. Once set the flag SHOULD
NOT be cleared.
Notes: There is no way to tell if a message with $Forwarded keyword
set was forwarded more than once.
Corresponding ANNOTATE attribute: "/message/flags/$forwarded"
(default mapping as described in ANNOTATE)
Additional IMAP capabilities: none.
Security Considerations: A server implementing this keyword as a
shared keyword, may disclose that a confidential message was
forwarded.
2.2 Keywords related to junk filtering
This section defines two groups of keywords related to mail
filtering.
2.2.1 $AutoJunk/$AutoNotJunk/$AutoMaybeJunk
Purpose: An automated system (delivery agent, mail filtering software
or IMAP4/POP3 server) may mark a message with one of the following
keywords:
$AutoJunk - a message is most likely to contain junk;
$AutoNotJunk - a message is most likely not to contain junk;
$AutoMaybeJunk - a message may contain junk;
$AutoMaybeJunk, for example, may be used by a Bayesian filtering
Melnikov Expires: February 2006 [Page 3]
INTERNET DRAFT Common IMAP keywords August 2005
software that can't classify a message with certainty as being either
junk or not junk.
These keyword can be used to mark, group or hide ($AutoJunk)
offensive messages. However no automatic irreversible action (in
particular message deletion, bouncing, moving into a different
mailbox) should be allowed on messages marked as $AutoJunk.
Private or Shared on a server: may be shared. SHOULD be shared when
automatically set by a delivery agent or an IMAP4/POP3 server.
Is it an advisory keyword or may it cause an automatic action:
advisory
When/by whom the keyword is set/cleared: Any one of the described
keywords can be set automaticall either by a delivery agent, a mail
filtering software or a mail (IMAP4/POP3) server. Once set, the value
SHOULD NOT be changed. If $AutoJunk and/or $AutoMaybeJunk are used
to hide all messages with those flags from the current view, the mail
client MUST implement a mode of operation when it is possible to see
the hidden messages.
Notes: $AutoJunk, $AutoNotJunk and $AutoMaybeJunk are mutually
exclusive. If more than one of them is set for a message, the mail
client MUST treat this as if none of them is set and SHOULD remove
all of them from the IMAP server.
Notes: See also section 3.2.2 that talks how $AutoJunk, $AutoNotJunk
and $AutoMaybeJunk may interact with $Junk and $NotJunk.
Corresponding ANNOTATE attribute: "/message/flags/$autojunk"
"/message/flags/$autonotjunk"
"/message/flags/$automaybejunk"
(default mapping as described in ANNOTATE)
Additional IMAP capabilities: none.
Security Considerations: A message marked with $AutoJunk keyword by
an automated system might not be considered junk by any or even all
users of the system. Thus, any automated actions are prohibited
based on the keywords described in this section.
2.2.2 $Junk/$NotJunk
Purpose: The user (or a delivery agent on behalf of the user) may
choose to mark a message as either definitely containing junk ($Junk)
or definitely not containing junk ($NotJunk). This keyword can be
Melnikov Expires: February 2006 [Page 4]
INTERNET DRAFT Common IMAP keywords August 2005
used to mark (and potentially move/delete messages later), group or
hide offensive messages.
If none of $Junk or $NotJunk is present for a messages, a mail client
MAY treat $AutoJunk (section 3.2.1) as $Junk and $AutoNotJunk
(section 3.2.1) as $NotJunk. However, in this case no automatic
irreversible action MUST be done on the message. <<For example, if
the user chooses to move all messages marked as junk to a different
mailbox, the message that only have $AutoJunk set, MUST NOT be
moved?>>
Private or Shared on a server: private
Is it an advisory keyword or may it cause an automatic action:
advisory
When/by whom the keyword is set/cleared: $Junk/$NotJunk can be set
either by a delivery agent or a mail client on users behalf. The user
must be able to change $Junk to $NotJunk or vice versa at any time.
If the mail client hides all messages with $Junk keyword from the
current view, the mail client MUST implement a mode when it is
possible to see all messages marked as $Junk.
Notes:
1). $Junk and $NotJunk are mutually exclusive. If more than one of
them is set for a message, the mail client MUST treat this as if
none of them is set and SHOULD remove both of them from the IMAP
server.
2). $Junk is also mutually exclusive with $Work and $Personal.
If more than one of them is set for a message, the mail client
MUST treat this as if none of them is set and SHOULD remove all
of them from the IMAP server.
3). The combination of $NotJunk and $AutoJunk keywords indicates that
the automated system made a false-positive.
The combination of $Junk and $AutoNotJunk keywords indicates that
the automated system made a false-negative.
Both combinations can be used to train the automated system that
set $AutoJunk/$AutoNotJunk to do a better job in classifying junk
versa not junk.
4). <<There are existing clients that use mutually exclusive keywords
Junk and NotJunk to mark a message as definitely containing
/definitely non containing junk information. Use of
Melnikov Expires: February 2006 [Page 5]
INTERNET DRAFT Common IMAP keywords August 2005
"Junk"/"NotJunk" is discouraged, mail clients should be using
"$Junk"/"$NotJunk" instead.>>
Corresponding ANNOTATE attribute: "/message/flags/$junk"
"/message/flags/$notjunk"
(default mapping as described in ANNOTATE)
Additional IMAP capabilities: none.
Security Considerations: A message marked with $Junk keyword by one
user might not be considered junk by another (or even by the same
user under different circumstances), so no automatic action can be
initiated when this flag is set.
2.3 $Work
Purpose: The user (or a delivery agent on behalf of the user) may
choose to mark a message as related to work. This keyword can be used
to automatically move a message to a different mailbox or to group
messages.
Private or Shared on a server: private
Is it an advisory keyword or may it cause an automatic action:
advisory
When/by whom the keyword is set/cleared: This keyword can be set
either by a delivery agent or a mail client on users behalf. The user
must be able to set and unset this keyword.
Notes: This keyword is mutually exclusive with $Junk and $Personal.
If more than one of the $Junk, $Work or $Personal keywords is set for
a message, the mail client MUST treat this as if none of them is set
and SHOULD remove all of them from the IMAP server.
Note: $Work and $Personal can be used to help implement a "poor man"
multiple personalities (actually just two personalities) feature in a
mail client.
Corresponding ANNOTATE attribute: "/message/flags/$work"
(default mapping as described in ANNOTATE)
Additional IMAP capabilities: none.
Security Considerations: <<same as $Junk>>.
2.4 $Personal
Melnikov Expires: February 2006 [Page 6]
INTERNET DRAFT Common IMAP keywords August 2005
Purpose: The user (or a delivery agent on behalf of the user) may
choose to mark a message as personal. This keyword can be used to
automatically move a message to a different mailbox or to group
messages.
Private or Shared on a server: private
Is it an advisory keyword or may it cause an automatic action:
advisory
When/by whom the keyword is set/cleared: This keyword can be set
either by a delivery agent or a mail client on users behalf. The user
must be able to set and unset this keyword.
Notes: This keyword is mutually exclusive with $Junk and $Work. If
more than one of the $Junk, $Work or $Personal keywords is set for a
message, the mail client MUST treat this as if none of them is set
and SHOULD remove all of them from the IMAP server.
Note: $Work and $Personal can be used to help implement a "poor man"
multiple personalities (actually just two personalities) feature in a
mail client.
Corresponding ANNOTATE attribute: "/message/flags/$personal"
(default mapping as described in ANNOTATE)
Additional IMAP capabilities: none.
Security Considerations: <<same as $Junk>>.
2.5 $ShouldReply
Purpose: The user may mark a message with this keyword to specify
that the message requires a reply. One possible use of this keyword
is to group in some way all messages having this keyword. Another
possible use would be to periodically remind the user to send replies
to messages marked with this keyword. When a reply to this message is
sent, the mail client MUST remove this keyword and MUST set the
\Answered flag.
<<Does \Answered cancel $ShouldReply? Is a special IMAP capability
required for this?>>
Private or Shared on a server: private
Is it an advisory keyword or may it cause an automatic action:
advisory(<<?>>)
Melnikov Expires: February 2006 [Page 7]
INTERNET DRAFT Common IMAP keywords August 2005
When/by whom the keyword is set/cleared: This keyword can be set
either by a delivery agent or a mail client on users behalf (for
example, "should reply to all messages from boss with particular
subject"). The user must be able to set and unset this keyword.
Notes: <<popping up a dialog asking for reply each time the client
sees this flag might be a bad UI idea>>.
Corresponding ANNOTATE attribute: "/message/flags/$shouldreply"
(default mapping as described in ANNOTATE)
Additional IMAP capabilities: none.
Security Considerations: <<danger of any automated reply...>>
2.6 $ToDo
Purpose: The user may mark a message with this keyword to specify
that the message requires some kind of action from the user, for
example phone call, or reply (in the latter case the $ShouldReply
keyword would also be set). One possible use of this keyword is to
group in some way all messages having this keyword.
Private or Shared on a server: private
Is it an advisory keyword or may it cause an automatic action:
advisory(<<?>>)
When/by whom the keyword is set/cleared: This keyword can be set
either by a delivery agent or a mail client on users behalf. The user
must be able to set and unset this keyword.
Notes: <<popping up a dialog asking for reply each time the client
sees this flag might be a bad UI idea>>.
Corresponding ANNOTATE attribute: "/message/flags/$todo"
(default mapping as described in ANNOTATE)
Additional IMAP capabilities: none.
Security Considerations: <<danger of any automated reply...>>
2.7 $Important
Purpose: <<[IMAP4] doesn't specify exact semantics of the \Flagged
flag. It suggests that it is up to a MUA to assign any special
meaning to it. Most intuitive meaning of \Flagged is probably to mark
Melnikov Expires: February 2006 [Page 8]
INTERNET DRAFT Common IMAP keywords August 2005
that message as important. However since the same user can use
multiple MUAs from different vendors, there are some MUAs that use it
for different purposes. In order to introduce a consistent
"Important" mark a new flag is required. This document defines a new
keyword $Important for this purpose.>>
Private or Shared on a server: private
Is it an advisory keyword or may it cause an automatic action:
advisory
When/by whom the keyword is set/cleared: This keyword can be set
either by a delivery agent or a mail client on users behalf, for
example if the message includes header field "Importance" with the
value "High". The user must be able to set and unset this keyword.
Notes: ...
<<Describe how client should display that: use described header
fields if the $Important keyword is not set. The keyword overrides
header fields.>>
<<Add mutual exclusive $Important/$Normal/$Unimportant, so that it
would be possible to override the meaning prescribed by headers?>>
Corresponding ANNOTATE attribute: ...
Additional IMAP capabilities: ?.
Security Considerations: ...
3. Security Considerations
<< Danger of an automatic initiation of an action based on $Junk
keyword >>
4. Known issues with mail clients
A popular open source mail client Mozilla implemented "labels". Each
label has associated color and name (description) that can be changed
by a user, a label name can be stored on an IMAP server as a keyword.
Mozilla uses 5 hardcoded keywords $Label1, $Label2, $Label3, $Label4
and $Label5. However, there is a problem with how Mozilla
implemented this feature. Each label has a fixed IMAP keyword and a
description that can be changed. Now imagine that two users (or even
the same user on two different computers) configured Mozilla
Melnikov Expires: February 2006 [Page 9]
INTERNET DRAFT Common IMAP keywords August 2005
differently so that the label $Label1 has description "Important" on
one machine and description "Junk" on another. As label description
is not stored on the IMAP server there is an interoperability
problem.
There are two possible ways to fix the problem.
One way is to disallow editing of label descriptions (the defaults
are Important/Work/Personal/ToDo/Later) and to use matching keywords
from this document (or create new ones if necessary).
Another way is to allow users to edit keyword names in addition to
label descriptions. This is a feature for advanced users and should
have a detailed documentation describing how to correctly select
keyword names.
5. Formal Syntax
Formal syntax is defined using ABNF [ABNF], extending the ABNF rules
in section 9 of [IMAP4]. Elements not defined here can be found in
the [ABNF] and [IMAP4].
Except as noted otherwise, all alphabetic characters are case-
insensitive. The use of upper or lower case characters to define
token strings is for editorial clarity only. Implementations MUST
accept these strings in a case-insensitive fashion.
flag_keyword ::= spe_keywords / other_keywords
spe_keywords ::= "$" ( "Forwarded" / "Important" / "ShouldReply" /
/ "Work" / "Personal" ) / junk_keywords
junk_keywords ::= (junkauto_keys / junkmanual_keys)
junkauto_keys ::= "AutoJunk" / "AutoNotJunk" / "AutoMaybeJunk"
junkmanual_keys ::= "Junk" / "NotJunk"
other_keywords ::= atom
6. IANA Considerations
6.1. IMAP Keyword Registry
IANA is requested to establish a new registry for IMAP keywords.
Melnikov Expires: February 2006 [Page 10]
INTERNET DRAFT Common IMAP keywords August 2005
Registration of an IMAP keyword is requested by filling in the
following template:
Subject: Registration of IMAP keyword X
IMAP keyword name:
Purpose (description):
Private or Shared on a server: (One of PRIVATE, SHARED or BOTH)
Is it an advisory keyword or may it cause an automatic action:
When/by whom the keyword is set/cleared:
Related keywords: (for example "mutually exclusive with keywords Y and Z")
Additional IMAP capabilities:
Security considerations:
Published specification (recommended):
Person & email address to contact for further information:
Intended usage: (One of COMMON, LIMITED USE or OBSOLETE)
Owner/Change controller:
Note: (Any other information that the author deems interesting may
be added here, for example if the keyword(s) is supported by
existing clients.)
and sending it via electronic mail to <iana@iana.org>.
Registration of IMAP keywords intended for common use requires expert review.
This can be performed by posting a review request to IMAP mailing list <<>>.
IMAP keywords intended for widespread use should be
standardized through the normal IETF process, when appropriate.
Registration of vendor specific keywords is done on First Come First Serve
basis and doesn't require an expert review. However such review is still
encouraged.
<<Vendor specific prefix and prefix for standard keywords.>>
Melnikov Expires: February 2006 [Page 11]
INTERNET DRAFT Common IMAP keywords August 2005
6.1.1. Comments on IMAP Keywords' Registrations
Comments on registered IMAP Keywords should first be sent to the
"owner" of the mechanism and/or to the IMAP mailing list.<<>>
Submitters of comments may, after a reasonable attempt to contact the
owner and after soliciting comments on the IMAP mailing list,
request IANA to attach their comment to the IMAP keyword
registration itself by sending mail to <iana@iana.org>. At IANA sole
discretion, IANA may attach the comment to the IMAP keyword registration.
6.1.2. Change Control
Once an IMAP keyword registration has been published by IANA, the
author may request a change to its definition. The change request
follows the same procedure as the registration request.
The owner of a IMAP keyword may pass responsibility for the IMAP keyword
to another person or agency by informing IANA; this can be
done without discussion or review.
The IESG may reassign responsibility for an IMAP keyword. The most
common case of this will be to enable changes to be made to mechanisms
where the author of the registration has died, moved out of contact or
is otherwise unable to make changes that are important to the
community.
IMAP keyword registrations may not be deleted; <<keywords which are
no longer believed appropriate for use can be declared OBSOLETE by a
change to their "intended usage" field>>.
The IESG is considered to be the owner of all IMAP keywords which
are on the IETF standards track.
6.2. Initial registrations
<<>>
7. Acknowledgments
The creation of this document was prompted by one of many discussions
on the IMAP mailing list.
John Neystadt co-authored the first revision of this document.
Special thanks to Chris Newman, David Harris, Lyndon Nerenberg and
Melnikov Expires: February 2006 [Page 12]
INTERNET DRAFT Common IMAP keywords August 2005
Mark Crispin for reviewing the document. However all errors or omissions
must be attributed to the author of this document.
The author would also like to thank the developers of Mozilla mail
clients for providing food for thoughts.
8. Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 3501, University of Washington, March 2003.
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC 2822] Resnick, P., "Internet Message Format", RFC 2822,
QUALCOMM Incorporated, April 2001.
[] Palme, J., "Common Internet Message Headers", RFC 2076,
Stockholm University/KTH, February 1997.
[ANNOTATION] Gellens, R., Daboo, C., "IMAP ANNOTATE Extension",
work in progress,
<http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-xx.txt>
9. Author's Addresses
Alexey Melnikov
Isode Limited
Address: 5 Castle Business Village,
36 Station Road,
Hampton, Middlesex,
United Kingdom, TW12 2BX
Phone: +44 77 53759732
Email: alexey.melnikov@isode.com
Melnikov Expires: February 2006 [Page 13]
INTERNET DRAFT Common IMAP keywords August 2005
10. Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
11. Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Appendix A. To do list and open issues
[[Note to RFC Editor: delete this section before publication.]]
Melnikov Expires: February 2006 [Page 14]
INTERNET DRAFT Common IMAP keywords August 2005
Open issues are enclosed in << and >> through out this document.
This document is still very raw. Comments are encouraged.
<<Register "$" prefix for user defined keywords with special
semantics?>>
<<Add mutually exclusive $Important/$Unimportant/$NormalImportance?>>
<<Add IANA registration for $MDNSent.>>
<<Describe a new IMAP extension that can advertise which keywords are
mutually exclusive?>>
<<Mozilla uses the following labels:
Important/Work/Personal/ToDo/Later. Labels in Mozilla are mutually
exclusive (i.e. at least one or none). I personally disagree that
Important is mutually exclusive with either Work or Personal. Same
about ToDo. I am not sure what is the purpose of the "Later" label.>>
Appendix B. Change History
[[Note to RFC Editor: delete this section before publication.]]
Changes from draft-melnikov-imap-keywords-01
1. Dropped $Adult as it was too controversial.
2. Replaced $Spam with $Junk/$NotJunk/$AutoJunk/$AutoNotJunk and
$AutoMaybeJunk. Reworked text to reflect this and tried to
catch all different interactions between newly introduced
keywords.
3. Added more usage examples for different keywords.
4. Updated IMAP4rev1 reference.
5. Added description of a problem with labels in Mozilla.
Changes from draft-melnikov-imap-keywords-02
1. Added $ToDo.
2. Cleaned up some open issues, in particular removed text
prescribing which RFC 2822 header fields should cause
autosetting
of $Important.
3. Added IANA considerations section and registration procedure.
4. Fixed ABNF - extra leading $ was used for some keywords.
Melnikov Expires: February 2006 [Page 15]
