Gmail vers SQLite

 (github.com/marcboeker)
2 points par GN⁺ 2025-05-11 | 1 commentaires | Partager sur WhatsApp
  • Outil en ligne de commande basé sur Python qui convertit les données d’e-mails reçues dans Gmail en base de données SQLite afin de les gérer et de les analyser de manière structurée
  • Développé en open source, il peut être librement étendu et personnalisé aussi bien par des particuliers que par des entreprises
  • Par rapport à une gestion classique des e-mails, il permet des requêtes rapides et des analyses détaillées à partir des mots-clés ou conditions souhaités
  • La migration des données est simple, et l’outil est particulièrement efficace pour la sauvegarde et l’archivage de grands volumes d’e-mails
  • Par rapport aux autres solutions open source similaires, il se distingue par moins de dépendances, une configuration simple et la commodité de fonctions comme l’indexation automatique

À lire aussi

1 commentaires

 
GN⁺ 2025-05-11
Avis Hacker News

  • Ce que je me demande, c’est pourquoi certains en-têtes ont été séparés dans le schéma Par exemple, des champs comme recipients, subject ou sender pourraient tous être placés dans une seule entrée JSON headers, donc je me demande pourquoi les séparer explicitement Si c’est pour des raisons de performance, on pourrait quand même garder headers comme blob JSON et n’extraire que les champs nécessaires en colonnes générées Je trouve que cela donne un modèle vraiment puissant, car via ALTER TABLE, l’utilisateur peut librement ajouter des colonnes générées indexées selon les requêtes dont il a besoin Par exemple, si on a besoin d’une requête sur le statut DKIM, on peut l’ajouter avec ALTER TABLE et créer facilement un index Comme on peut étendre les champs librement selon ses besoins, c’est avantageux pour de nombreux usages

    • En fait, même les colonnes générées ne sont pas nécessaires, SQLite permet de créer directement des index sur des expressions Donc, par exemple, on peut créer un index sur subject directement avec json_extract, puis réutiliser cet index dans les requêtes quand on en a besoin J’ai l’impression que créer uniquement des index de cette façon et les exploiter via des vues est plus utile que de modifier la table principale avec ALTER

    • Ajouter un index juste pour une requête ponctuelle ne me semble pas être une très bonne habitude En général, je préfère n’extraire explicitement que les colonnes dont je sais qu’elles seront utilisées de manière stable et répétée, surtout dans un cas comme les en-têtes d’e-mail où la structure est relativement stable Mettre tous les en-têtes dans un seul JSON peut faciliter les changements de schéma plus tard, mais au final on déplace simplement la complexité de l’écriture vers les requêtes en lecture, et dans certains cas cela autorise même des échecs silencieux

    • J’utilise souvent un schéma similaire avec Postgres Je commence par mettre en colonnes les champs dont je suis certain d’avoir besoin, puis je regroupe les métadonnées supplémentaires dans une colonne JSON Deux mois plus tard, je peux réinjecter depuis le JSON les champs devenus réellement nécessaires, ajuster l’API pour qu’elle reste stable, ou créer des vues selon le besoin Cette approche m’a été très utile pour éviter les douleurs de croissance consistant à tout balancer au départ dans Mongo ou dans le système de fichiers sans trop réfléchir, puis à le regretter plus tard

    • Je vois qu’ils ont défini la colonne dkim en NOT NULL, mais je me demande ce qui se passe si l’e-mail n’a pas du tout d’en-tête Dkim-Signature

  • J’ai récemment essayé d’intégrer Gmail à mon application J’y ai passé énormément de temps, mais j’ai fini par abandonner la prise en charge de Gmail Gmail to SQLite dit que le processus d’identification se termine en 6 étapes, mais en pratique ce n’était pas le cas Une fois les 6 étapes terminées, Google m’a de nouveau signalé que l’application n’était pas publiée, puis après publication il m’a indiqué qu’elle ne pouvait pas être une application interne parce que je n’étais pas un utilisateur Workspace En la passant en application externe, il a ensuite demandé une procédure de validation supplémentaire distincte (domaine, adresse, détails, justification des permissions, vidéo explicative, délai de revue, etc.) Je trouve excessif d’imposer ce genre de processus complexe à des utilisateurs ordinaires J’ai été sidéré par l’expérience

    • Il suffit de faire comme avant et d’utiliser l’IMAP avec un mot de passe d’application Mieux vaut éviter toutes les procédures pénibles imposées par Google

    • Le nombre d’étapes à franchir juste pour obtenir une clé API chez Google est complètement délirant Je me demande si quelqu’un sait pourquoi ils ont rendu ça aussi absurde

  • Il y a quelques années, j’avais créé un outil pour visualiser de très gros volumes d’e-mails comme Gmail : https://github.com/terhechte/postsack

    • C’est vraiment superbe Ça fait penser à un outil de visualisation d’espace disque, mais centré sur le volume de mails lui-même Est-ce qu’il y a aussi une option pour voir quels expéditeurs occupent le plus d’espace de stockage chez moi ? À noter que le certificat SSL du site web a expiré

    • Ça a l’air intéressant Le lien vers gmvault dans le readme ne fonctionne plus ; est-ce que le bon lien est bien https://github.com/gaubert/gmvault ?

    • Ça a l’air vraiment intéressant J’avais déjà bricolé quelque chose de similaire en DIY avec qdirstat, mais dans ce cas il faut trier par structure de dossiers de messagerie ou par date, et c’est difficile de recomposer les données selon différents critères À noter que le fichier de cache de qdirstat est vraiment facile à générer, donc ça peut être très utile pour visualiser des données de type multi-fichiers

  • Je trouve vraiment dommage qu’on ne puisse bientôt plus se connecter simplement avec des mots de passe d’application et qu’il faille passer par l’enregistrement d’un client OAuth et tout un processus compliqué Même si c’est mon propre e-mail, j’ai l’impression que Google me retire des standards ouverts auxquels je pouvais accéder moi-même

    • Avec une adresse Gmail gratuite, je reçois énormément plus de spam qu’avec une adresse payante pour mon activité freelance, et je reçois aussi davantage de spam provenant de serveurs Gmail sur mes comptes non Gmail Surtout depuis que je vois mon e-mail freelance finir régulièrement en spam chez les systèmes de messagerie de mes correspondants, j’ai de plus en plus envie de sortir de l’écosystème Google Mais je ne vois pas bien comment me défaire de toutes mes habitudes liées à Google, et ça me pèse

    • Je ne comprends pas bien Avec un mot de passe d’application, on peut toujours obtenir un accès IMAP complet

    • Je me demande pourquoi les mots de passe d’application seraient considérés comme un standard ouvert alors qu’OAuth, lui, ne le serait pas

  • Vraiment génial Nouvelle demande de fonctionnalité : j’aimerais qu’il puisse extraire les liens de désabonnement du corps des e-mails afin de pouvoir se désabonner facilement des expéditeurs récurrents

  • J’ai essayé exactement la même chose hier, parce que je voulais lister le nombre d’e-mails reçus par domaine La qualité du code est faible, mais le voici : https://github.com/hugoferreira/gmail-sqlite-db

    • J’ai essayé la même chose, en groupant moi aussi par domaine et par expéditeur

  • Je ne savais pas que c’était possible, merci

  • Ça me rappelle un peu Archiveopteryx (serveur IMAP basé sur Postgres) : https://github.com/aox/aox J’ai toujours trouvé le schéma d’AOX très réussi, mais je n’ai encore jamais eu l’occasion de vraiment l’utiliser J’aurais surtout aimé m’en servir pour l’analyse ou la recherche dans les e-mails

  • Je me demande combien cela coûte en bande passante J’ai plus de 40 Go rien que sur Gmail, donc je me demande si l’utilisation de cet outil risque de me valoir une facture à cause du volume transféré Bien sûr, avec Google Takeout (téléchargement gratuit de tous les e-mails), il suffit ensuite de parser les fichiers, donc ce serait facile à résoudre Mais cet outil semble beaucoup plus rapide et plus simple pour démarrer

  • J’ai l’impression que ça devrait plutôt s’appeler « imap to sqlite » Je me demande pourquoi le limiter à un fournisseur d’e-mail particulier

    • Parce que cet outil est spécialisé pour Gmail Il utilise OAuth et l’accès aux API de Google La méthode IMAP est bien plus complexe et plus lente, et elle se heurte aussi aux limitations de bande passante de Google

    • Pour information, j’ai essayé pendant des années de sauvegarder mon compte Gmail via IMAP (même avec des outils spécialisés pour Gmail) sans jamais réussir une seule fois Même les outils de synchronisation qui semblaient fonctionner finissaient par tourner pendant environ un mois avant de se bloquer sur un e-mail précis qu’ils n’arrivaient pas à récupérer C’est peut-être lié à un état de cold storage Du coup, j’ai pensé que l’API spécifique de Google serait probablement meilleure Aujourd’hui, j’apprécie énormément le fait que Google Takeout me permette de récupérer directement un mbox, rapidement, complètement et sans problème (en environ une demi-journée) L’inconvénient, c’est qu’il n’y a pas de mise à jour continue automatique Pour info, j’ai déjà migré vers un autre service de messagerie (Infomaniak), et je suis vraiment content d’avoir eu mon propre domaine indépendant à l’avance