(registered 2010-08-26) IMAP keyword name: $Junk Purpose (description): The user (or a delivery agent on behalf of the user) may choose to mark a message as definitely containing junk ($Junk; see also the related keyword $NotJunk). The $Junk keyword can be used to mark (and potentially move/delete messages later), group or hide undesirable messages. Private or Shared on a server: BOTH (see Note 3) Is it an advisory keyword or may it cause an automatic action: This keyword is advisory. When/by whom the keyword is set/cleared: $Junk can be set either by a delivery agent or a mail client on users behalf. The user must be able to set or clear $Junk 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. Related keywords: $NotJunk Related IMAP capabilities: None Security considerations: A message marked the with $Junk keyword by one user might not be considered junk by another (or even by the same user under different circumstances). Any automated action taken by the mail system or by the MUA in response to this keyword needs to take that into account. Destructive action (such as expunging a message as soon as the $Junk keyword is applied) can cause loss of desired messages, and mail systems and MUAs SHOULD NOT take such actions. Published specification (recommended): Person & email address to contact for further information: Alexey Melnikov Intended usage: COMMON Owner/Change controller: IESG Note: 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 neither of them is set and SHOULD remove both of them from the IMAP server. 2). 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 "Junk"/"NotJunk" is deprecated, mail clients should be using "$Junk"/"$NotJunk" instead. 3). Because different users might have differing views of what constitutes "junk", server implementations SHOULD favor the use of a private keyword, to allow the most flexibility. However, because it will often be the case that there's broad agreement on the categorization of most messages in this regard, it will make the most sense for systems that implement shared messages to use a shared keyword, and to allow individual users to override that designation for themselves. An implementation might even take multiple overrides as a suggestion to change the shared flag, and consider that a useful optimization.