Enum imap_types::response::Data
source · pub enum Data<'a> {
Show 13 variants
Capability(NonEmptyVec<Capability<'a>>),
List {
items: Vec<FlagNameAttribute<'a>>,
delimiter: Option<QuotedChar>,
mailbox: Mailbox<'a>,
},
Lsub {
items: Vec<FlagNameAttribute<'a>>,
delimiter: Option<QuotedChar>,
mailbox: Mailbox<'a>,
},
Status {
mailbox: Mailbox<'a>,
items: Cow<'a, [StatusDataItem]>,
},
Search(Vec<NonZeroU32>),
Flags(Vec<Flag<'a>>),
Exists(u32),
Recent(u32),
Expunge(NonZeroU32),
Fetch {
seq: NonZeroU32,
items: NonEmptyVec<MessageDataItem<'a>>,
},
Enabled {
capabilities: Vec<CapabilityEnable<'a>>,
},
Quota {
root: AString<'a>,
quotas: NonEmptyVec<QuotaGet<'a>>,
},
QuotaRoot {
mailbox: Mailbox<'a>,
roots: Vec<AString<'a>>,
},
}
Expand description
Variants§
Capability(NonEmptyVec<Capability<'a>>)
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.
List
Fields
items: Vec<FlagNameAttribute<'a>>
Name attributes
delimiter: Option<QuotedChar>
Hierarchy delimiter
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.
Lsub
Fields
items: Vec<FlagNameAttribute<'a>>
Name attributes
delimiter: Option<QuotedChar>
Hierarchy delimiter
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.
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.
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.
Flags(Vec<Flag<'a>>)
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.
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.
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.
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.
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).
Enabled
Fields
capabilities: Vec<CapabilityEnable<'a>>
Quota
QuotaRoot
Implementations§
source§impl<'a> Data<'a>
impl<'a> Data<'a>
pub fn quota<R, Q>( root: R, quotas: Q ) -> Result<Self, QuotaError<R::Error, Q::Error>>where R: TryInto<AString<'a>>, Q: TryInto<NonEmptyVec<QuotaGet<'a>>>,
pub fn quota_root<M, R>( mailbox: M, roots: R ) -> Result<Self, QuotaRootError<M::Error, R::Error>>where M: TryInto<Mailbox<'a>>, R: TryInto<Vec<AString<'a>>>,
source§impl<'a> Data<'a>
impl<'a> Data<'a>
pub fn capability<C>(caps: C) -> Result<Self, C::Error>where C: TryInto<NonEmptyVec<Capability<'a>>>,
pub fn expunge(seq: u32) -> Result<Self, TryFromIntError>
pub fn fetch<S, I>( seq: S, items: I ) -> Result<Self, FetchError<S::Error, I::Error>>where S: TryInto<NonZeroU32>, I: TryInto<NonEmptyVec<MessageDataItem<'a>>>,
Trait Implementations§
source§impl<'a, 'arbitrary: 'a> Arbitrary<'arbitrary> for Data<'a>
impl<'a, 'arbitrary: 'a> Arbitrary<'arbitrary> for Data<'a>
source§fn arbitrary(u: &mut Unstructured<'arbitrary>) -> Result<Self>
fn arbitrary(u: &mut Unstructured<'arbitrary>) -> Result<Self>
Self
from the given unstructured data. Read moresource§fn arbitrary_take_rest(u: Unstructured<'arbitrary>) -> Result<Self>
fn arbitrary_take_rest(u: Unstructured<'arbitrary>) -> Result<Self>
Self
from the entirety of the given
unstructured data. Read more