E-Mail im eigenen S3-Bucket speichern: was dort landet

Eine Nachricht trifft für Sie ein, und etwa eine Sekunde später liegt ein neues Objekt in einem Bucket in Ihrem eigenen Cloud-Konto. Dieses Objekt ist der interessante Teil von Bring-your-own-Storage-E-Mail: was darin steht, wie es dorthin geschrieben wurde und was Sie damit tun können, was Ihnen kein Mail-Anbieter auf seinen eigenen Platten je erlauben würde.

Was landet tatsächlich in Ihrem Bucket?

Verschlüsselte Blobs — und der Index, der sie zu einem Postfach macht. Jede Nachricht wird mit zstd komprimiert, mit einem Schlüssel pro Postfach über age verschlüsselt (dem Dateiformat auf X25519-Basis) und unter dem Präfix blobs/ mit einem Namen abgelegt, der aus einem Hash ihres Inhalts abgeleitet ist. Identische Bytes bekommen denselben Namen. Am Objektschlüssel ist für einen Leser nichts zu erkennen: nicht der Betreff, nicht der Absender, nicht die Adresse, an die geschrieben wurde.

Den Index vergisst fast jeder, der sich das Ganze vorstellt. Ein Postfach ist kein Haufen Blobs. Irgendetwas muss wissen, welcher Blob welche Nachricht ist, zu welchem Thread sie gehört, was ungelesen ist, was ein Label trägt. Diese Struktur wird in denselben Speicher geschrieben und genauso verschlüsselt. Deshalb ist „meine Mail liegt in meinem Bucket“ eine stärkere Aussage, als sie zunächst klingt: Das Archiv ist nicht bloß abrufbar, es beschreibt sich selbst — für alles, was den Schlüssel hält.

Eine Frage an jeden Anbieter mit diesem Angebot, bevor Sie eine Domain darauf umstellen: Ist das Format im Speicher dokumentiert? Bytes, die nur die Software eines Herstellers lesen kann, sind eine schwächere Form von Eigentum, als sie aussehen.

Wie kommt eine Nachricht vom Absender in Ihren Speicher?

In fünf Schritten, und bei den letzten beiden zählt die Reihenfolge.

Unser MX-Host nimmt die SMTP-Verbindung an und prüft die Nachricht: SPF, DKIM und DMARC der eingehenden Mail, Absenderreputation und Blocklisten, dann die Spam- und Phishing-Analyse. Filtern setzt voraus, Klartext zu lesen, also passiert das alles hier — bevor irgendetwas im Ruhezustand verschlüsselt wird. Ein Dienst, der Ihren Spam filtert, hat Ihre Mail gesehen; wer beides behauptet, beschreibt etwas, das nicht funktionieren kann.

Danach wird die Empfängeradresse einem Postfach zugeordnet, die Nachricht komprimiert und mit dem Schlüssel dieses Postfachs verschlüsselt, und das Objekt wird in Ihren Speicher geschrieben — ein PUT an S3 oder einen S3-kompatiblen Endpunkt, an R2, an einen WebDAV-Server, oder ein Commit in ein Git-Repository.

Erst wenn dieser Schreibvorgang geglückt ist, antwortet der Edge mit 250 OK. Der annehmende Edge ist zustandslos und führt keine eigene Warteschlange. Das klingt nach einer Einschränkung und ist tatsächlich die Zuverlässigkeitsgarantie: Er kann nichts quittieren, was er nicht gespeichert hat. Ist Ihr Speicher ausgefallen, liegt die Nachricht weiter in der Warteschlange des sendenden Servers — dem dauerhaftesten Ort, den es für sie überhaupt gibt.

Was können Sie mit dem Bucket tun, was ein Anbieter nie erlauben würde?

Alles, was die Storage-API hergibt, denn es ist Ihr Bucket und der Mail-Dienst ist nur ein Client mit einem Schlüssel.

Objektversionierung macht aus „irgendetwas hat ein Jahr Mail gelöscht“ eine Wiederherstellung statt eines Vorfalls. Lifecycle-Regeln senken die Rechnung für ein Archiv, das niemand liest. Cross-Region-Replikation oder ein nächtliches rclone sync legt eine zweite Kopie zu einem zweiten Betreiber in ein zweites Land, im selben Rhythmus wie alles andere, was Sie sichern. Object Lock erfüllt eine Aufbewahrungspflicht, von der Ihr Mail-Anbieter nie gehört hat. Bucket-Zugriffsprotokolle halten jeden Lesezugriff fest, unseren eingeschlossen. Serverseitige Verschlüsselung mit Ihrem eigenen KMS-Schlüssel legt eine zweite Schicht um unseren Geheimtext, deren Schlüssel Sie einseitig widerrufen können.

Zwei davon haben scharfe Kanten. Übergänge in kalte Speicherklassen machen den Abruf langsam, richten Sie sie also auf eine Replik und nicht auf die Blobs, die Ihr Webmail aktiv liest. Und Object Lock im Compliance-Modus heißt, dass niemand ein Objekt vor Ablauf seiner Frist löscht — Sie eingeschlossen, auch die Version von Ihnen, die die Aufbewahrungsdauer falsch gesetzt hat. Dieser Modus ist eine Entscheidung, kein Häkchen.

Die andere Freiheit ist die Platzierung. Sie wählen die Region, und davon getrennt wählen Sie, wer sie betreibt. Region ist nicht Jurisdiktion: Eine EU-Region, die ein US-Unternehmen betreibt, bleibt über den seit 2018 geltenden CLOUD Act erreichbar. Für die Dokumentation nach Art. 44 ff. DSGVO ist das der angenehme Teil — der Speicherort wird eine Konfiguration statt einer Zusage. Beides bewusst zu wählen ist der größte Teil des Grundes, aus dem Leute diese Anordnung überhaupt wollen.

Die Kosten verhalten sich anders, als es Preisseiten antrainieren. Mail besteht aus tausenden kleinen Objekten, also dominieren Request-Kosten und Egress, nicht der Gigabyte-Preis. R2 rechnet Egress überhaupt nicht ab.

Was bleibt beim Routing-Dienst?

Die Teile, die zwangsläufig im öffentlichen Internet stehen — und standardmäßig die Schlüssel.

Bei uns bleiben die MX-Einträge, TLS am Edge, DKIM-Signatur und DMARC-Ausrichtung für Ihre ausgehende Mail, die Arbeit an der IP-Reputation, die Spam- und Phishing-Analyse und der Webmail-Client. Ihre Bucket-Zugangsdaten liegen versiegelt in unserer Datenbank, weil die Zustellung sie braucht.

Die Schlüsselverwahrung ist das ehrliche Sternchen. In der Standardstufe mit Serververwahrung halten wir die Schlüssel pro Postfach — nur so lässt sich ein Postfach im Browser darstellen und durchsuchen. Ihr Speicheranbieter sieht ausschließlich Geheimtext, wir können entschlüsseln. Die Gerätestufe, derzeit in der Beta, erzeugt die Schlüssel in Ihrem Browser und löscht unsere Kopie; danach kann der Dienst in Ihren Speicher schreiben und nicht lesen, was er geschrieben hat. Beides sind vertretbare Bauformen. Nur eine davon heißt „niemand außer mir“, und diesen Unterschied sollten Sie kennen, bevor Sie ihn in ein Datenschutzdokument schreiben.

Wie geht das schief?

Auf drei Wege, in der Reihenfolge, in der sie wirklich vorkommen.

Zugangsdaten. Sie rotieren an einem Dienstag einen Access Key und vergessen, dass der Mail-Pfad ein Konsument dieses Buckets ist. Die Zustellung schlägt fehl, und weil der Edge das 250 OK zurückhält, ist zunächst nichts verloren: Sie bekommen eine Verzögerung und Warnmeldungen, kein Loch im Archiv. Rotieren Sie so, wie Sie es für jeden anderen Client tun würden — neuen Schlüssel zuerst im Postfach eintragen, alten danach widerrufen.

Policies. Eine Bucket-Policy, die sich als öffentlich entpuppt, gibt Geheimtext frei und keine Nachrichten; das ist der Unterschied zwischen einer Peinlichkeit und einer Katastrophe. Objektzahl, Größen und Zeitstempel bleiben trotzdem ein Datensatz für Verkehrsanalyse, und ein Postfach, das Sie absichtlich auf Klartext im Ruhezustand gestellt haben, gibt genau das preis, was Sie erwarten. Eine Lifecycle-Regel mit Expiration-Action löscht Mail nach Plan und fragt nicht zweimal. Eine KMS-Key-Policy, die den Schreibenden auslässt, stoppt die Zustellung sofort.

Sie selbst. Mit der Verfügungsgewalt wandert die Verantwortung mit. Den Bucket zu löschen löscht die Mail, und es gibt kein Support-Ticket, das ein Backup wiederherstellt, das wir nie hatten. Das ist keine Lücke im Produkt. Das ist genau das, was Sie gekauft haben.

Der Test, den ich an jeden Anbieter dieses Modells anlegen würde: Können Sie seine Speicher-Zugangsdaten in zehn Sekunden widerrufen, und ist Ihr Archiv danach noch lesbar? Wenn ja, besitzen Sie Ihre Mail. Enthält die Antwort ein Export-Werkzeug, besitzen Sie ein Konto.