De Gmail a SQLite

• Herramienta de línea de comandos basada en Python que convierte los datos de correos electrónicos recibidos en Gmail a una base de datos SQLite para gestionarlos y analizarlos de forma sistemática
• Desarrollada como software de código abierto, permite que tanto personas como empresas la amplíen y personalicen libremente
• En comparación con la gestión de correo tradicional, permite consultas rápidas y análisis detallados con los términos de búsqueda o condiciones que se deseen
• Facilita la migración de datos y destaca por su eficiencia para el respaldo y archivado de grandes volúmenes de correos
• Frente a otros proyectos de código abierto similares, ofrece gran facilidad de configuración gracias a sus pocas dependencias, una configuración sencilla y el indexado automático

[GN⁺]

Comentarios de Hacker News

• Lo que me da curiosidad es por qué separaron ciertos headers en el esquema. Por ejemplo, campos como recipients, subject y sender también podrían ir todos dentro de un solo campo JSON llamado headers, así que me pregunto por qué decidieron separarlos. Si es por rendimiento, igual se podría dejar headers como un blob JSON y extraer solo los campos necesarios como columnas generadas. Me parece un modelo muy potente porque así el usuario podría agregar libremente columnas generadas indexadas según las consultas que necesite mediante ALTER TABLE. Por ejemplo, si hiciera falta consultar el estado de DKIM, se podría agregar con ALTER TABLE y crear el índice fácilmente. Como los campos se pueden extender libremente según se quiera, sirve muy bien para distintos usos.

  • En realidad ni siquiera hacen falta columnas generadas; SQLite puede crear índices directamente sobre expresiones. Entonces, por ejemplo, bastaría con crear un índice sobre subject usando json_extract, y luego aprovechar ese índice en las consultas cuando haga falta. Siento que crear índices por separado de esta forma y usarlos mediante vistas es más útil que modificar la tabla principal con ALTER.

  • Agregar índices solo para consultas puntuales no me parece una práctica tan buena. Normalmente prefiero extraer por separado solo las columnas que sé con certeza que se van a usar de forma consistente en adelante, especialmente cuando la estructura es estable, como en los headers de correo. Meter todos los headers en un solo JSON puede hacer más fácil cambiar el esquema después, pero al final solo trasladas a las consultas de lectura el trabajo que evitaste en la escritura, y en algunos casos hasta permites fallos silenciosos.

  • Yo también uso seguido un patrón parecido en Postgres. Primero saco a columnas solo los campos que sé que hacen falta, y dejo la metadata adicional en una columna JSON. Después de un par de meses, vuelvo a evaluar qué campos realmente hacen falta, los relleno desde el JSON, ajusto la API para que se mantenga estable o creo una vista, según convenga. Esto me ha servido muchísimo para evitar esos dolores de crecimiento de meter todo sin pensar al principio en Mongo o en el sistema de archivos y arrepentirme después.

  • Vi que hicieron la columna dkim como NOT NULL; me pregunto cómo lo manejan si un correo no tiene en absoluto el header Dkim-Signature.

• Hace poco intenté integrar Gmail en mi app. Le dediqué muchísimo tiempo a ese proceso, pero al final terminé abandonando el soporte para Gmail. En Gmail to SQLite dicen que el proceso de credenciales termina en 6 pasos, pero en la práctica no fue así. Cuando terminé los 6 pasos, Google volvió a avisarme que la app no estaba publicada; cuando la publiqué, entonces me dijo que, como no era usuario de Workspace, no podía usarla como app interna. Si la cambias a app externa, entonces te exige además otro proceso de verificación por separado (dominio, dirección, más detalles, justificación de permisos, video explicativo, tiempo de revisión, etc.). Me parece demasiado pedirles a usuarios normales que pasen por un proceso tan complicado como el que exige Google. La experiencia directa me dejó muy desconcertado.

  • Simplemente usa IMAP como antes, con una contraseña de aplicación. Es mejor evitar todo el proceso engorroso que exige Google.

  • El proceso para obtener una sola API key de Google es absurdamente engorroso. Me pregunto si alguien sabe por qué lo han hecho así.

• Hace unos años hice una herramienta para visualizar buzones grandes como Gmail: https://github.com/terhechte/postsack

  • Esto está muy bueno. Se siente como una herramienta de visualización de uso de disco, pero enfocada en el volumen del correo. Me pregunto si también tiene una opción para ver cuánto espacio me ocupa cada remitente. Por cierto, el certificado SSL del sitio web está vencido.

  • Se ve interesante. En el readme, el enlace a gmvault ya no funciona; ¿es este el enlace correcto? https://github.com/gaubert/gmvault

  • Se ve realmente interesante. Yo también hice algo parecido en modo DIY con qdirstat, pero en ese caso hay que organizarlo por estructura de carpetas o por fechas, y es difícil recombinarlo después con distintos criterios. Por cierto, el archivo de caché de qdirstat es muy fácil de generar, así que puede ser útil para visualizar datos de varios archivos.

• Sí da pena que ahora ya no se pueda iniciar sesión solo con contraseñas de aplicación y que haya que pasar por todo el proceso complejo de registrar un cliente OAuth y demás. Aunque sea mi propio correo, siento como si Google me hubiera quitado los estándares abiertos que me permitían acceder por mi cuenta.

  • El spam que recibo en mi dirección gratuita de Gmail es muchísimo más que el que recibo en mi dirección pagada para trabajo freelance, y también llega más spam desde servidores de Gmail a mi cuenta que no es de Gmail. Además, al ver que el correo de freelance cada vez cae más seguido en spam en los sistemas de correo de otras personas, me dan más ganas de salir del ecosistema de Google. Pero me cuesta imaginar cómo dejar una rutina tan dependiente de Google; la idea me abruma.

  • No lo entiendo muy bien. Con una contraseña de aplicación puedes tener acceso completo por IMAP.

  • Me pregunto por qué una contraseña de aplicación se considera un estándar abierto y OAuth no.

• Está realmente genial. Nueva función solicitada: estaría bueno poder extraer los enlaces de cancelación de suscripción desde el cuerpo de los correos para darse de baja fácilmente de remitentes frecuentes.

• Yo también probé exactamente esto ayer, porque quería listar cuántos correos recibo por dominio. La calidad del código no es muy buena, pero aquí está: https://github.com/hugoferreira/gmail-sqlite-db

  • Yo también intenté agrupar por dominio y por remitente.

• No sabía que esto fuera posible, gracias.

• Esto me recordó un poco a Archiveopteryx (servidor IMAP basado en Postgres): https://github.com/aox/aox Siempre me ha gustado mucho el esquema de AOX, aunque todavía no he tenido ocasión de usarlo de verdad. Principalmente me interesaba para análisis y búsqueda de correo.

• Me pregunto cuánto cuesta esto en ancho de banda. Solo mi Gmail ya supera los 40 GB, así que me pregunto si usar esta herramienta me va a generar una factura por la transferencia. Claro, si saco un Google Takeout —descarga completa y gratuita del correo— entonces solo habría que parsear los archivos y asunto resuelto. Aun así, esta herramienta parece mucho más rápida y fácil para empezar.

• Siento que esto debería llamarse más bien "imap to sqlite". Me pregunto por qué limitarlo a un proveedor de correo específico.

  • La razón es que esta herramienta está especializada en Gmail. Usa OAuth y el acceso a la API de Google. Por IMAP sería bastante más complejo y más lento, y además choca con los límites de ancho de banda de Google.

  • Como referencia, durante años intenté respaldar mi cuenta de Gmail por IMAP (incluso con herramientas especializadas para Gmail), y nunca lo logré ni una sola vez. Incluso las herramientas de sincronización que sí parecían funcionar se detenían tras más o menos un mes porque no podían descargar cierto correo en particular. Sospecho que quizá se debía a que estaba en cold storage. Por eso pienso que usar la API específica de Google probablemente sea mejor. Ahora simplemente obtengo el mbox directamente desde Google Takeout y puedo hacer un respaldo completo, rápido y sin problemas, lo cual está muy bien (tarda como medio día). La desventaja es que no permite actualizaciones continuas automáticas. Por cierto, ya me cambié a otro servicio de correo (Infomaniak), y me alegra mucho haber tenido desde antes un dominio propio independiente.