@TwelveBaud reported
Trac ID	trac#10290
Type	defect
Created	2022-01-08 19:39:02Z

Specification

RFC 3501, which defines IMAP4, has two separate, related concepts.

Section 2.3.2 defines message flags thusly:
2.3.2. Flags Message Attribute

A list of zero or more named tokens associated with the message. A
flag is set by its addition to this list, and is cleared by its
removal. There are two types of flags in IMAP4rev1[, system flags and message keywords]. A flag of
either type can be permanent or session-only.

Many commands regarding individual messages allow reading, writing, or filtering on message flags. Also, when sending detailed information about a mailbox (part of a SELECT or EXAMINE reply), one of the untagged responses is a list of flags, set out in section 7.2.6:
Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
While that section states that the response "identifies the flags [...] that are applicable for this mailbox", other references (e.g. section 6.3.1 on the SELECT command) describe them as defined in the mailbox, specifically as flags for messages. In other words, when working with messages in that box, a client can expect to see messages with those flags, and potentially set those flags on messages.

Mailbox name attributes do not get their own special section, but are defined as part of the LIST response in section 7.2.2:
7.2.2. LIST Response

[...]

Four name attributes are defined:

\Noinferiors
It is not possible for any child levels of hierarchy to exist
under this name; no child levels exist now and none can be
created in the future.

\Noselect
It is not possible to use this name as a selectable mailbox.

\Marked
The mailbox has been marked "interesting" by the server; the
mailbox probably contains messages that have been added since
the last time the mailbox was selected.

\Unmarked
The mailbox does not contain any additional messages since the
last time the mailbox was selected.

Other RFCs (such as RFC 6154) add additional mailbox name attributes. Key to all of them is that they describe an aspect of the mailbox itself, not the messages within. Mailbox name attributes are only sent in LIST and LSUB responses, and can only be manipulated with CREATE and DELETE commands.

RFC 3501 mistakenly refers to name attributes as flags in two places -- the LSUB command says that "The returned untagged LSUB response MAY contain different mailbox flags from a LIST untagged response" and the language grammar refers to '''mbx'''-list-flags -- but in both cases it's clear that mailbox name attributes were intended.

Interface

Twisted Mail defines an interface for the results of IAccountIMAP.listMailboxes() (i.e. in response to a LIST or LSUB command, which should include name attributes). The relevant method has this definition:

    def getFlags():
        """
        Return the flags defined in this mailbox

        Flags with the \\ prefix are reserved for use as system flags.

        @rtype: L{list} of L{str}
        @return: A list of the flags that can be set on messages in this
            mailbox.
        """

There are no methods which include "name attributes" anywhere in their docstrings; none in IMailboxIMAPInfo, none in IMailboxIMAP, none in ISearchableIMAPMailbox, none in ICloseableMailboxIMAP. There are also no methods whose docstrings suggest they'll be called in that context.

Implementation

The in-box IMAP4Server calls getFlags whenever it's interested in either concept -- getFlags' output is used for LIST and LSUB name attribute lists, and for the FLAGS response for message keywords, and for checking whether or not a mailbox can be selected, examined, or destroyed (via presence of \Noselect). This leads to the server making some strange claims, such that a mailbox has been replied to or that a client can dictate a message be disallowed from ever having sub-messages -- fortunately, unextended IMAP has no attribute/flag collisions and attributes are relatively rare, so clients safely ignore the nonsense. However, if the server has been extended to include RFC 5258 support, suddenly \Subscribed inadvertently gets advertised as something you can set on messages in mailboxes you've subscribed to, while RFC 6154 support makes every mailbox the "Drafts" mailbox.

trac-id__10290 10290
type__defect defect
reporter__TwelveBaud TwelveBaud
priority__low low
milestone__None None
branch__ 
branch_author__ 
status__new new
resolution__None None
component__mail mail
keywords__None None
time__1641670742498376 1641670742498376
changetime__1641670742498376 1641670742498376
version__None None
owner__None None