Gmail'den SQLite'a

• Gmail'den alınan e-posta verilerini sistemli biçimde yönetmek ve analiz etmek için bunları bir SQLite veritabanına dönüştüren Python tabanlı komut satırı aracı
• Açık kaynak olarak geliştirildiği için bireyler ve şirketler tarafından özgürce genişletilebilir ve özelleştirilebilir
• Genel e-posta yönetimine kıyasla, istenen arama terimleri veya koşullarla hızlı sorgular ve ayrıntılı analiz yapılmasını sağlar
• Veri taşıma işlemi kolaydır; büyük hacimli e-postaların verimli yedeklenmesi ve arşivlenmesinde çok başarılıdır
• Benzer açık kaynak projelere kıyasla daha az bağımlılık, sade yapılandırma ve otomatik indeksleme gibi özelliklerle kullanım kolaylığı sunar

[GN⁺]

Hacker News görüşü

• Merak ettiğim şey, şemada neden bazı başlıkların ayrı alanlara bölündüğü Örneğin recipients, subject, sender gibi alanların hepsi headers adlı tek bir JSON öğesine konulabilirdi; neden özellikle ayrı tutulmuşlar merak ediyorum Eğer sebep performanssa, yine de headers JSON blob biçiminde tutulup yalnızca gereken alanlar generated column olarak çıkarılabilir Bana göre bu yaklaşım, kullanıcıların ihtiyaç duydukları sorgular için ALTER TABLE ile indekslenmiş generated column'ları serbestçe ekleyebilmesini sağladığından gerçekten güçlü bir model Mesela dkim status sorgusu gerekiyorsa ALTER TABLE ile eklenip kolayca indeks de oluşturulabilir Alanlar istenildiği gibi genişletilebildiği için farklı kullanım amaçları açısından avantajlı

  • Aslında generated column da gerekmiyor; SQLite ifadeler üzerinde doğrudan indeks oluşturabiliyor Yani örneğin subject için indeks doğrudan json_extract ile oluşturulabilir ve bu indeks sorgularda gerektiğinde kullanılabilir Bana göre bu şekilde yalnızca indeks oluşturup view üzerinden kullanmak, ana tabloyu ALTER ile değiştirmekten daha kullanışlı

  • Sadece tek seferlik sorgular için indeks eklemek pek iyi bir alışkanlık gibi gelmiyor Genelde gelecekte kesin ve tutarlı biçimde kullanılacak kolonları özellikle ayrı çıkarmayı tercih ederim; özellikle de e-posta başlıkları gibi yapısı daha stabil olan durumlarda Başlıkları tek bir JSON içinde toplamak, şemayı sonradan değiştirmeyi kolaylaştırabilir ama sonuçta yazma tarafındaki yükü okuma sorgularına geri taşımış oluyorsunuz ve bazı durumlarda sessizce başarısız olan vakalara da izin verebiliyor

  • Ben de Postgres'te benzer bir deseni sık kullanıyorum Önce kesin gerekli alanları kolonlara çıkarıyorum, ek metadata'yı ise JSON kolonda topluyorum İki ay sonra gerçekten gerekli alanlar ortaya çıkınca onları JSON'dan geri doldurup API'yi koruyacak şekilde değiştiriyor ya da view oluşturuyorum; duruma göre esnekçe ayarlıyorum Bu yaklaşım, başlangıçta her şeyi düşünmeden Mongo'ya ya da dosya sistemine doldurup sonradan pişman olunan büyüme sancılarından kaçınmak için çok faydalı oldu

  • dkim kolonunu NOT NULL yapmışlar; peki e-postada Dkim-Signature başlığı hiç yoksa bunun nasıl ele alındığını merak ediyorum

• Yakın zamanda uygulamam için Gmail entegrasyonunu denemiştim Bu süreçte gerçekten çok zaman harcadım ama sonunda Gmail desteğinden vazgeçtim Gmail to SQLite, kimlik bilgisi sürecinin 6 adımda bittiğini söylüyor ama pratikte öyle değildi 6 adımı bitirince Google bu kez uygulamanın publish edilmediğini söyledi; publish edince de Workspace kullanıcısı olmadığım için bunun internal app olamayacağını bildirdi External app'e çevirince de ayrıca doğrulama süreci istedi: alan adı/adres/detay bilgileri, izinlerin neden gerektiğine dair açıklama, video anlatımı, inceleme süresi vb. Google'ın istediği bu karmaşık süreci sıradan kullanıcılara yaptırmak bana fazla geliyor Bunu bizzat yaşayınca gerçekten afalladım

  • Eski usul devam edip IMAP için bir app password alarak kullanmak yeterli Google'ın dayattığı zahmetli süreçten kaçınmak en iyisi

  • Google'dan tek bir API anahtarı almak için geçilen aşamalar gerçekten çılgınca zahmetli Bunu neden bu kadar zorlaştırdıklarını bilen var mı gerçekten merak ediyorum

• Birkaç yıl önce Gmail gibi büyük e-posta arşivlerini görselleştiren bir araç yapmıştım: https://github.com/terhechte/postsack

  • Bu gerçekten çok hoş Disk kullanımını görselleştiren araçlar gibi bir hissi var ama odak doğrudan posta hacminde Acaba gönderen bazında depolama alanımın en çok kim tarafından tüketildiğini gösteren bir boyut görünümü seçeneği de var mı? Bu arada web sitesinin SSL sertifikasının süresi dolmuş

  • İlginç görünüyor readme içindeki gmvault bağlantısı artık çalışmıyor; doğru bağlantı şu mu diye merak ettim: https://github.com/gaubert/gmvault

  • Gerçekten ilginç görünüyor Ben de qdirstat ile buna benzer bir şeyi DIY olarak yapmayı denemiştim ama bu durumda e-posta klasör yapısına ya da tarihe göre sıralamak gerekiyor ve farklı ölçütlere göre yeniden birleştirmek zor oluyor Bu arada qdirstat'ın cache dosyası gerçekten çok kolay oluşturuluyor; o yüzden dosya benzeri verileri görselleştirmede oldukça kullanışlı olabiliyor

• Artık yalnızca app password ile giriş yapamamak ve bunun yerine OAuth client kaydı gibi karmaşık süreçlerden geçmek zorunda kalmak gerçekten üzücü Kendi e-postam olmasına rağmen Google sanki benim erişebileceğim açık standartları elimden almış gibi hissettiriyor

  • Ücretsiz Gmail adreslerine gelen spam, freelancer işi için kullandığım ücretli adrese gelenden açık ara daha fazla; ayrıca Gmail sunucularından gelen spam de Gmail dışı hesabıma daha çok ulaşıyor Özellikle freelance e-posta adresimin karşı tarafın posta sistemlerinde sık sık spam'e düşmeye başladığını fark edince Google ekosisteminden çıkma isteğim giderek arttı Yine de Google bağımlısı rutinlerden nasıl kurtulacağımı bilemiyorum; gözümde büyüyor

  • Çok anlayamadım Sadece app password ile IMAP üzerinden tüm erişim yetkisini alabiliyorsun

  • Neden app password'ü açık standart sayıp OAuth'u açık standart saymadığını merak ediyorum

• Gerçekten harika Yeni özellik isteği: e-posta gövdesinden abonelikten çıkma bağlantılarını çıkarıp sık gelen gönderenler için kolayca abonelikten çıkmayı sağlayan bir özellik olsa güzel olurdu

• Ben de dün tam aynısını denedim; alan adına göre aldığım e-posta sayısını listelemek istiyordum Kod kalitesi çok iyi değil ama burada: https://github.com/hugoferreira/gmail-sqlite-db

  • Ben de aynı şekilde alan adı ve gönderen bazında gruplamayı denemiştim

• Bunun mümkün olduğunu bilmiyordum, teşekkürler

• Bu biraz Archiveopteryx'i (Postgres tabanlı IMAP sunucusu) hatırlatıyor: https://github.com/aox/aox AOX'un şeması bana hep çok iyi görünmüştü ama onu gerçekten kullanma fırsatım henüz olmadı Daha çok e-posta analizi ya da arama amacıyla kullanmak istemiştim

• Buradaki bant genişliği maliyetinin ne kadar olduğunu merak ediyorum Yalnızca Gmail kapasitem 40GB'ı geçiyor; bu aracı kullanırsam veri transferi yüzünden fatura çıkar mı diye düşünüyorum Tabii Google Takeout ile tüm e-postaları ücretsiz indirip dosyaları parse etmek de mümkün, o durumda çözüm kolay Yine de bu araçla başlamak çok daha hızlı ve kolay görünüyor

• Bunun adı daha çok "imap to sqlite" olmalıymış gibi geliyor Neden özellikle tek bir e-posta sağlayıcısına odaklandığını merak ediyorum

  • Sebebi, bu aracın Gmail'e özel olması OAuth ve Google'ın API erişimini kullanıyor IMAP yaklaşımı çok daha karmaşık ve yavaş; ayrıca Google'ın bant genişliği sınırlarına da takılıyor

  • Bilgi olarak, yıllardır Gmail hesabımı IMAP ile yedeklemeyi denedim (hatta Gmail'e özel araçlarla bile) ama bir kez bile tamamen başarılı olamadım Düzgün çalışan senkronizasyon araçları bile yaklaşık bir ay sonra belirli bir e-postayı çekemeyip takılıyordu Muhtemelen bazı iletiler cold storage durumunda olduğu içindir diye düşünüyorum Bu yüzden Google'a özgü API'yi kullanmanın daha iyi olabileceğini düşündüm Şu anda Google Takeout ile doğrudan mbox alıp sorunsuz, hızlı ve eksiksiz yedekleme yapabiliyorum; bu gerçekten çok iyi (yaklaşık yarım gün sürüyor) Dezavantajı, sürekli otomatik güncelleme olmaması Bu arada ben zaten başka bir posta hizmetine (Infomaniak) geçtim ve önceden bağımsız bir alan adına sahip olmanın ne kadar iyi bir karar olduğunu şimdi daha iyi anlıyorum