Estate Agent Mail Access — Nick Tart Viewing Emails

Background: John asked Claude to find emails from the new estate agent (Nick Tart, contact Scott Turner — see personal/house-sale-tettenhall) about viewings. Gmail search (Gmail:search_threads) returned nothing for from:nicktart.com, "nick tart", or "Scott Turner" — the relevant mail lives on the personal MS Live/Outlook (live.com) account, not Gmail.

No Claude connector covers this

Checked search_mcp_registry for outlook/microsoft/live.com/email connectors. Found Microsoft 365 (directoryUuid ce0c9cda-5ea5-44c5-9cf2-40810dfa6582) but it only authenticates against work/school (M365 tenant) accounts, not a personal live.com/outlook.com consumer account — confirmed by John. No other listed connector fits (Superhuman Mail supports Gmail & Outlook but wasn't pursued once the better option below was found).

The mail store only holds routed addresses — correction

Initial assumption was that popit3.py's raw store (~/.email3.mail.gdbm, key=UIDL) captures every message fetched from the account regardless of routing, since popit3/architecture describes sync as a step prior to dispatch. John corrected this (2026-09-05): only emails with a set-up destination (i.e. an address in the routing table — see popit3/email-routing) actually go into the mail store. Mail to unrouted addresses is not captured there.

Implication: unless Nick Tart's emails happen to be arriving at one of the routed john.xxx@critchley.biz aliases (unlikely for an estate agent), they are almost certainly not sitting in ~/.email3.mail.gdbm. The earlier "very likely already sitting in the store" conclusion in this note was wrong and is superseded by this correction.

What's actually needed

Establish which address the estate agent is actually emailing — if it's a routed critchley.biz alias, the mail should already be in the store (check there first). If it's John's plain live.com/outlook.com address directly, it isn't captured at all today.
If it's the plain address and John wants this mail visible to Claude/automation going forward, add a routing entry for it (per popit3/email-routing) so future messages land in the store or an IMAP folder — this only captures new mail from that point on, not anything already received.
For mail already received and not routed, it can only be read directly in the Outlook.com mailbox itself (webmail or an Outlook client) — there's no way to retrieve it from the existing popit3 store after the fact, since it was never downloaded/stored.

Open design question: should storing be the default?

John's reaction (2026-09-05) to the routed-only correction above: rather than treating "only routed addresses get stored" as a fixed constraint, worth deciding whether storing to the mail store should become the default for all incoming mail, with routing/handlers layered on top as additional processing — rather than storage being gated on a routing entry existing. This is an architecture decision, not yet made or actioned; see the corresponding entry in popit3/todo.

Why Claude couldn't just check