Gmail para SQLite

• Ferramenta de linha de comando baseada em Python que converte dados de e-mail recebidos no Gmail para um banco de dados SQLite, permitindo gerenciamento e análise de forma estruturada
• Desenvolvida como open source, permitindo que tanto indivíduos quanto empresas façam extensões e personalizações livremente
• Em comparação com o gerenciamento comum de e-mails, permite consultas rápidas e análises detalhadas com os termos de busca ou condições desejados
• Facilita a migração de dados e é excelente para backup e arquivamento eficientes de grandes volumes de e-mails
• Destaca-se pela praticidade da configuração, com menos dependências do que alternativas open source semelhantes, configuração simples e indexação automática

[GN⁺]

Comentários no Hacker News

• O que me deixa curioso é por que certos cabeçalhos foram separados no esquema. Por exemplo, campos como recipients, subject e sender poderiam todos ficar dentro de um único item JSON chamado headers, então fico curioso sobre o motivo de separá-los. Se for por desempenho, ainda assim daria para manter headers como um blob JSON e extrair só os campos necessários como colunas geradas. Acho que isso seria um modelo realmente poderoso, porque o usuário poderia adicionar livremente colunas geradas indexadas para as consultas que precisar via ALTER TABLE. Por exemplo, se precisar consultar o status de DKIM, poderia adicionar com ALTER TABLE e criar um índice com facilidade. Como os campos podem ser estendidos livremente do jeito que você quiser, isso é vantajoso para vários usos.

  • Na verdade, nem precisa de colunas geradas; o SQLite consegue criar índices diretamente sobre expressões. Então, por exemplo, dá para criar um índice de subject diretamente com json_extract e usar esse índice nas consultas sempre que precisar. Tenho a impressão de que criar índices assim de forma separada e usar views é mais útil do que alterar a tabela principal com ALTER.

  • Adicionar índice só para uma consulta pontual não me parece um hábito muito bom. Em geral, prefiro extrair separadamente apenas as colunas que sei com certeza que serão usadas de forma consistente no futuro, especialmente quando a estrutura é estável, como nos cabeçalhos de e-mail. Colocar todos os cabeçalhos em um único JSON pode facilitar mudar o esquema depois, mas no fim você só transfere para as consultas de leitura o trabalho que deixou de fazer na escrita, e em alguns casos isso ainda permite falhas silenciosas.

  • Eu também uso bastante um padrão parecido no Postgres. Primeiro separo em colunas só os campos que são claramente necessários, e concentro os metadados adicionais em uma coluna JSON. Depois de uns 2 meses, reajusto com liberdade: preencho a partir do JSON os campos que de fato se mostraram necessários, faço mudanças para manter a API estável ou crio views. Isso foi muito útil para evitar aquelas dores de crescimento de começar jogando tudo sem pensar no Mongo ou no sistema de arquivos e se arrepender depois.

  • Vi que a coluna dkim foi definida como NOT NULL; fico curioso sobre como isso é tratado se o e-mail simplesmente não tiver nenhum cabeçalho Dkim-Signature.

• Tentei recentemente integrar o Gmail ao meu app. Gastei realmente muito tempo nisso, mas no fim desisti de oferecer suporte ao Gmail. Dizem que o Gmail to SQLite resolve o processo de credenciais em 6 etapas, mas na prática não foi assim. Quando terminei as 6 etapas, o Google ainda avisou de novo que o app não estava publicado; depois que publiquei, apareceu outro aviso dizendo que, por eu não ser usuário do Workspace, não dava para usar como app interno. Ao mudar para app externo, ainda exigiram um processo adicional de verificação (pedindo domínio, endereço, detalhes, justificativa para as permissões, vídeo explicativo, tempo de revisão etc.). Acho demais fazer usuários comuns passarem por toda essa complexidade exigida pelo Google. Fiquei bem chocado com a experiência.

  • É só usar do jeito antigo com IMAP e uma senha de app. Melhor evitar esse processo burocrático que o Google exige.

  • O número de etapas para conseguir uma única chave de API do Google é absurdamente burocrático. Queria saber se alguém entende por que fizeram isso ficar assim.

• Há alguns anos eu fiz uma ferramenta para visualizar e-mails grandes, como os do Gmail: https://github.com/terhechte/postsack

  • Isso é muito legal. Parece uma ferramenta de visualização de uso de disco, mas focada no volume de e-mails em si. Queria saber se também existe uma opção de mostrar o tamanho por remetente, para ver quem ocupa mais espaço no meu armazenamento. Aliás, o certificado SSL do site expirou.

  • Parece interessante. O link para o gmvault no readme não funciona mais; seria este o link correto? https://github.com/gaubert/gmvault

  • Parece muito interessante. Eu já cheguei a fazer algo parecido no estilo DIY com o qdirstat, mas nesse caso você precisa organizar pela estrutura de pastas de e-mail ou por data, e fica difícil recombinar depois segundo critérios diferentes. Aliás, o arquivo de cache do qdirstat é realmente muito fácil de gerar, então ele pode ser bem útil para visualizar dados de vários tipos de arquivo.

• É realmente uma pena que agora nem só com senha de app já dê para entrar, e que seja preciso passar por um processo complicado com registro de cliente OAuth e afins. Mesmo sendo meu e-mail, tenho a sensação de que o Google acabou tirando de mim padrões abertos pelos quais eu poderia acessá-lo por conta própria.

  • O volume de spam que recebo em um endereço gratuito do Gmail é esmagadoramente maior do que em um endereço pago para trabalho freelance, e também recebo mais spam vindo de servidores do Gmail na minha conta que não é Gmail. Especialmente depois de perceber que meu e-mail profissional como freelancer vive sendo tratado como spam pelos sistemas de e-mail dos outros, fui ficando cada vez com mais vontade de sair do ecossistema do Google. Só não faço ideia de como me desligar dessa rotina dependente do Google; isso me deixa meio sobrecarregado.

  • Não entendi muito bem. Com uma senha de app você pode ter acesso IMAP completo.

  • Fico curioso sobre por que senha de app seria considerada um padrão aberto, enquanto OAuth não seria.

• Muito legal. Pedido de funcionalidade nova: seria ótimo ter uma função que extraísse links de cancelamento de assinatura do corpo do e-mail para facilitar o descadastro de remetentes frequentes.

• Eu também fiz exatamente isso ontem, porque queria listar quantos e-mails recebo por domínio. A qualidade do código não é das melhores, mas está aqui: https://github.com/hugoferreira/gmail-sqlite-db

  • Eu também tentei fazer exatamente isso, agrupando por domínio e por remetente.

• Eu não sabia que isso era possível, obrigado.

• Isso me lembra um pouco o Archiveopteryx (servidor IMAP baseado em Postgres): https://github.com/aox/aox Sempre achei o esquema do AOX muito bom, mas ainda não tive a chance de usá-lo de verdade. Eu queria principalmente usar algo assim para análise e busca em e-mails.

• Fico curioso sobre quanto isso custa em largura de banda. Só no Gmail eu tenho mais de 40 GB, então queria saber se usar essa ferramenta acabaria gerando cobrança por volume transferido. Claro, se eu baixar tudo com o Google Takeout (download gratuito do e-mail inteiro), aí bastaria fazer o parsing dos arquivos e o problema estaria resolvido. Ainda assim, esta ferramenta parece ser muito mais rápida e fácil para começar.

• Fico pensando se isso não deveria se chamar algo como "imap to sqlite". Queria entender por que limitar a um provedor de e-mail específico.

  • O motivo é que esta ferramenta é especializada em Gmail. Ela usa OAuth e o acesso à API do Google. O método por IMAP é bem mais complexo e lento, além de esbarrar nos limites de largura de banda do Google.

  • Só como referência: durante anos tentei fazer backup da minha conta do Gmail via IMAP (inclusive com ferramentas específicas para Gmail) e nunca consegui concluir uma vez sequer. Mesmo as ferramentas de sincronização que pareciam funcionar rodavam por cerca de um mês e depois paravam ao não conseguir buscar algum e-mail específico. Talvez fosse porque essas mensagens estavam em cold storage. Por isso achei que usar a API própria do Google poderia ser melhor. Hoje em dia estou muito satisfeito porque o Google Takeout entrega diretamente um mbox, e consigo fazer backup completo de forma rápida e sem problemas (leva algo como meio dia). A desvantagem é que não há atualização automática contínua. Aliás, eu já migrei para outro serviço de e-mail (Infomaniak) e acho que ter tido um domínio próprio com antecedência foi uma decisão excelente.