Struct Address 

#[non_exhaustive]
pub struct Address {
    pub name: Option<String>,
    pub email: String,
}

An email address with optional display name.

References

• RFC 5322 Section 3.4 (address specification)

Fields (Non-exhaustive)

Non-exhaustive structs could have additional fields added in future. Therefore, non-exhaustive structs cannot be constructed in external crates using the traditional Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.

name: Option<String>

Display name, decoded from RFC 2047 encoded words if present.

email: String

Email address (addr-spec form).

Implementations

impl Address

pub fn new(email: impl Into<String>) -> Result<Self>

Creates an address with only an email, validating the syntax.

Errors

Returns crate::Error::InvalidAddress if the email is not valid per RFC 5322 Section 3.4.

pub fn with_name( name: impl Into<String>, email: impl Into<String>, ) -> Result<Self>

Creates an address with a display name and email, validating the syntax.

Errors

Returns crate::Error::InvalidAddress if the email is not valid per RFC 5322 Section 3.4.

pub fn new_unchecked(name: Option<String>, email: String) -> Self

Creates an Address without validating the email syntax.

You almost certainly want Address::new or Address::with_name instead

Those constructors validate the email address against RFC 5322 Section 3.4 and reject malformed input. An Address built with new_unchecked may contain syntax that is invalid for outgoing mail, which can cause:

• Rejected RCPT TO commands at the SMTP layer.
• Malformed From/To/Cc headers that downstream MTAs or MUAs cannot parse.
• Messages that silently disappear into spam filters or bounce queues.

When this method is appropriate

This exists for parser and protocol-conversion code that must accept addresses already received from the network, where Postel’s law applies (RFC 5322 Section 3.4): be liberal in what you accept. For example, an IMAP ENVELOPE address or a From: header parsed from an incoming message may contain syntax that is technically non-conformant but still meaningful. Rejecting it would discard data the user needs to see.

If you are building a new outgoing message, use Address::new or Address::with_name — they enforce the same validation the message builder applies and will catch mistakes at construction time rather than at send time.

Trait Implementations

impl Clone for Address

fn clone(&self) -> Address

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Debug for Address

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

Formats the value using the given formatter.

impl Display for Address

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

Formats the address per RFC 5322 Section 3.4.

• Non-ASCII display names are RFC 2047 encoded (RFC 5322 Section 2.2 requires header field bodies to be US-ASCII; RFC 2047 Section 5 defines the encoded-word mechanism for non-ASCII text).
• ASCII display names containing specials are quoted per RFC 5322 Section 3.2.4.
• Without display name: bare email

impl FromStr for Address

fn from_str(s: &str) -> Result<Self, Self::Err>

Parses an address from a string (RFC 5322 Section 3.4).

Accepts both Display Name <email> and bare email forms. Decodes RFC 2047 encoded words in the display name (RFC 2047 Section 5).

type Err = Error

The associated error which can be returned from parsing.

impl Hash for Address

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, Self: Sized,

Feeds a slice of this type into the given Hasher.

impl PartialEq for Address

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

Tests for self and other values to be equal, and is used by ==.

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

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl Eq for Address

impl StructuralPartialEq for Address