#[non_exhaustive]pub struct Email {Show 27 fields
pub id: Id,
pub blob_id: Id,
pub thread_id: Id,
pub mailbox_ids: HashMap<Id, bool>,
pub keywords: HashMap<Keyword, bool>,
pub size: u64,
pub received_at: UTCDate,
pub message_id: Option<Vec<String>>,
pub in_reply_to: Option<Vec<String>>,
pub references: Option<Vec<String>>,
pub sender: Option<Vec<EmailAddress>>,
pub from: Option<Vec<EmailAddress>>,
pub to: Option<Vec<EmailAddress>>,
pub cc: Option<Vec<EmailAddress>>,
pub bcc: Option<Vec<EmailAddress>>,
pub reply_to: Option<Vec<EmailAddress>>,
pub subject: Option<String>,
pub sent_at: Option<Date>,
pub headers: Vec<EmailHeader>,
pub body_values: HashMap<String, EmailBodyValue>,
pub text_body: Vec<EmailBodyPart>,
pub html_body: Vec<EmailBodyPart>,
pub attachments: Vec<EmailBodyPart>,
pub body_structure: Option<EmailBodyPart>,
pub has_attachment: bool,
pub preview: Option<String>,
pub extra: Map<String, Value>,
}Expand description
An Email object (RFC 8621 §4.1).
Combines metadata (§4.1.1), parsed header convenience properties (§4.1.3), and body fields (§4.1.4).
§Full vs partial responses
This type is designed for full Email/get responses where all metadata
properties are present. The metadata fields blob_id, thread_id,
mailbox_ids, size, and received_at are required (non-Option);
deserialization fails if any of them is absent from the JSON.
RFC 8621 §4.5 allows clients to request only a subset of properties. If
a partial response omits any required metadata field, serde_json::from_str
will return a “missing field” error. For partial-property responses,
deserialize into serde_json::Value first or define a narrower type with
all fields Option.
Header convenience properties (§4.1.3) and body fields (§4.1.4) are all
Option; they deserialize as None when not included in the response.
§Serialization caveat for server implementors
Several collection fields (keywords, body_values, text_body,
html_body, attachments, headers) use
#[serde(skip_serializing_if = "…::is_empty")]. This is correct for
partial responses — a property not in the client’s properties list MUST be
absent from the response. However, RFC 8621 §4.1.1 defines keywords with
default: {}, meaning a server MUST include "keywords":{} in the response
when the property was requested and the email has no keywords.
Do not rely on serde_json::to_value(email) to produce RFC-compliant JSON
for full-object responses. Server code in jmap-mail-server must
explicitly populate any collection fields that are in the requested
properties set before serialization, or use a custom serializer that
includes them.
Fields (Non-exhaustive)§
This struct is marked as non-exhaustive
Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.id: IdThe JMAP object id of this Email.
blob_id: IdBlob id of the raw RFC 5322 message octets.
thread_id: IdId of the Thread this Email belongs to.
mailbox_ids: HashMap<Id, bool>Set of Mailbox ids this Email belongs to.
Represented as HashMap<Id, bool> because the JMAP wire format uses a JSON object
with boolean values (RFC 8621 §4.1.1). Values are always true in full-object
responses; the map shape is also used in PatchObject updates (RFC 8620 §5.3) where
a null value removes an entry.
keywords: HashMap<Keyword, bool>Keywords applied to this Email.
Same JSON object shape as mailbox_ids (string keys, boolean values) — JMAP wire
format requirement. Keys are Keyword values (not JMAP Ids); system keywords
start with $ which is not valid inside a JMAP Id (RFC 8620 §1.2).
Values are always true in full-object responses (RFC 8621 §4.1.1).
size: u64Size in octets of the raw RFC 5322 message.
received_at: UTCDateDate the Email was received by the message store.
message_id: Option<Vec<String>>Value of the Message-ID header field as a list of message ids.
in_reply_to: Option<Vec<String>>Value of the In-Reply-To header field as a list of message ids.
references: Option<Vec<String>>Value of the References header field as a list of message ids.
sender: Option<Vec<EmailAddress>>Parsed addresses from the Sender header field.
from: Option<Vec<EmailAddress>>Parsed addresses from the From header field.
to: Option<Vec<EmailAddress>>Parsed addresses from the To header field.
cc: Option<Vec<EmailAddress>>Parsed addresses from the Cc header field.
bcc: Option<Vec<EmailAddress>>Parsed addresses from the Bcc header field.
reply_to: Option<Vec<EmailAddress>>Parsed addresses from the Reply-To header field.
subject: Option<String>Decoded text value of the Subject header field.
sent_at: Option<Date>Parsed value of the Date header field (RFC 8621 §4.1.3).
Type Date (any RFC 3339 timezone offset) per the RFC. Email Date
headers commonly carry non-UTC offsets such as "+10:00".
headers: Vec<EmailHeader>All header fields of the message in Raw form, in order.
body_values: HashMap<String, EmailBodyValue>Map from partId to decoded text content for text body parts.
text_body: Vec<EmailBodyPart>Text body parts to display, preferring text/plain.
html_body: Vec<EmailBodyPart>HTML body parts to display, preferring text/html.
attachments: Vec<EmailBodyPart>All attachment parts (depth-first, excluding subParts).
body_structure: Option<EmailBodyPart>Full MIME body structure of the message.
has_attachment: boolTrue if there is at least one downloadable attachment.
preview: Option<String>Short plaintext preview of the message body (≤256 characters).
extra: Map<String, Value>Catch-all for vendor / site / private extension fields not covered by the typed fields above. Preserves unknown fields across deserialize/serialize round-trip per workspace extras-preservation policy (see workspace AGENTS.md).