Gmail zu SQLite

 (github.com/marcboeker)
2 Punkte von GN⁺ 2025-05-11 | 1 Kommentare | Auf WhatsApp teilen
  • Ein Python-basiertes Kommandozeilen-Tool, das E-Mail-Daten aus Gmail in eine SQLite-Datenbank umwandelt, um sie systematisch zu verwalten und zu analysieren
  • Wird als Open Source entwickelt und kann daher von Einzelpersonen wie auch Unternehmen frei erweitert und angepasst werden
  • Im Vergleich zur herkömmlichen E-Mail-Verwaltung sind schnelle Abfragen und detaillierte Analysen anhand gewünschter Suchbegriffe oder Bedingungen möglich
  • Erleichtert die Datenmigration und eignet sich hervorragend für effiziente Backups und die Archivierung großer E-Mail-Mengen
  • Bietet im Vergleich zu ähnlichen Open-Source-Projekten hohen Einrichtungskomfort durch wenige Abhängigkeiten, einfache Konfiguration und automatische Indizierung

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-05-11
Hacker-News-Kommentare

  • Ich frage mich, warum bestimmte Header im Schema separat herausgezogen wurden. Felder wie recipients, subject und sender könnte man doch auch komplett in einem einzigen JSON-Eintrag namens headers unterbringen, daher wüsste ich gern, warum man sie unbedingt trennen sollte. Falls es um Performance geht, könnte man headers immer noch als JSON-Blob behalten und nur die benötigten Felder als generierte Spalten herausziehen. Ich finde, das wäre ein wirklich mächtiges Modell, weil Nutzer dann per ALTER TABLE frei indexierte generierte Spalten für die jeweils benötigten Abfragen hinzufügen könnten. Wenn man zum Beispiel eine Abfrage zum DKIM-Status braucht, könnte man sie per ALTER TABLE ergänzen und auch leicht einen Index darauf anlegen. Weil sich Felder nach Belieben erweitern lassen, ist das für viele Einsatzzwecke vorteilhaft.

    • Eigentlich braucht man nicht einmal generierte Spalten, SQLite kann Indizes direkt auf Ausdrücken anlegen. Man könnte also zum Beispiel einen Index auf subject direkt mit json_extract erstellen und diesen Index dann bei Bedarf in Abfragen verwenden. Ich habe das Gefühl, dass es nützlicher ist, auf diese Weise nur Indizes anzulegen und mit Views zu arbeiten, als die Haupttabelle per ALTER zu verändern.

    • Nur für einmalige Abfragen einen Index hinzuzufügen, scheint keine besonders gute Gewohnheit zu sein. Normalerweise bevorzuge ich es, nur die Spalten separat herauszuziehen, die man künftig sicher und konsistent verwenden wird, besonders bei stabil strukturierten Dingen wie E-Mail-Headern. Alle Header in ein einziges JSON zu packen macht spätere Schemaänderungen zwar einfacher, aber letztlich verlagert man damit die Mühe beim Schreiben nur wieder in die Leseabfragen, und in manchen Fällen erlaubt man sogar stillschweigende Fehler.

    • Ich verwende in Postgres oft ein ähnliches Muster. Zuerst ziehe ich nur die Felder, die definitiv gebraucht werden, als eigene Spalten heraus und packe zusätzliche Metadaten in eine JSON-Spalte. Nach zwei Monaten befüllt man dann die wirklich nötigen Felder wieder aus dem JSON, passt Dinge so an, dass die API erhalten bleibt, oder baut Views – ganz wie es gerade sinnvoll ist. Das hat sich als sehr nützlich erwiesen, um die Wachstumsschmerzen zu vermeiden, die entstehen, wenn man anfangs alles gedankenlos in Mongo oder ein Dateisystem kippt und es später bereut.

    • Die dkim-Spalte wurde als NOT NULL definiert; ich frage mich, was passiert, wenn eine E-Mail gar keinen Dkim-Signature-Header hat.

  • Ich habe kürzlich versucht, in meiner App eine Gmail-Integration umzusetzen. Ich habe sehr viel Zeit darauf verwendet, am Ende aber den Gmail-Support aufgegeben. Es hieß, bei Gmail to SQLite sei der Anmeldeinformationsprozess nach 6 Schritten erledigt, in der Praxis war das aber nicht so. Nach diesen 6 Schritten meldete Google erneut, dass die App nicht veröffentlicht sei; nach der Veröffentlichung kam dann die nächste Meldung, dass sie als interne App nicht möglich sei, weil ich kein Workspace-Nutzer bin. Wenn man sie auf eine externe App umstellt, kommen noch weitere Verifizierungsprozesse hinzu – Domain, Adresse, Detailangaben, Begründung für die Berechtigungen, Video-Erklärung, Zeit für die Prüfung und so weiter. Ich finde es völlig überzogen, normalen Nutzern einen derart komplexen Prozess zuzumuten. Die eigene Erfahrung damit hat mich ziemlich schockiert.

    • Man kann einfach wie früher IMAP mit einem App-Passwort verwenden. So vermeidet man das umständliche Verfahren, das Google verlangt.

    • Die Schritte, die man durchlaufen muss, nur um von Google einen API-Schlüssel zu bekommen, sind wirklich absurd umständlich. Ich frage mich ernsthaft, ob jemand weiß, warum sie das so gebaut haben.

  • Ich habe vor ein paar Jahren ein Tool gebaut, um große E-Mail-Bestände wie Gmail zu visualisieren: https://github.com/terhechte/postsack

    • Das ist wirklich cool. Es erinnert an ein Visualisierungstool für Festplattenspeicher, scheint hier aber speziell auf das Mail-Volumen fokussiert zu sein. Gibt es vielleicht auch eine Größenanzeige, mit der man sehen kann, welche Absender am meisten Speicherplatz belegen? Übrigens ist das SSL-Zertifikat der Website abgelaufen.

    • Sieht interessant aus. Der gmvault-Link in der README funktioniert offenbar nicht mehr; ist das hier der richtige Link: https://github.com/gaubert/gmvault ?

    • Sieht wirklich interessant aus. Ich habe einmal versucht, etwas Ähnliches als DIY-Lösung mit qdirstat zu bauen, aber dort muss man nach E-Mail-Ordnerstruktur oder Datum sortieren, und es ist schwer, die Daten nach verschiedenen Kriterien neu zu kombinieren. Nebenbei: Die Cache-Datei von qdirstat lässt sich wirklich leicht erzeugen, daher ist sie nützlich, wenn man Daten aus verschiedenen Dateien visualisieren will.

  • Ich finde es wirklich schade, dass man sich inzwischen nicht einmal mehr nur mit einem App-Passwort anmelden kann, sondern durch komplizierte Prozesse wie die Registrierung eines OAuth-Clients gehen muss. Obwohl es meine E-Mail ist, fühlt es sich an, als würde Google mir offene Standards wegnehmen, mit denen ich selbst darauf zugreifen könnte.

    • Die Menge an Spam, die ich auf eine kostenlose Gmail-Adresse bekomme, ist überwältigend größer als auf eine kostenpflichtige Adresse für Freiberufler, und auch Spam von Gmail-Servern landet häufiger in meinen Nicht-Gmail-Konten. Vor allem weil meine Freelancer-Mailadresse von den Mail-Systemen anderer oft als Spam eingestuft wird, wächst in mir immer mehr der Wunsch, das Google-Ökosystem zu verlassen. Ich weiß allerdings nicht, wie ich mich aus meinen Google-abhängigen Routinen lösen soll, und das belastet mich.

    • Ich verstehe das nicht ganz. Mit einem App-Passwort kann man doch vollständigen IMAP-Zugriff bekommen.

    • Ich frage mich, warum App-Passwörter als offener Standard gelten sollen, OAuth aber nicht.

  • Wirklich cool. Neuer Feature-Wunsch: eine Funktion, die Abmeldelinks aus E-Mail-Texten extrahiert, damit man Newsletter von häufigen Absendern leicht abbestellen kann.

  • Ich habe gestern genau dasselbe ausprobiert, weil ich auflisten wollte, wie viele E-Mails ich pro Domain bekomme. Die Codequalität ist nicht besonders gut, aber hier ist es: https://github.com/hugoferreira/gmail-sqlite-db

    • Ich habe ebenfalls versucht, nach Domains und Absendern zu gruppieren.

  • Ich wusste nicht, dass das möglich ist, danke.

  • Das erinnert mich ein wenig an Archiveopteryx, einen IMAP-Server auf Postgres-Basis: https://github.com/aox/aox Das Schema von AOX hat mir immer sehr gut gefallen, aber ich hatte noch nie die Gelegenheit, es wirklich zu verwenden. Ich wollte es hauptsächlich für E-Mail-Analyse oder Suche einsetzen.

  • Ich frage mich, wie hoch hier die Bandbreitenkosten sind. Allein mein Gmail-Speicher liegt bei über 40 GB, und ich frage mich, ob ich bei Nutzung dieses Tools wegen des Datenverkehrs eine Rechnung bekomme. Natürlich wäre das mit Google Takeout leicht zu lösen, weil man dort die kompletten E-Mails kostenlos herunterladen und dann nur die Dateien parsen muss. Trotzdem scheint man mit diesem Tool viel schneller und einfacher loslegen zu können.

  • Sollte das nicht eher so etwas wie „imap to sqlite“ heißen? Ich frage mich, warum es auf einen bestimmten E-Mail-Anbieter beschränkt ist.

    • Der Grund ist, dass dieses Tool speziell auf Gmail zugeschnitten ist. Es nutzt OAuth und den API-Zugriff von Google. IMAP ist deutlich komplexer und langsamer und stößt außerdem an Googles Bandbreitenlimits.

    • Zur Einordnung: Ich habe über Jahre hinweg versucht, mein Gmail-Konto per IMAP zu sichern – sogar mit speziell auf Gmail zugeschnittenen Tools – und es nie erfolgreich geschafft. Selbst Synchronisationstools, die zunächst gut funktionierten, liefen nach etwa einem Monat irgendwann fest, weil sie eine bestimmte Mail nicht abrufen konnten. Vielleicht lag es daran, dass sie sich im Cold Storage befand. Deshalb dachte ich, dass die proprietäre Google-API vielleicht besser wäre. Inzwischen bin ich sehr froh, dass man bei Google Takeout direkt eine mbox bekommen und damit schnell und vollständig ohne Probleme ein Backup erstellen kann; das dauert etwa einen halben Tag. Der Nachteil ist, dass es keine kontinuierlichen automatischen Updates gibt. Zur Einordnung: Ich bin bereits zu einem anderen Maildienst, Infomaniak, gewechselt, und ich bin wirklich froh, dass ich schon vorher eine eigene unabhängige Domain hatte.