Reverse-Engineering The "Privacy Inbox": Building a Local-First Email Parser
Most users have hundreds of accounts tied to their primary email address. Over time, forgotten SaaS trials, ecommerce orders, and obsolete newsletter signups turn into a liability surface.
When you look for tools to map or reduce this footprint, you run into an ironic design pattern:
Almost every commercial inbox cleaner requires you to route your email metadata through their cloud servers. To reduce your exposure to third parties, you have to hand your entire inbox to another cloud database.
When building Paperweight, I took the opposite architectural path: building a local-first desktop app in TypeScript and Electron that parses inboxes, identifies accounts, and generates GDPR deletion requests entirely on-device.
Here is a look at the technical architecture, MIME classification heuristics, and the engineering tradeoffs of zero-server email analysis.
1. System Architecture: On-Device Processing
The core design constraint of Paperweight is simple: no email payload or metadata ever leaves the client machine.
Ingestion Pipeline
Direct Transport: Connects directly to the mail server via IMAP or local loopback OAuth (PKCE for Microsoft, loopback listener for Google Desktop App credentials).
Batch Header Scanning: Fetches minimal envelope metadata (RFC 822 headers) to minimize network overhead and avoid downloading full attachments.
Local SQLite Storage: Indexes extracted sender domains, list headers, and date bounds locally on-disk.
2. Classification Heuristics and Lexicons
Classifying millions of unstructured emails across multiple languages without sending text to remote LLMs requires lightweight, deterministic pattern matching.
Header-Level Signals
The engine inspects standard RFC headers first:
List-Unsubscribe/List-Unsubscribe-Post: Identifies automated mailing lists and extracts mailto/HTTP unsubscribe targets.Precedence: bulkorList-Id: Direct signals of broadcast communications.Authentication-Results(DKIM/SPF): Validates domain ownership to avoid spoofed sender footprints.
Phrase Lexicons (Multi-Language)
When RFC headers are absent, the parser evaluates localized phrase lexicons across email footers and bodies to catch:
Transactional receipts and account confirmations
Subscription preferences ("manage your preferences", "opt out", "afmelden", "abmelden")
Account security alerts
Rather than hardcoding language heuristics into the engine, lexicons are structured as plain data files in the codebase (analysis/src/data/lexicons/), making multi-language contributions straightforward.
3. Engineering Tradeoffs of Local-First
Building a privacy-first utility without server infrastructure presents specific engineering challenges:
Zero Telemetry Debugging
With no server-side Sentry logging or central telemetry, bug diagnosis relies completely on automated unit tests, reproducible MIME fixtures, and user-submitted issue logs with redacted headers.
Memory and Parser Bounds in Electron
Parsing deep MIME multipart structures inside Node.js streams requires strict memory boundaries to prevent the Electron main process from bloating on inboxes with 100,000+ messages.
Open Source and Building in Public
Paperweight is 100% open-source under the MIT License on GitHub.
If you are interested in local-first software, client-side data parsing, or contributing language lexicons, check out the repository or test the app on your own inbox:
Source Code: github.com/wslyvh/paperweight
Website: paperweight.email