Metadata-only analysis means the system works from a declared set of message headers, Gmail’s generated preview snippet, labels, dates, and engagement state without fetching the full or raw message body. It is data minimization, not content-free processing.
Separate headers, preview text, and full content
Email data is not binary. Identity and routing headers sit at one layer. Gmail’s snippet is a short preview generated by Gmail from message content. The full MIME message contains the complete text, HTML, inline assets, and attachments.
A metadata request can include selected headers and Gmail’s snippet without returning the full MIME parts. That materially reduces collection, but the snippet and subject may still contain a name, purchase, appointment, or other sensitive phrase.
What DeclutrMail stores
DeclutrMail’s published message-field disclosure lists: Gmail message and thread IDs, Sender name and email address, Subject, Gmail Preview (the short snippet shown in your inbox list), Received date, Gmail labels, Read or unread state, Whether a message was sent by you, Recipient email addresses from To and Cc on mail you sent, Unsubscribe links and whether one-click unsubscribe is supported, Gmail message size estimate.
It also stores derived sender aggregates and the user’s own decisions, automation settings, and activity records. Full message bodies, HTML, attachments, inline images, raw MIME, and headers outside the allowlist are not fetched or stored.
What can be inferred without a body
Sender frequency, time since last message, read rate, reply history, labels, and whether a sender is protected can support useful sender-level decisions. These facts answer questions such as “how often does this source arrive?” and “do I engage with it?” without parsing a complete email.
They cannot reliably answer what a specific message means. When a subject or snippet is ambiguous, the correct interface sends you to Gmail rather than pretending the metadata contains the whole story.
External processing still belongs in the disclosure
DeclutrMail’s sender-reasoning adapter receives aggregate facts and no subject or snippet. Daily Brief uses a different bounded input: sender identity, subject, and Gmail snippet may be sent to Anthropic to compose a short narrative when the adapter is configured.
That input remains body-free, and the stored Brief payload intentionally omits the snippets used in the prompt. Even so, sending allowlisted metadata to a processor is processing and should not be hidden behind “no full bodies.”
How to evaluate a metadata-only claim
Ask for implementation-level answers rather than accepting the category label.
- Which API format and required metadata are requested?
- Is a provider-generated snippet fetched or stored?
- Which derived aggregates are retained, and for how long?
- Does any feature send subjects or snippets to an external processor?
- Are logs, error reports, analytics, and exports barred from containing those fields?
- Can the user delete the index without deleting mail in Gmail?
The trade-off is reduced exposure, not zero exposure
Metadata-only design lowers the consequence of a breach because the service never possesses complete conversations or attachments. It also constrains product behavior: deep content search, complete summarization, and body-based classification should not be possible.
A trustworthy design treats those missing capabilities as proof of the boundary, not as gaps to work around silently.