Von Google zu Thundermail

Nach Jahren bei Google Workspace habe ich meine E-Mail-Infrastruktur komplett auf Thundermail umgezogen. In diesem Artikel möchte ich kurz erläutern, warum ich gewechselt bin und wie die Migration technisch abgelaufen ist.

Warum der Wechsel?

1. Weg von Google

Ich betreibe seit Jahren Server, IT-Infrastruktur und Monitoring für Kunden – und je tiefer man in dieses Feld eintaucht, desto unangenehmer wird die Abhängigkeit von einem einzelnen US-Großkonzern für die eigene digitale Identität. E-Mail ist der zentrale Knotenpunkt fast aller Online-Konten: Passwort-Resets, 2FA, Rechnungen, Kundenkommunikation. Diesen Knotenpunkt bei Google zu belassen, während man selbst überall sonst versucht, Kontrolle über die eigene Infrastruktur zu behalten, hat sich zunehmend inkonsequent angefühlt.

Dazu kommen die bekannten Kritikpunkte: Datenauswertung für Werbezwecke, intransparente Kontosperrungen ohne Support-Ansprechpartner, und die schiere Marktmacht eines Unternehmens, das E-Mail, Browser, Betriebssystem und Werbenetzwerk gleichzeitig kontrolliert.

2. Open Source und Unabhängigkeit

Thundermail überzeugt mich durch seinen Open-Source-Ansatz. Ich kann nachvollziehen, wie meine Daten verarbeitet werden, bin nicht an die Blackbox eines Konzerns gebunden und profitiere von einer Infrastruktur, die nicht primär auf Monetarisierung meiner Daten ausgelegt ist. Außerdem werden die Daten komplett in Deutschland gehosted und unterliegen dadurch strengen Datenschutzrichtlinien.

3. Praktikabilität

Der Wechsel musste sich auch technisch lohnen: saubere IMAP-/JMAP-Unterstützung, verlässliche Standards, keine proprietären Extras, die einen erneut in ein Ökosystem zwingen. Das war bei Thundermail gegeben.

Die technische Migration

Der Umzug von tausenden E-Mails über Jahre hinweg sollte möglichst verlustfrei, nachvollziehbar und wiederholbar sein. Die Wahl fiel auf das bewährte Tool imapsync, das IMAP-zu-IMAP-Migrationen inkrementell und idempotent durchführt – ein entscheidender Vorteil, denn so lässt sich der Sync beliebig oft laufen lassen, ohne Duplikate zu erzeugen.

Vorbereitung

Auf einem Ubuntu-Server wurde imapsync installiert:

sudo apt update && sudo apt install -y imapsync

Testlauf mit --dry

Vor jeder echten Migration lohnt sich ein Trockenlauf, um Ordnerkonflikte oder Fehler zu erkennen, ohne das Ziel zu verändern:

imapsync \
  --host1 imap.gmail.com \
  --user1 'user@example.org' \
  --passfile1 src.pass \
  --ssl1 \
  --gmail1 \
  --host2 mail.thundermail.com \
  --user2 'user@example.org' \
  --passfile2 dst.pass \
  --ssl2 \
  --automap \
  --skipcrossduplicates \
  --useheader 'Message-Id' \
  --syncinternaldates \
  --folderlast "[Gmail]/Alle Nachrichten" \
  --dry \
  --logfile imapsync-dry.log

Die wichtigsten Optionen im Detail:

• --gmail1 setzt Gmail-spezifische Defaults, um mit den Eigenheiten von Googles IMAP-Implementierung (Labels als Ordner, [Gmail]-Namespace) sauber umzugehen.
• --automap ordnet Ordner zwischen Quelle und Ziel automatisch anhand von Namenskonventionen zu, statt eine exakte 1:1-Übereinstimmung zu erwarten. Gmail-Ordnernamen wie [Gmail]/Gesendet werden so sinnvoll auf das Zielschema von Thundermail gemappt.
• --skipcrossduplicates verhindert, dass eine E-Mail, die durch Gmail-Labels in mehreren Ordnern gleichzeitig liegt, auf dem Ziel mehrfach angelegt wird.
• --useheader 'Message-Id' nutzt die Message-ID als zuverlässiges Kriterium, um bereits übertragene Mails bei wiederholten Läufen zu erkennen – robuster als der Standard-Vergleich über Datum und Größe.
• --syncinternaldates überträgt die ursprünglichen Empfangsdaten, statt die Mails mit dem Datum des Sync-Vorgangs zu versehen.
• --folderlast "[Gmail]/Alle Nachrichten" sorgt dafür, dass der Gmail-Catch-all-Ordner ("Alle Nachrichten") erst ganz zum Schluss synchronisiert wird – so werden Mails, die bereits über gelabelte Ordner übertragen wurden, korrekt dedupliziert, bevor der Catch-all-Ordner läuft.

Zwei Gmail-Ordner wurden bewusst ausgeschlossen: [Gmail]/Wichtig und [Gmail]/Markiert. Beide sind reine Gmail-Labels (\Important und \Flagged) und keine eigenständigen Container – die zugehörigen Mails liegen ohnehin vollständig in "Alle Nachrichten" und werden von dort übertragen. Kein Datenverlust, nur weniger redundante Ordner im neuen Postfach.

Der produktive Lauf

Nach einem sauberen Dry-Run folgte der eigentliche Sync – derselbe Befehl ohne --dry:

imapsync \
  --host1 imap.gmail.com \
  --user1 'user@example.org' \
  --passfile1 src.pass \
  --ssl1 \
  --gmail1 \
  --host2 mail.thundermail.com \
  --user2 'user@example.org' \
  --passfile2 dst.pass \
  --ssl2 \
  --automap \
  --skipcrossduplicates \
  --useheader 'Message-Id' \
  --syncinternaldates \
  --folderlast "[Gmail]/Alle Nachrichten" \
  --logfile imapsync-run-$(date +%Y%m%d).log

Bei knapp 10.000 Mails ein Prozess, der einige Zeit in Anspruch nimmt.

Da imapsync idempotent arbeitet, lässt sich der Befehl mehrfach wiederholen: ein Vorab-Sync Tage im Voraus, ein finaler Sync kurz vor oder nach der eigentlichen DNS-Umstellung – bereits übertragene Mails werden dabei automatisch übersprungen.

Fazit

Der technische Aufwand für die Migration war überschaubar – imapsync macht den eigentlichen Datentransfer einfach. Der größere Wert liegt für mich im Ergebnis: ein zentraler, sicherheitskritischer Dienst läuft jetzt auf einer offenen, nicht-Google-Infrastruktur, ohne dass ich auf saubere IMAP-Unterstützung oder Zuverlässigkeit verzichten musste.