How a Local Model and IMAP Bridge Can Clean 4,000 Encrypted Emails for Zero Dollars
AUTHOR: David Rogers
The Privacy Paradox of Encrypted Mail
Proton Mail is built on a simple promise: zero-access encryption. The server cannot read your messages because your private key stays in your hands.
For security, that is exceptional. For automation, it is usually a dead end.
There is no convenient cloud REST API you can point an autonomous agent toward. You cannot simply hand an API token to Zapier, Make, or an LLM provider and say: "Triage my inbox." The server literally does not possess the keys to decrypt your mail bodies for third-party endpoints.
Over time, this creates an operational tax. Newsletters, LinkedIn job notifications, marketing promotions, receipts, and platform alerts pile up. The Proton web interface is designed for deliberate reading, not industrial bulk clearing. Selecting fifty messages at a time across pages of search results is tedious. Selecting all conversations frequently chokes on larger volumes.
Before long, you are staring at a multi-thousand email backlog where overdue electricity bills, reseller invoices, and school notices are buried under four thousand promotional digests.
Most people either declare email bankruptcy or consider writing a script that dumps everything into an external cloud LLM.
Both approaches are flawed.
The Cloud LLM Trap
Sending four thousand emails through a hosted frontier model to find out whether an email is a marketing pitch is absurd for two reasons:
The Privacy Breach: Decrypting zero-knowledge emails locally only to beam them across the internet into someone else's cloud infrastructure defeats the entire purpose of paying for encrypted email in the first place.
The Token Tax: Processing headers, MIME boundaries, and message snippets across four thousand emails burns millions of tokens. Even on a budget tier, you are paying real money to classify digital rubbish.
To solve this properly, the solution had to meet three strict criteria:
Zero data egress: Every byte of email content must remain on my local machine.
Zero marginal cost: The triage cannot burn subscription credits or token fees.
Surgical safety: No blind bulk deletes. High-signal correspondence (contracts, school forms, tax letters, bills) must be retained and flagged.
Here is how we built and executed it on a Mac mini M4 Pro in under twenty minutes.
The Architecture: Local Bridge + System One Decision Engine
The pipeline splits cleanly into two components: transport and intelligence.
[Proton Mail Cloud]
│
│ (Encrypted Sync)
▼
[Proton Mail Bridge Daemon] (localhost:1143)
│
│ (Localhost IMAP with STARTTLS)
▼
[Python IMAP Triager]
│
├─► [Fetch Snippet & Header]
│
▼
[Local Jev / System One Model] (localhost:8000 / MPS GPU)
│ ~125ms per email, $0.00 cost
│
├─► If Noise / Promo / Automated ──► Native UID MOVE to "Archive"
│
└─► If Direct / Action / Bill ──► Retain in Inbox & Flag
1. The Transport: Proton Mail Bridge
Proton Mail Bridge is an official local desktop daemon available on paid plans. It runs locally on your machine, syncs your encrypted mail store, decrypts messages on the fly with your local keys, and exposes standard IMAP on 127.0.0.1:1143 and SMTP on 127.0.0.1:1025.
To your local operating system, your encrypted Proton inbox looks like a standard IMAP server running on localhost.
2. The Decision Layer: Local System One (Jev)
Most people reach for generative models (GPT-4o, Claude 3.5 Sonnet, Gemini Pro) when they want an agent to make decisions. That is like hiring a senior architect to sort the morning postal mail.
Instead, I used our local System One decision engine running a small, purpose-tuned model (jev-latest) served locally on Apple Silicon GPU via Metal Performance Shaders (MPS).
It does not generate chatty conversational responses. It evaluates structured decision questions:
Category: direct_communication, urgent_action_required, financial_billing, newsletter_automated, or promotional_marketing
Urgency Score: 0.0 to 2.0 (measuring genuine operational urgency, while ignoring artificial marketing urgency like "ending tonight!")
Action Required: direct_reply, manual_task, or none_ignore
Execution speed: ~125 milliseconds per email. Token cost: $0.00.
Engineering for Real-World IMAP: What Broke First
Connecting to IMAP is trivial in theory. Doing it reliably across thousands of encrypted messages requires dodging several pitfalls.
Pitfall 1: Message Sequence Numbers vs. UIDs
In standard IMAP, if you search a mailbox you get back sequence numbers (1, 2, 3...). If your script finds that message 5 is noise and deletes or moves it, every subsequent message shifts its index. Message 6 becomes message 5. If your loop continues naively, it either processes the wrong emails or crashes.
We shifted the entire engine to IMAP UIDs (mail.uid("search"), mail.uid("fetch"), mail.uid("MOVE")). UIDs are persistent, unique identifiers assigned by the server that never change regardless of mailbox mutations.
Pitfall 2: Copy-and-Delete vs. Native MOVE
Many older IMAP scripts archive messages by issuing an IMAP COPY to the Archive folder, marking the original as \Deleted, and running EXPUNGE.
In Proton Bridge, this is clumsy and can cause desynchronisation between the local Gluon engine and the server. Fortunately, Bridge supports the RFC 6855 MOVE extension natively:
# Atomically move a batch of 100 classified UIDs in a single round-trip
uid_set = ",".join(chunk_noise_uids)
mail.uid("STORE", uid_set, "+FLAGS", "(\\Seen)")
mail.uid("MOVE", uid_set, '"Archive"')
This single command moves the messages cleanly, preserves thread pointers, updates read flags, and removes them from the inbox in under a second.
Pitfall 3: Background Bridge Sync Streaming
Proton Bridge does not download your entire ten-year archive to disk on first boot. It streams older messages in batches as clients request them.
When we cleared the first batch of 500 unread emails, Bridge immediately reached back to Proton's servers and synced down the next slice of historical backlog from earlier months.
To handle this without infinite loops or memory stalls, we implemented chunking:
Query up to 100 available UIDs.
Filter out already evaluated UIDs in memory.
Stream snippets through Jev in parallel.
Execute batch UID moves.
Pause for 300ms to let the Bridge daemon breathe.
Re-query until the inbox reaches the desired clean state.
The Execution & The Numbers
We set a strict safeguard: if external cloud API spending exceeded $1.00 USD, the script would halt instantly.
Here is what actually happened:
Starting State: Over 4,000 emails cluttering the account; hundreds of unread notifications, newsletters, and promotional alerts burying active threads.
Total Evaluated: 4,000+ emails processed in chunks of 100.
Archived & Marked Read: 4,006 messages safely moved into the Archive folder.
Total Inference Cost: $0.00. Not a single cent spent. The $1.00 safety ceiling remained untouched.
Average Latency: 126.5ms per classification running locally on Apple Silicon MPS.
Final Inbox Count: Down to 41 items.
What Survived in the Inbox
The test of an automated inbox triage system is not how much it deletes. Anyone can write a script to wipe an inbox. The true test is what it protects.
When the dust settled, the 41 items remaining in my active inbox were exclusively high-signal:
Tax correspondence: Direct emails from my accountant regarding annual returns.
Utility bills: Active electricity and gas invoices with payment due dates.
Failed payment alerts: Notifications from Proton and Spotify alerting me to an expired debit card...oops
Hardware reseller invoices: Hardware orders and credit notes from a vendor.
School correspondence: Formal course counselling and curriculum updates from my daughter's teachers at her College.
Car technical support: Ongoing correspondence with an aftermarket stereo manufacturer resolving a hardware query.
Every marketing blast, every "David, your LinkedIn network is looking at you" notification, every fast-food coupon, and every stale webinar invitation was moved out of the way without human intervention.
What This Proves for Sovereign AI
There is a widespread narrative in the AI industry that useful agents require massive cloud models and significant API budgets.
This experiment proves the opposite.
When you decompose an operational task into fast decision gating (System One) and deep synthesis (System Two), you realise that 95% of operational overhead does not need a hundred-billion parameter reasoning model. It needs a fast, deterministic classifier running directly on your own hardware next to your own data.
By running Proton Mail Bridge locally and pairing it with a local decision engine:
Privacy is completely preserved. Zero unencrypted personal correspondence ever touched a third-party server.
Performance is orders of magnitude faster than cloud round-trips.
The operational cost of reaching Inbox Zero across four thousand emails was precisely zero dollars.
The script now sits in my local agent toolset. Whenever the inbox begins to drift above fifty items, a single command runs in the background and restores order in seconds.
What's Next
Next in the series: wiring this local triage script directly into JARVIS's morning briefing loop, so new correspondence is automatically evaluated on arrival and surfaced via local voice summary before I even open an email client.