Enum imap_codec::types::response::Data

pub enum Data {
    Capability(Vec<Capability>),
    List {
        items: Vec<FlagNameAttribute>,
        delimiter: Option<char>,
        mailbox: Mailbox,
    },
    Lsub {
        items: Vec<FlagNameAttribute>,
        delimiter: Option<char>,
        mailbox: Mailbox,
    },
    Status {
        mailbox: Mailbox,
        attributes: Vec<StatusAttributeValue>,
    },
    Search(Vec<NonZeroU32>),
    Flags(Vec<Flag>),
    Exists(u32),
    Recent(u32),
    Expunge(NonZeroU32),
    Fetch {
        seq_or_uid: NonZeroU32,
        attributes: Vec<MessageAttribute>,
    },
    Enabled {
        capabilities: Vec<Capability>,
    },
}

7.2 - 7.4 Server and Mailbox Status; Mailbox Size; Message Status

Variants

Capability(Vec<Capability>)

7.2.1. CAPABILITY Response

• Contents: capability listing

The CAPABILITY response occurs as a result of a CAPABILITY command. The capability listing contains a space-separated listing of capability names that the server supports. The capability listing MUST include the atom “IMAP4rev1”.

In addition, client and server implementations MUST implement the STARTTLS, LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS]) capabilities. See the Security Considerations section for important information.

A capability name which begins with “AUTH=” indicates that the server supports that particular authentication mechanism.

The LOGINDISABLED capability indicates that the LOGIN command is disabled, and that the server will respond with a tagged NO response to any attempt to use the LOGIN command even if the user name and password are valid. An IMAP client MUST NOT issue the LOGIN command if the server advertises the LOGINDISABLED capability.

Other capability names indicate that the server supports an extension, revision, or amendment to the IMAP4rev1 protocol. Server responses MUST conform to this document until the client issues a command that uses the associated capability.

Capability names MUST either begin with “X” or be standard or standards-track IMAP4rev1 extensions, revisions, or amendments registered with IANA. A server MUST NOT offer unregistered or non-standard capability names, unless such names are prefixed with an “X”.

Client implementations SHOULD NOT require any capability name other than “IMAP4rev1”, and MUST ignore any unknown capability names.

A server MAY send capabilities automatically, by using the CAPABILITY response code in the initial PREAUTH or OK responses, and by sending an updated CAPABILITY response code in the tagged OK response as part of a successful authentication. It is unnecessary for a client to send a separate CAPABILITY command if it recognizes these automatic capabilities.

Tuple Fields of Capability

0: Vec<Capability>

List

7.2.2. LIST Response

The LIST response occurs as a result of a LIST command. It returns a single name that matches the LIST specification. There can be multiple LIST responses for a single LIST command.

The hierarchy delimiter is a character used to delimit levels of hierarchy in a mailbox name. A client can use it to create child mailboxes, and to search higher or lower levels of naming hierarchy. All children of a top-level hierarchy node MUST use the same separator character. A NIL hierarchy delimiter means that no hierarchy exists; the name is a “flat” name.

The name represents an unambiguous left-to-right hierarchy, and MUST be valid for use as a reference in LIST and LSUB commands. Unless \Noselect is indicated, the name MUST also be valid as an argument for commands, such as SELECT, that accept mailbox names.

Fields of List

items: Vec<FlagNameAttribute>

Name attributes

delimiter: Option<char>

Hierarchy delimiter

mailbox: Mailbox

Name

Lsub

7.2.3. LSUB Response

The LSUB response occurs as a result of an LSUB command. It returns a single name that matches the LSUB specification. There can be multiple LSUB responses for a single LSUB command. The data is identical in format to the LIST response.

Fields of Lsub

items: Vec<FlagNameAttribute>

Name attributes

delimiter: Option<char>

Hierarchy delimiter

mailbox: Mailbox

Name

Status

7.2.4 STATUS Response

The STATUS response occurs as a result of an STATUS command. It returns the mailbox name that matches the STATUS specification and the requested mailbox status information.

Fields of Status

mailbox: Mailbox

Name

attributes: Vec<StatusAttributeValue>

Status parenthesized list

Search(Vec<NonZeroU32>)

7.2.5. SEARCH Response

• Contents: zero or more numbers

The SEARCH response occurs as a result of a SEARCH or UID SEARCH command. The number(s) refer to those messages that match the search criteria. For SEARCH, these are message sequence numbers; for UID SEARCH, these are unique identifiers. Each number is delimited by a space.

Tuple Fields of Search

0: Vec<NonZeroU32>

Flags(Vec<Flag>)

7.2.6. FLAGS Response

• Contents: flag parenthesized list

The FLAGS response occurs as a result of a SELECT or EXAMINE command. The flag parenthesized list identifies the flags (at a minimum, the system-defined flags) that are applicable for this mailbox. Flags other than the system flags can also exist, depending on server implementation.

The update from the FLAGS response MUST be recorded by the client.

Tuple Fields of Flags

0: Vec<Flag>

Exists(u32)

7.3.1. EXISTS Response

The EXISTS response reports the number of messages in the mailbox. This response occurs as a result of a SELECT or EXAMINE command, and if the size of the mailbox changes (e.g., new messages).

The update from the EXISTS response MUST be recorded by the client.

Tuple Fields of Exists

0: u32

Recent(u32)

7.3.2. RECENT Response

The RECENT response reports the number of messages with the \Recent flag set. This response occurs as a result of a SELECT or EXAMINE command, and if the size of the mailbox changes (e.g., new messages).

Note: It is not guaranteed that the message sequence numbers of recent messages will be a contiguous range of the highest n messages in the mailbox (where n is the value reported by the RECENT response). Examples of situations in which this is not the case are: multiple clients having the same mailbox open (the first session to be notified will see it as recent, others will probably see it as non-recent), and when the mailbox is re-ordered by a non-IMAP agent.

The only reliable way to identify recent messages is to look at message flags to see which have the \Recent flag set, or to do a SEARCH RECENT.

The update from the RECENT response MUST be recorded by the client.

Tuple Fields of Recent

0: u32

Expunge(NonZeroU32)

7.4.1. EXPUNGE Response

The EXPUNGE response reports that the specified message sequence number has been permanently removed from the mailbox. The message sequence number for each successive message in the mailbox is immediately decremented by 1, and this decrement is reflected in message sequence numbers in subsequent responses (including other untagged EXPUNGE responses).

The EXPUNGE response also decrements the number of messages in the mailbox; it is not necessary to send an EXISTS response with the new value.

As a result of the immediate decrement rule, message sequence numbers that appear in a set of successive EXPUNGE responses depend upon whether the messages are removed starting from lower numbers to higher numbers, or from higher numbers to lower numbers. For example, if the last 5 messages in a 9-message mailbox are expunged, a “lower to higher” server will send five untagged EXPUNGE responses for message sequence number 5, whereas a “higher to lower server” will send successive untagged EXPUNGE responses for message sequence numbers 9, 8, 7, 6, and 5.

An EXPUNGE response MUST NOT be sent when no command is in progress, nor while responding to a FETCH, STORE, or SEARCH command. This rule is necessary to prevent a loss of synchronization of message sequence numbers between client and server. A command is not “in progress” until the complete command has been received; in particular, a command is not “in progress” during the negotiation of command continuation.

Note: UID FETCH, UID STORE, and UID SEARCH are different commands from FETCH, STORE, and SEARCH. An EXPUNGE response MAY be sent during a UID command.

The update from the EXPUNGE response MUST be recorded by the client.

Tuple Fields of Expunge

0: NonZeroU32

Fetch

7.4.2. FETCH Response

The FETCH response returns data about a message to the client. The data are pairs of data item names and their values in parentheses. This response occurs as the result of a FETCH or STORE command, as well as by unilateral server decision (e.g., flag updates).

Fields of Fetch

seq_or_uid: NonZeroU32

Message SEQ or UID

attributes: Vec<MessageAttribute>

Message data

Enabled

—– ENABLE Extension (RFC 5161) —–

Fields of Enabled

capabilities: Vec<Capability>

Trait Implementations

impl Clone for Data

fn clone(&self) -> Data

Returns a copy of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for Data

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Encode for Data

fn encode(&self, writer: &mut impl Write) -> Result<()>

impl Hash for Data

fn hash<__H: Hasher>(&self, state: &mut __H)

Feeds this value into the given Hasher.

fn hash_slice<H>(data: &[Self], state: &mut H) where
    H: Hasher, 

Feeds a slice of this type into the given Hasher.

impl PartialEq<Data> for Data

fn eq(&self, other: &Data) -> bool

This method tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Data) -> bool

This method tests for !=.

impl Eq for Data

impl StructuralEq for Data

impl StructuralPartialEq for Data