Internet Draft: Common IMAP keywords A. Melnikov Document: draft-melnikov-imap-keywords-03.txt Isode Ltd. Expires: March 2004 September 2003 Intended category: Informational Registration of common IMAP keywords Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 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 (2002-2003). All Rights Reserved. Table of Contents 0. To do ....................................................... 1 1. Abstract .................................................... 2 2. Conventions Used in this Document ........................... 2 3. IMAP keyword registrations .................................. 3 3.1 $Forwarded .................................................. 3 3.2 Keywords related to junk filtering .......................... X 3.3 $Work ....................................................... X 3.4 $Personal ................................................... X Melnikov Expires: December 2003 [Page 1] INTERNET DRAFT Registration of common IMAP keywords June 2003 3.5 $ShouldReply ................................................ X 3.6 $Important .................................................. X 4. Security Considerations ..................................... 4 5. Known issues with mail clients .............................. 4 6. Formal Syntax ............................................... 4 7. Acknowledgments ............................................. 5 8. References .................................................. 5 9. Author's Addresses .......................................... 5 10. Full Copyright Statement .................................... 6 1. 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. 2. 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]. <> Melnikov Expires: December 2003 [Page 2] INTERNET DRAFT Registration of common IMAP keywords June 2003 3. IMAP keyword registrations 3.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 the message with $Forwarded flags 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. 3.2 Keywords related to junk filtering This section defines two groups of keywords related to mail filtering. 3.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: December 2003 [Page 3] INTERNET DRAFT Registration of common IMAP keywords June 2003 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: ?. 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. 3.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) Melnikov Expires: December 2003 [Page 4] INTERNET DRAFT Registration of common IMAP keywords June 2003 or definitely not containing junk ($NotJunk). This keyword can be 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 irreversible action (whether automatic or manual <>) MUST be done on the message. <> 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 all 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 Melnikov Expires: December 2003 [Page 5] INTERNET DRAFT Registration of common IMAP keywords June 2003 Junk and NotJunk to mark a message as definitely containing /definitely non containing junk information. Use of "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: ?. 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. 3.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: ?. Security Considerations: <>. Melnikov Expires: December 2003 [Page 6] INTERNET DRAFT Registration of common IMAP keywords June 2003 3.4 $Personal 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: ?. Security Considerations: <>. 3.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 pop up a dialog reminding the user to send a reply. When a reply to this message is sent, the mail client MUST remove this keyword and MUST set the \Answered flag. <> Private or Shared on a server: private Is it an advisory keyword or may it cause an automatic action: advisory(?) Melnikov Expires: December 2003 [Page 7] INTERNET DRAFT Registration of common IMAP keywords June 2003 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: <>. Corresponding ANNOTATE attribute: "/message/flags/$shouldreply" (default mapping as described in ANNOTATE) Additional IMAP capabilities: none. Security Considerations: ... 3.6 $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 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.>> The server that recognizes $Important SHOULD automatically set it on a message injection if the root bodypart of that message contains the header field "Importance" with the value "High". The server SHOULD also set this keyword if the root body part contains either a header field "Priority" with the value of "urgent" [HEADERS] or a header field "X-Priority" with the value "1" or "2". Note that a header field value comparison MUST be done after removing RFC 822 comments (see section 3.2.3 of [RFC 2822]). For example, the "X-Priority" header field with the value "1 (Highest)" and "1" MUST be treated the same way. 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 as described above. The user must be able to set and unset this keyword. Melnikov Expires: December 2003 [Page 8] INTERNET DRAFT Registration of common IMAP keywords June 2003 <> Notes: ... <> <> <> Corresponding ANNOTATE attribute: ... Additional IMAP capabilities: ?. Security Considerations: ... 4. Security Considerations << Danger of an automatic initiation of an action based on $Junk keyword >> 5. 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 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). Melnikov Expires: December 2003 [Page 9] INTERNET DRAFT Registration of common IMAP keywords June 2003 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. 6. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4]. Non-terminals referenced but not defined below are as defined by [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 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 Mark Crispin for reviewing the document. The author would also like to thank the developers of Mozilla mail clients for providing food for thoughts. 8. References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Melnikov Expires: December 2003 [Page 10] INTERNET DRAFT Registration of common IMAP keywords June 2003 Requirement Levels", RFC 2119, March 1997. [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, University of Washington, March 2003. [RFC 2822] Resnick, P., "Internet Message Format", RFC 2822, QUALCOMM Incorporated, April 2001. [HEADERS] Palme, J., "Common Internet Message Headers", RFC 2076, Stockholm University/KTH, February 1997. [ANNOTATION] Gellens, R., Daboo, C., "IMAP ANNOTATE Extension", work in progress, 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: mel@isode.com Melnikov Expires: December 2003 [Page 11] INTERNET DRAFT Registration of common IMAP keywords June 2003 10. Full Copyright Statement Copyright (C) The Internet Society (2002-2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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 Open issues are enclosed in << and >> through out this document. This document is still very raw. Comments are encouraged. << Define a regular template?: Purpose (description): ... Private or Shared on a server: private/shared/both Is it an advisory keyword or may it cause an automatic action? When/by whom the keyword is set/cleared: ... Notes: (e.g. - limitations, mutually exclusive with ...) How the flag should be mapped to ANNOTATE (especially for mutually exclusive flags) Additional IMAP capability strings if the server is required to do Melnikov Expires: December 2003 [Page 12] INTERNET DRAFT Registration of common IMAP keywords June 2003 special processing ... Security Considerations: ... >> <> <> <> <> <> Appendix B. Change History 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 Mozilla. Melnikov Expires: December 2003 [Page 13]