MCP, iPhone, Grenzen

Für ein Modell erreichbar: --mcp

s3mail spricht das Model Context Protocol über stdin/stdout: kein Fenster, kein Webserver, kein Port. Damit kann Claude im Postfach suchen, lesen, einsortieren und einen Entwurf schreiben. Voraussetzung: s3mail muss einmal normal gelaufen und eingerichtet sein; --mcp liest dieselbe config.json und startet keinen Assistenten.

claude mcp add s3mail -- /pfad/zu/s3mail --mcp
claude mcp list          # muss „✔ Connected“ zeigen

Für Claude Desktop in claude_desktop_config.json: {"mcpServers": {"s3mail": {"command": "/pfad/zu/s3mail", "args": ["--mcp"]}}}, danach Claude Desktop neu starten.

Es gibt kein Werkzeug zum Senden, und das ist der Punkt. Eine eingehende Mail ist fremder Text, der im Kontext des Modells landet; „schick das an …“ passt in eine Mail. Das Modell legt einen Entwurf in den Bucket, du öffnest s3mail und drückst Senden. Der Absender bleibt technisch ein Mensch, nicht nur organisatorisch. Aus demselben Grund sind Papierkorb und Spam keine Ziele für move: mit der Lifecycle-Regel wäre ein Verschieben dorthin ein Löschen mit Verzögerung. Wer noch weniger zulassen will, startet mit --mcp-readonly.

Jede gelesene Mail kommt mit dem Hinweis davor, dass der Inhalt Daten sind und keine Anweisungen. Das löst Prompt-Injection nicht, es begrenzt, was daraus folgen kann. Kein API-Schlüssel, keine Netzverbindung zu Dritten: s3mail ruft kein Modell auf, sondern macht sich für eines erreichbar.

Auf dem Telefon

Eine native iOS-App liest denselben Bucket direkt, mit einem eigenen IAM-Benutzer und einer Rechtegrenze, die sie auf das Prefix dieses Postfachs deckelt. Gekoppelt wird so: auf dem Desktop einen Namen eintippen, einen QR-Code scannen, sechs Ziffern bestätigen. Der Schlüssel reist versiegelt im Code, die PIN nicht; deshalb ist ein Foto des Bildschirms kein Zugang. Ein verlorenes Telefon ist eine einzelne Sperrung, keine Rotation überall.

Die App lebt in einem eigenen Repository: github.com/ohartwig/s3mail-ios; die Überlegungen dahinter stehen in IOS.md.

Grenzen

• Kein IMAP. Ein normales Mailprogramm kann das Postfach nicht öffnen. Senden ginge über den SMTP-Endpunkt von SES, lesen nicht, SES kennt keinen Postfachdienst. Warum das schwer ist und wo der Weg durchginge, steht in IMAP.md; gebaut ist davon nichts.
• Keine Thread-Gruppierung. Die Liste zeigt einzelne Mails. Richtiges Threading braucht References, eine Normalisierung der Betreffs und einen Umgang mit Fäden, die ein Ticketsystem abgeschnitten hat. Was den Zweck meistens erfüllt, gibt es: Verlauf in der Mailansicht zeigt alle Mails mit dieser Adresse über alle Ordner.
• Push braucht eine Klingel in AWS: SES benachrichtigt ein SNS-Topic, das in eine SQS-Queue schreibt, an der s3mail hängt. Ohne läuft --refresh im Takt (Standard 60 Sekunden). Die Queue liest s3mail aus der eigenen IAM-Policy.
• Der Zugang hängt an einem Token, nicht an Benutzern.
• Verschieben kopiert das Objekt. Verschlüsselung und Speicherklasse kommen mit, die Versionshistorie eines versionierten Buckets nicht.
• Bei sehr großen Postfächern (über etwa 50.000 Objekte) dauert das erste Indexieren; dann mit engerem Prefix arbeiten.
• Die Windows-Pakete sind nicht signiert, dort meldet sich SmartScreen. Die macOS-Pakete sind signiert und notarisiert. Für alle Plattformen gibt es SHA256SUMS mit cosign-Signatur.

Lizenz und Meldeweg

Apache-2.0, jede Quelldatei trägt den SPDX-Identifier, das Repository ist REUSE-konform. Die Patentklausel in Abschnitt 3 ist der Grund für Apache-2.0 statt MIT: sie gibt jedem Nutzer die Patentrechte an dem, was drin ist, und nimmt sie dem wieder, der darüber klagt. Sicherheitslücken an security@ole-hartwig.eu, nicht als Issue.