Die RocMail-Verfassung

Das Postfach gehört dem Nutzer, nicht uns

1. I.1Postinhalte sollen allein für ihren Eigentümer lesbar sein. Der Dienst soll niemals einen Schlüssel besitzen, erzeugen oder annehmen, der gespeicherte Post öffnen kann. Wir können die Post, die wir speichern, nicht lesen — nicht „tun es nicht“, sondern können nicht. Texte, Betreffzeilen, Absender, Empfänger, Vorschauen, die Bytes der Anhänge und ihre Dateinamen, Entwürfe, Kontakte und der Suchindex sind für eine Tresor-Identität versiegelt, deren geheime Hälfte nur in deinem entsperrten Browser existiert.
2. I.2Der Eingangs-Worker hält nur einen öffentlichen Schlüssel: Er kann Post an dich versiegeln und sie nie öffnen.
3. I.3Der frühere Post-Schlüssel des Servers wurde am 7. August 2026 vernichtet, nachdem jede gespeicherte Nachricht neu versiegelt war. Alte Datenbank-Snapshots sind unlesbar, weil der Schlüssel, der sie öffnete, nirgends mehr existiert. Er wird nie neu erzeugt.
4. I.4Kann nicht versiegelt werden, wird die Zustellung abgewiesen, damit der sendende Server es erneut versucht. Wir speichern nie stillschweigend eine lesbare Kopie von Post, die du für verschlüsselt hältst.

Durchgesetzt durchVersiegelung beim Eingang (Mashrabiya: ML-KEM-768 + X25519), ein Zustellweg, der abweist, statt auf Klartext auszuweichen, ein Test, der die rohen Datenbankdateien nach Klartext durchsucht, und kein verbliebener Weg über einen Serverschlüssel, der Post öffnen könnte.

Keine Werbung, kein Tracking, keine Datenwirtschaft

1. II.1Keine Werbung, niemals. Werbung wird mit Aufmerksamkeit finanziert und mit Profilbildung bezahlt; ein Mailprodukt, das Werbung zeigt, liest etwas, um sie gezielt auszuspielen.
2. II.2Keine Analyse, keine Tracker, kein Fingerprinting — in der App oder auf den öffentlichen Seiten. Kein Skript, keine Schrift, kein CDN und kein Zählpixel eines Dritten darf von einer Seite geladen werden, die wir ausliefern.
3. II.3Keine Cookies für anonyme Besucher. Angemeldete Nutzer erhalten genau zwei: ein Sitzungscookie und seinen CSRF-Zwilling.
4. II.4Wir verkaufen, teilen oder vermieten Nutzerdaten nicht, und wir „anonymisieren und aggregieren“ sie nicht. Es gibt keinen Absatz über eine Rechtsgrundlage, der das später akzeptabel macht.
5. II.5Die Tracking-Pixel eingehender Post sind standardmässig entschärft — externe Inhalte laden nur, wenn der Leser es verlangt, pro Nachricht.

Durchgesetzt durchEine Content-Security-Policy ohne Ursprünge Dritter (das Analyse-Beacon wurde in v27 entfernt), selbst gehostete Schriften ohne Preconnects, das Entfernen von Trackern beim Eingang und Tests, die die ausgelieferten Seiten nach Ressourcen anderer Hosts durchsuchen.

Macht über Konten, nie über Korrespondenz

1. III.1Einen Betreiber gibt es, und ab einer gewissen Grösse ist er nötig. Seine Macht ist die Kontoverwaltung: einladen, sperren, entsperren, löschen, und die Einstellungen der Instanz. Nie lesen.
2. III.2Das ist strukturell, nicht prozedural: Die Befehle des Betreibers treffen auf denselben Chiffretext wie die eines Fremden. Es gibt keinen privilegierten Lesepfad, den man missbrauchen, zu schützen vergessen oder zu benutzen gezwungen werden könnte.
3. III.3Auch der Eigentümer kann keine Post lesen. Keine Rolle in diesem System, auch nicht die, der der Server gehört, kann das Postfach eines Nutzers öffnen.
4. III.4Kein Konto hält die Macht des Betreibers. Ausgeübt wird sie nur an der Konsole des Servers selbst, von dem, der auf der Maschine Root ist — und der all das ohnehin könnte. Die Web-App hat keine Verwaltungsseite und keine Admin-Route: Keine Sitzung, kein Cookie und kein Passwort, auch nicht die des Eigentümers, kann ein Konto sperren, einen Gutschein ausgeben, die Registrierung öffnen oder auf einer geteilten Domain eine Adresse wählen. Ein abgefischtes Passwort, eine gestohlene Sitzung oder eine Lücke im Web-Client erreicht ein Postfach und nichts weiter. Das Konto des Eigentümers ist ein Postfach wie jedes andere.
5. III.5Jede Handlung des Betreibers wird im Audit-Protokoll als die der Konsole festgehalten, ohne Konto und ohne Adresse.

Durchgesetzt durchJede Macht des Betreibers in einem Modul, das nur die Konsole des Servers einbindet; gar keine Verwaltungsroute (ein Test schlägt fehl, sobald eine auftaucht oder Web-Code eine Schreibhandlung des Betreibers aufruft); Sperrungen, die dort durchgesetzt werden, wo Sitzungen aufgelöst werden; und eine Probe auf einem echten Server, die die Konsole von Anfang bis Ende bedient und prüft, dass die alten Admin-Routen auch dem Eigentümer mit 404 antworten.

Ehrlichkeit über Grenzen

1. IV.1Wir veröffentlichen, wogegen wir uns nicht verteidigen: ein entsperrtes Gerät, eingeschleuste Skripte bei offenem Tresor, Verkehrsanalyse, ein bösartiges Client-Update, das wir selbst ausliefern, und eine beschlagnahmte Maschine.
2. IV.2Wir nennen die Metadaten, die der Server behält — Zeitstempel, Ordner- und Gelesen-Markierungen, Anzahl der Anhänge, die Weiterleitungsadressen von Namen, Regelbedingungen, Message-IDs — auf der öffentlichen Website, nicht in einer Fussnote.
3. IV.3Wo Dokumente und Code sich widersprechen, gilt der Code, und das Dokument ist der Fehler. Wir korrigieren das Dokument.
4. IV.4Wir beanspruchen keine Eigenschaft, die wir nicht nachweisen können. Werbesprache, die dem Mechanismus vorauseilt, ist ein Fehler und meldbar wie jeder andere.

Durchgesetzt durchEin veröffentlichtes Bedrohungsmodell, dieselben Grenzen auf der Sicherheitsseite und die Metadatentabelle, abgedruckt auf der Startseite selbst.

Klarheit ist Teil des Produkts

1. V.1Text, den du empfängst, muss lesbar sein: niemals rohe Kodierung, niemals verstümmelte Reste unserer eigenen Verarbeitung. Jede Oberfläche — Listenvorschau, Leseansicht, Zitat, Export, Suchzeile — zeigt dieselbe reparierte Wahrheit.
2. V.2Systemurteile müssen in Sätzen erklärt werden, nicht in Protokollkürzeln. Ein Signal, das du nicht deuten kannst, ist Dekoration.
3. V.3Reparaturen müssen zurückhaltend sein: Ehrlicher Text geht byte-identisch hindurch. Lieber zeigen wir eine Nachricht unvollkommen, als tausend zu beschädigen.
4. V.4Fehlermeldungen sagen, was geschehen ist und was es bedeutet. Schweigen ist kein Zustand einer Oberfläche.

Durchgesetzt durchReparatur auf jedem Lesepfad, eine Erklärung in klarer Sprache für jedes SPF-, DKIM- und DMARC-Ergebnis und Tests, die belegen, dass ehrlicher Text unverändert durchgeht und dass Listenzeile, Leseansicht und Urteilssätze übereinstimmen.

Keine Hintertür, und der Preis, den wir dafür zahlen

1. VI.1Keine Hinterlegung zur Wiederherstellung, kein Eingriff des Betreibers und keine Abhörfähigkeit soll gebaut, gekauft oder angenommen werden — nicht aus Bequemlichkeit, nicht für Wachstum, nicht unter Druck. Es gibt keine Passwort-Wiederherstellung für den Tresor und keinen Weg über „wende dich an den Support“, an dessen Ende jemand anderes deinen Schlüssel hält.
2. VI.2Der ehrliche Preis soll überall genannt werden, wo er gilt — bei der Registrierung, beim Anlegen des Tresors, auf der Sicherheitsseite, in den Nutzungsbedingungen: Wer sowohl die Tresor-Passphrase als auch die Wiederherstellungsphrase verliert, hat seine Post verloren, mathematisch, und keine Support-Anfrage ändert Mathematik.
3. VI.3Ein Dienst, der Wiederherstellung und Privatsphäre zugleich anbietet, beschreibt einen Schlüssel, den er aufbewahrt. Dazu werden wir nicht aus Bequemlichkeit.
4. VI.4Die Kontolöschung vernichtet die Umhüllungen des Tresors, wodurch die Post des Nutzers in der laufenden Datenbank und in jeder danach daraus gezogenen Kopie dauerhaft unlesbar wird — stärker als das Löschen von Zeilen und gewollt unumkehrbar. Ein Backup von vor der Löschung hält die alten Umhüllungen noch, bis es ausläuft, und die alte Passphrase oder Wiederherstellungsphrase würde es öffnen; [die Datenschutzerklärung](/de/privacy#backups) nennt, wie lange Backups aufbewahrt werden. Ist das letzte davon fort, ist es auch der letzte Schlüssel.

Durchgesetzt durchEin Zurücksetzungsweg, der vernichtet statt zurückzusetzen und das in genau diesen Worten sagt („DELETE MY MAIL PERMANENTLY“), die Tresor-Schranke und eine Kontolöschung, die die Umhüllungen entfernt statt der Zeilen.

Die Ausgangstür bleibt offen

1. VII.1Gehen muss immer möglich sein. Der vollständige Export des Postfachs in Standard-mbox und ein versiegeltes Archiv (Chiffretext) gehören zum Produkt — nicht auf eine Roadmap, nicht hinter den Support. Die Passwörter, die neben der Post liegen, gehen auf dieselbe Weise: als verschlüsselte Sicherungsdatei, die nur die dafür gewählte Passphrase öffnet, oder als unverschlüsselte Datei im Bitwarden-Format, die andere Passwortmanager importieren.
2. VII.2Lock-in, gebaut auf den Kosten des Gehens, ist ein Geschäftsmodell, das wir ablehnen.
3. VII.3Die Nahtstellen fürs Selbsthosten — anbieterneutraler Eingang, SMTP für den Ausgang, das Datenbankschema für beide Engines — werden gepflegt und getestet, sodass diese Instanz vollständig zurückgelassen werden kann, auch von uns.
4. VII.4Die Löschung vernichtet die Schlüssel, nicht bloss die Zeilen. Das Löschen eines Kontos vernichtet zuerst jede Umhüllung des Schlüssels dieses Postfachs; das macht die Post sofort unwiederbringlich, in dieser Datenbank und im Objektspeicher — und in jeder Seite, jedem Write-Ahead-Log und jedem Replikat, die danach daraus kopiert werden und die das Löschen von Zeilen allein nie erreichen könnte. Backups von vor der Löschung behalten die alten Umhüllungen, bis sie auslaufen (VI.4). Es gibt keine Hinterlegung, keinen Eingriff des Betreibers, keinen Weg über den Support, der das rückgängig macht: Sind diese Backups ausgelaufen, existiert der Chiffretext nirgends mehr zusammen mit einem Schlüssel.
5. VII.5Nichts behält den Namen von jemandem, der gegangen ist. Die Löschkaskade entfernt die Zeilen des Kontos aus jeder Tabelle, die sie enthält, und ein Test durchsucht das gesamte Schema — jede Tabelle, jede Spalte — nach der ID des Gegangenen, sodass eine künftig hinzugefügte Tabelle nicht still eine Person behalten kann, die um ihre Löschung gebeten hat.

Durchgesetzt durchBeide Exportformate des Postfachs und beide Passwort-Exporte heute im Produkt; ein getesteter, anbieterneutraler Postweg, damit der ganze Dienst den Host wechseln kann; der schlüsselvernichtende Löschweg mit einem schemaweiten Prüftest, der scheitert, wenn irgendeine Tabelle noch ein gelöschtes Konto enthält.

Für wen wir bauen

1. VIII.1Dieser Dienst ist so gebaut, dass er für Journalisten, ihre Quellen, Aktivisten und alle verteidigbar ist, deren Korrespondenz gegen sie verwendet werden kann. Wenn eine Designentscheidung Bequemlichkeit gegen die Sicherheit dieses Menschen abwägt, gewinnt die Sicherheit.
2. VIII.2Das Hosting wird so gewählt, dass der Host selbst als Gegner behandelt wird, was die Metadaten angeht — nicht nur beim Inhalt. Ein Server unter unserer Kontrolle in einem Rechtsraum, der die Privatsphäre schützt, mit einem Tor-Onion-Dienst, damit der Netzwerkstandort der Leser niemandem zum Protokollieren gehört.
3. VIII.3Wir fügen keine Funktion hinzu, deren Wert davon abhängt, Nutzer zu beobachten.

Durchgesetzt durchDas Runbook für souveränes Hosting (die Zielarchitektur und der Onion-Dienst — privat gehalten, bis die Migration abgeschlossen ist) und ein Onion-Ursprung, unterstützt als vollwertiges Bereitstellungsziel.

Geld, und was es nicht kaufen darf

1. IX.1Der Dienst wird von Menschen finanziert, die für ihn bezahlen. Nicht von Werbekunden, nicht von Datenhändlern, nicht von „Partnern“ mit einem Interesse am Posteingang.
2. IX.2Kein Investor, Käufer oder Partner darf eine Fähigkeit erlangen, die diese Verfassung verweigert. Ein Eigentümerwechsel ändert Artikel I nicht — und könnte es nicht ohne die vernichteten Schlüssel, die es nicht mehr gibt.
3. IX.3Es gibt keine gesponserte Fläche: keinen Feed, kein Board, keine Platzierung, auf keiner Seite. Nichts erscheint irgendwo, weil jemand bezahlt hat, und das Schema hat keine Tabelle, in der eine Zahlung eine Zeile kaufen könnte. (Eine kuratierte Nachrichten- und Marktfunktion gab es einmal; sie wurde mit Schema v31 vollständig entfernt. Diese Klausel hat sie überdauert.)
4. IX.4Die Bezahlung darf das Postfach nicht identifizieren. Geld kauft einen Gutschein; ein Gutschein speist ein beliebiges Konto; der Schlüssel, der beide verbindet, wird nie gespeichert. Die Gutscheintabelle hat keine Nutzerspalte, die man vorladen könnte, und die Einlösung verlängert ein Konto in einer getrennten Anweisung, die nie erfährt, welcher Code bezahlt hat. Zahlungswege werden nach Privatsphäre geordnet angeboten — Bargeld per Post, Monero, Bitcoin —, und ein künftiger Kartenweg muss Gutscheine über eine gehostete Seite kaufen, nie Abonnements an einem Konto.
5. IX.5Nichtzahlung friert ein; sie löscht nie, und sie sperrt nie den Empfang. Ein abgelaufenes Konto empfängt, liest und exportiert für immer weiter. Die Löschung ist allein die Handlung des Nutzers — sofort, mit Warnung und unumkehrbar.

Durchgesetzt durchEine Abrechnung, die zum Empfangen, Lesen oder Exportieren nie den Zahlungsstatus befragt (nur Senden und das Anlegen von Namen tun es), eine Einlösung, die keinen Gutschein vermerkt, eine Gutscheintabelle ohne Verbindung zu einem Konto und die Zahlungswege samt der Kartenregel, veröffentlicht auf der Preisseite.

Missbrauchsabwehr, die nicht zur Überwachung wird

1. X.1Wir verteidigen den Dienst gegen Spam, Brute Force und Missbrauch mit den dünnsten Signalen, die funktionieren: Ratenbegrenzungen, Sendeobergrenzen für junge Konten, Authentifizierungsergebnisse und eine Inhaltsbewertung, die bei der Ankunft im Arbeitsspeicher geschieht und nur ihr Urteil behält.
2. X.2Missbrauchsabwehr wird nie zum Grund, Post zu lesen, Nutzerprofile zu bilden oder mehr aufzubewahren, als der Mechanismus braucht.
3. X.3Die Registrierung wird geschützt, nicht überwacht — geschlossen, nur auf Einladung oder offen, nach Entscheidung des Eigentümers, mit Einladungscodes, die gehasht gespeichert werden, sodass ein Datenbankleck keinen einzigen gültigen Code hergibt.

Durchgesetzt durchRatenbegrenzungen pro Identität, eine Sendeobergrenze für junge Konten, gehashte Einladungen zur einmaligen Einlösung, die keine Privilegien verleihen, und Spam-Urteile, gespeichert ohne ihre Beweismittel.

Harte Grenzen

1. XI.1Keine Hintertür, keine Schlüsselhinterlegung und keine Fähigkeit für „rechtmässigen Zugriff“ wird hinzugefügt. Wo ein gültiges rechtliches Verfahren uns zwingt, geben wir heraus, was wir haben — die E-Mail-Adresse des Kontos, Routing-Metadaten, Chiffretext — und sagen ehrlich, dass der Inhalt nicht unser ist, um ihn herauszugeben.
2. XI.2Kein Durchsuchen von Inhalten für Werbung, Modelltraining oder Profilbildung. Niemals.
3. XI.3Keine Dark Patterns: keine Engagement-Mechaniken, keine künstliche Dringlichkeit, keine Oberflächen, die Gehen, Löschen oder Ablehnen schwerer machen sollen als Zustimmen.
4. XI.4Keine stille Erweiterung von Fähigkeiten. Neue Befugnisse über Nutzerdaten erfordern eine öffentliche Änderung dieses Dokuments, mit Begründung, bevor der Code ausgeliefert wird.

Durchgesetzt durchDiese Grenzen sind absolut und werden gegen nichts abgewogen. Kein Mechanismus kann ersetzen, dass man sie einhält.

Rechenschaft

1. XII.1Dieses Dokument lebt im Repository beim Code, versioniert in einer öffentlichen Historie. Änderungen sind Commits: datiert, zurechenbar, überprüfbar.
2. XII.2Fehler werden veröffentlicht, nicht begraben. Wenn wir hier ein Versprechen brechen — wie mit dem Fehler im Eingang, der im August 2026 Nachrichtentexte unlesbar speicherte —, werden die Korrektur, die Ursache und der Test, der eine Wiederholung verhindert, in der Commit-Historie und im Statusbuch festgehalten.
3. XII.3Sicherheitsmeldungen erreichen eine überwachte Adresse und werden beantwortet.
4. XII.4Wird dieser Dienst je eingestellt, erfahren Nutzer es mindestens 90 Tage im Voraus und erhalten ihre Exporte.

Durchgesetzt durchEine Testsuite, die diese Verfassung liest, jeden genannten Mechanismus herauszieht und den Build scheitern lässt, wenn einer aus der Codebasis entfernt wird; und das laufende Verzeichnis dessen, was ausgeliefert wurde, Fehlschläge eingeschlossen.