Metadata-only analysis means the system works from a listed set of message headers, Gmail’s preview snippet, labels, dates, and read state without fetching the complete or raw email. It reduces data collection; it does not mean the system receives no text.
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 limited Gmail request can include selected headers and Gmail’s preview snippet without returning the complete email. That materially reduces collection, but the snippet and subject line may still contain a name, purchase, appointment, or other sensitive phrase.
What DeclutrMail stores
DeclutrMail’s published message-field disclosure lists: Gmail message and conversation IDs, Sender name and email address, Subject line, Gmail preview snippet (the short text shown in your inbox list), Date received, Gmail labels, Your Gmail label names, Read or unread state, Whether a message was sent by you, Recipient email addresses from To and Cc on email you sent, Unsubscribe links and whether one-click unsubscribe is supported, Estimated Gmail message size.
It also stores sender totals, read rates, the user’s decisions, automation settings, and Activity history. Full email contents, HTML, attachments, embedded images, raw email source, and headers outside the published list are not fetched or stored.
What can be inferred without a body
Sender frequency, time since the last email, read rate, reply history, labels, and whether a sender is protected can support useful sender decisions. These facts answer questions such as “how often does this sender email me?” and “do I engage with it?” without parsing a complete email.
They cannot reliably answer what a specific email means. When a subject line or snippet is ambiguous, the correct interface sends you to Gmail rather than pretending those details contain the whole story.
External processing still belongs in the disclosure
To explain a suggestion, Anthropic receives sender totals and read rates but no subject line or snippet. Daily Brief works differently: it may send the sender, subject line, and Gmail preview snippet to Anthropic to compose a short summary.
Full email contents are not sent, and the saved Brief omits the snippets used to create it. Even so, sending any listed Gmail details to another company 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 Gmail details 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 email 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.