imap-mcp

Quelloffen, kein Produkt. Dies ist ein generischer IMAP → MCP-Server, der auf Cloudflare Workers läuft. Er ist unter MIT veröffentlicht, damit der Code gelesen, kopiert und daraus gelernt werden kann – aber er ist für genau ein Postfach gebaut und wird dagegen betrieben: ein persönliches iCloud-Konto. Es gibt keine Support-Zusage: Issues werden nicht bearbeitet, Pull Requests sind nicht erwünscht, es gibt keine Releases, und nichts hier ist für die Nutzung durch andere versioniert. Wenn es für dich nützlich ist, forke es.

Es ist eher aus Design als aus Ehrgeiz generisch – Host, Port und Anmeldedaten sind Konfiguration, keine Konstanten –, sodass es gegen jeden IMAP-Server funktionieren sollte. Tatsächlich getestet wird nur iCloud.

Status: Gerüst. Noch ist nichts Funktionales implementiert. Beide Worker sind Platzhalter, die installieren, linten, typchecken, testen und einen Deploy-Dry-Run bestehen. Siehe Roadmap.

Was es tut

Indiziert ein Postfach in den Speicher von Cloudflare und stellt es dann einem MCP-Client als Such- und Abrufwerkzeuge bereit – sodass ein Modell Fragen zu fünfzehn Jahren E-Mail beantworten kann, ohne dass das Postfach selbst bei jeder Abfrage im Spiel ist.

   ┌────────────────────┐  IMAP over TLS   ┌──────────────┐
   │  imap-mcp-sync     │ ───────────────▶ │   mailbox    │
   │  packages/sync     │ ◀─────────────── │   (iCloud)   │
   │  cron, owns creds  │                  └──────────────┘
   └─────────┬──────────┘
             │ writes                    ▲ writes proxied over
             ▼                           │ a service binding
   ┌────────────────────┐                │
   │  D1 (+FTS5) and R2 │                │
   └─────────┬──────────┘                │
             │ reads                     │
             ▼                           │
   ┌────────────────────┐────────────────┘   ┌──────────────┐
   │  imap-mcp-server   │  Streamable HTTP   │  MCP client  │
   │  packages/mcp      │ ◀───────────────── │  behind CF   │
   │  stateless, no creds                    │  Access      │
   └────────────────────┘                    └──────────────┘

Zwei Worker, und die Trennung zwischen ihnen ist eher das Sicherheitsdesign als eine Verpackungsentscheidung:

• packages/sync (imap-mcp-sync) ist der einzige Teil des Systems, der IMAP spricht. Es hält das app-spezifische Passwort – das bei iCloud vollen Postfachzugriff einschließlich SMTP-Senden gewährt –, sodass diese Anmeldedaten an genau einer Stelle existieren.

• packages/mcp (imap-mcp-server) ist ein zustandsloser Leser. Er fragt den Index ab, niemals das Postfach, und leitet die wenigen Schreiboperationen über ein Service-Binding an den Sync-Worker zurück, anstatt eine eigene Verbindung zu öffnen.

Related MCP server: stalwart-mail-mcp

Schnellstart

pnpm install         # installs both packages
pnpm run lint        # biome check (lint + format)
pnpm run typecheck   # wrangler types + tsc --noEmit
pnpm run test        # vitest, inside workerd
pnpm run dead-code   # knip
pnpm run build       # wrangler deploy --dry-run, both workers

Pro Paket, aus packages/sync oder packages/mcp: pnpm run dev, pnpm run test:watch, pnpm run deploy.

Konfiguration

Dieses Repository ist öffentlich, daher werden keine deploymentspezifischen Werte eingecheckt – keine Cloudflare-Konto-ID, kein Zonen-Tag, keine Cloudflare-Access-Teamdomain oder Anwendungs-Audience (AUD), keine Postfachadresse. Keine der wrangler.jsonc-Dateien enthält eine account_id, und der MCP-Worker deklariert überhaupt keine Route.

Alles, was du angeben musst, ist in .env.example benannt und erklärt. Kopiere es in .env und fülle es aus. Kurz:

Lokal kommen Geheimnisse in eine gitignorierte .dev.vars pro Paket; jedes hat eine .dev.vars.example zum Kopieren.

Beide Worker sind standardmäßig nicht erreichbar

workers_dev und preview_urls sind in beiden wrangler.jsonc-Dateien auf false gesetzt, und der MCP-Worker deklariert keine Route. Ein frischer Deploy ist daher aus dem Internet nicht erreichbar. Das ist beabsichtigt: Ohne Ordnerbegrenzung ist der MCP-Endpunkt funktional ein Lesezugriff auf ein ganzes Postfach, daher darf er nicht erreichbar werden, bevor Cloudflare Access davor steht. Ohne workers_dev: false ist ein Worker unter <name>.<account>.workers.dev live, egal welche Routen oder Access-Richtlinien existieren.

Ein vollständiger Deploy-von-Grund-auf-Leitfaden – Geheimnisse, Access-Einrichtung, Bindings, Migrationen und das Backfill – ist noch nicht geschrieben; er kommt mit dem Rest des Systems.

Roadmap

Verfolgt als Issues in diesem Repo:

Ein Spike hat die eine Frage geklärt, von der die gesamte Architektur abhing – kann ein Cloudflare Worker überhaupt IMAP mit iCloud sprechen? Ja: TLS und LOGIN auf Port 993 in 755 ms, Ordner aufgelistet, Nachrichten abgerufen und MIME-dekodiert, ein Entwurf angehängt und markiert. Der Sync-Pfad ist also ein Worker, und nichts wandert in einen Container. Die Erkenntnisse, die das Design einschränken – CONDSTORE-Reihenfolge, kein MOVE bei iCloud, SEARCH für Inhalte unbrauchbar – sind in die Tickets geschrieben, die sie betreffen.

Lizenz

MIT – siehe LICENSE.