Struct imap_types::response::data::Envelope

pub struct Envelope<'a> {
    pub date: NString<'a>,
    pub subject: NString<'a>,
    pub from: Vec<Address<'a>>,
    pub sender: Vec<Address<'a>>,
    pub reply_to: Vec<Address<'a>>,
    pub to: Vec<Address<'a>>,
    pub cc: Vec<Address<'a>>,
    pub bcc: Vec<Address<'a>>,
    pub in_reply_to: NString<'a>,
    pub message_id: NString<'a>,
}

The fields of the envelope structure are in the following order: date, subject, from, sender, reply-to, to, cc, bcc, in-reply-to, and message-id. The date, subject, in-reply-to, and message-id fields are strings. The from, sender, reply-to, to, cc, and bcc fields are parenthesized lists of address structures.

See Address.

[RFC-2822] group syntax is indicated by a special form of address structure in which the host name field is NIL. If the mailbox name field is also NIL, this is an end of group marker (semi-colon in RFC 822 syntax). If the mailbox name field is non-NIL, this is a start of group marker, and the mailbox name field holds the group name phrase.

If the Date, Subject, In-Reply-To, and Message-ID header lines are absent in the [RFC-2822] header, the corresponding member of the envelope is NIL; if these header lines are present but empty the corresponding member of the envelope is the empty string.

Note: some servers may return a NIL envelope member in the “present but empty” case. Clients SHOULD treat NIL and empty string as identical.

Note: [RFC-2822] requires that all messages have a valid Date header. Therefore, the date member in the envelope can not be NIL or the empty string.

Note: [RFC-2822] requires that the In-Reply-To and Message-ID headers, if present, have non-empty content. Therefore, the in-reply-to and message-id members in the envelope can not be the empty string.

If the From, To, cc, and bcc header lines are absent in the [RFC-2822] header, or are present but empty, the corresponding member of the envelope is NIL.

If the Sender or Reply-To lines are absent in the [RFC-2822] header, or are present but empty, the server sets the corresponding member of the envelope to be the same value as the from member (the client is not expected to know to do this).

Note: [RFC-2822] requires that all messages have a valid From header. Therefore, the from, sender, and reply-to members in the envelope can not be NIL. TODO(#31): many invariants here…

Fields

date: NString<'a>

subject: NString<'a>

from: Vec<Address<'a>>

sender: Vec<Address<'a>>

reply_to: Vec<Address<'a>>

to: Vec<Address<'a>>

cc: Vec<Address<'a>>

bcc: Vec<Address<'a>>

in_reply_to: NString<'a>

message_id: NString<'a>

Trait Implementations

impl<'a> Clone for Envelope<'a>

fn clone(&self) -> Envelope<'a>

Returns a copy of the value.

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

Performs copy-assignment from source.

impl<'a> Debug for Envelope<'a>

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

Formats the value using the given formatter.

impl<'a> Encode for Envelope<'a>

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

impl<'a> Hash for Envelope<'a>

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<'a> PartialEq<Envelope<'a>> for Envelope<'a>

fn eq(&self, other: &Envelope<'a>) -> bool

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

fn ne(&self, other: &Envelope<'a>) -> bool

This method tests for !=.

impl<'a> Eq for Envelope<'a>

impl<'a> StructuralEq for Envelope<'a>

impl<'a> StructuralPartialEq for Envelope<'a>