NanoClaw’s Proton Mail proposal demonstrates an email round trip on Raspberry Pi

NanoClaw’s open Proton Mail proposal reports a concrete adoption experiment: building Proton Mail Bridge from a pinned upstream release on a Raspberry Pi 5, receiving an Outlook reply through IMAP IDLE, and returning the agent’s answer in the same email thread. The proposal was created September 6 and remains unmerged. It is evidence of a contributor-tested channel design, not a channel that every NanoClaw installation already has.

A separate September 8 AgentMail draft illustrates a different route to the same user-facing goal: a managed inbox with signed inbound webhooks instead of a locally operated mail bridge. The two are useful to compare because email support includes sender admission, reply identity, loops and attachment handling, not simply the ability to call an SMTP function.

The facts

- PR #3726 proposes a native IMAP/SMTP adapter connected to a local Proton Mail Bridge, with ARM64 and x86 source-build support. - Each correspondent is modeled as a direct message and unknown senders default to request_approval. - Inbound handling uses IMAP IDLE with a 60-second fallback poll and persists a cursor while skipping existing mail on first connection. - The design caps attachments at 15 MB, checks filenames and rejects automated senders and its own marked echoes. - The author reports a Raspberry Pi 5 round trip using Debian 13 and Docker 29.8; the setup requires a paid Proton plan. - Bridge listener ports are published on loopback only, and containers do not receive Bridge access. - Separate PR #3743 proposes AgentMail SDK delivery and Svix-verified webhooks, but its cited focused test establishes registration rather than a live mail round trip.

Why it matters

This is the difference between adding an email logo and describing an operable mailbox boundary. A self-hosted bridge avoids moving the whole account into an agent container, but adds a service, a vault and readiness checks that someone must maintain. Managed inboxes reduce that plumbing while changing where messages and credentials live. Neither approach should let arbitrary incoming mail become trusted instructions just because delivery was technically successful.

Current

Inspected on 2026-09-10. The NanoClaw stable-release baseline is v2.3.0 published 2026-08-24T11:45:32Z. The main source was open (not merged) when captured. Release metadata is a version boundary; an open proposal, a merged mainline change and a packaged release remain different states.

Evidence

The primary evidence is nanocoai/nanoclaw PR #3726 (https://github.com/nanocoai/nanoclaw/pull/3726). Supporting context comes from nanocoai/nanoclaw PR #3743 (https://github.com/nanocoai/nanoclaw/pull/3743); NanoClaw — official product and isolation model (https://nanoclaw.dev/); NanoClaw — current official README (https://raw.githubusercontent.com/nanocoai/nanoclaw/main/README.md). These pages were inspected directly. Related project records explain the source cluster; they are not independent replications of contributor test claims.

Operator take

Evaluate sender admission, threading, duplicate delivery and attachment rejection before granting a real mailbox. The Proton proposal’s readiness check waits for an IMAP greeting rather than a TCP accept, an important distinction when a forwarding process can listen before the underlying service is ready. Compare managed and bridge-based options on operational ownership, not only on setup convenience. Do not open loopback mail ports to make a remote test easier.

Caveat

Both adapters remain open proposals. The Proton round trip and test results are contributor-reported, not independently reproduced; its source also discloses unrelated full-suite failures. AgentMail’s registration and suite claims do not prove live delivery or every signature-failure path. This brief endorses neither service nor paid adoption.