Gmail से SQLite

• Gmail में प्राप्त ईमेल डेटा को व्यवस्थित रूप से प्रबंधित और विश्लेषित करने के लिए उसे SQLite डेटाबेस में बदलने वाला Python-आधारित कमांड-लाइन टूल
• यह ओपन सोर्स रूप में विकसित किया गया है, इसलिए व्यक्ति और कंपनियाँ दोनों इसे स्वतंत्र रूप से विस्तार और अनुकूलित कर सकते हैं
• सामान्य ईमेल प्रबंधन की तुलना में मनचाहे सर्च शब्दों या शर्तों के साथ तेज़ क्वेरी और विस्तृत विश्लेषण संभव है
• डेटा माइग्रेशन आसान है, और बड़े पैमाने के ईमेल का कुशल बैकअप और आर्काइविंग करने में उत्कृष्ट है
• समान ओपन सोर्स विकल्पों की तुलना में कम dependencies, सरल कॉन्फ़िगरेशन, और ऑटोमैटिक इंडेक्सिंग जैसी सुविधाओं के कारण सेटअप करना अधिक सुविधाजनक है

[GN⁺]

Hacker News टिप्पणियाँ

• मुझे यह जिज्ञासा है कि schema में कुछ specific headers को अलग क्यों किया गया उदाहरण के लिए, recipients, subject, sender जैसे fields को भी headers नाम की एक ही JSON entry में रखा जा सकता है, तो इन्हें अलग करने की वजह क्या है, यह जानना चाहूँगा अगर वजह performance है, तब भी headers को JSON blob के रूप में रखा जा सकता है, और ज़रूरी fields को generated columns के रूप में निकालकर इस्तेमाल किया जा सकता है मुझे लगता है कि ऐसा करने पर ALTER TABLE के ज़रिए user अपनी ज़रूरत की queries के हिसाब से indexed generated columns मनचाहे ढंग से जोड़ सकता है, जो बहुत powerful model है उदाहरण के लिए, अगर dkim status query चाहिए, तो ALTER TABLE से उसे जोड़ा जा सकता है और index भी आसानी से बनाया जा सकता है fields को मनचाहे तरीके से बढ़ाया जा सकता है, इसलिए यह कई तरह के use cases में फायदेमंद है

  • सच कहूँ तो generated columns की भी ज़रूरत नहीं है, SQLite expression पर सीधे index बना सकता है इसलिए उदाहरण के लिए subject का index json_extract से सीधे बनाया जा सकता है, और ज़रूरत पड़ने पर query में इस index का इस्तेमाल किया जा सकता है मुझे लगता है कि इस तरह अलग से indexes बनाकर views के साथ इस्तेमाल करना, main table को ALTER करके बदलने से ज़्यादा उपयोगी है

  • सिर्फ one-off queries के लिए index जोड़ना मुझे बहुत अच्छी आदत नहीं लगती आम तौर पर मैं वही columns अलग निकालना पसंद करता हूँ जिनका आगे लगातार और निश्चित रूप से उपयोग होना है, खासकर email headers जैसी stable structure वाली चीज़ों में headers को एक ही JSON में ठूँस देने से बाद में schema बदलना आसान हो सकता है, लेकिन अंत में write की मेहनत read queries में वापस करनी पड़ती है, और कुछ मामलों में यह quietly fail होने वाली situations को भी allow कर देता है

  • मैं भी Postgres में ऐसा ही pattern अक्सर इस्तेमाल करता हूँ पहले सिर्फ वही fields columns में निकालता हूँ जिनकी पक्की ज़रूरत है, और बाकी metadata को JSON column में रख देता हूँ 2 महीने बाद देखकर, जिन fields की सच में ज़रूरत होती है उन्हें फिर JSON से भर देता हूँ, API को compatible रखता हूँ, या views बना लेता हूँ, जैसा ठीक लगे वैसा adjust करता हूँ इससे शुरुआत में सब कुछ बिना सोचे-समझे mongo या filesystem में ठूँस देने और बाद में पछताने वाली growing pains से बचने में बहुत मदद मिली

  • उन्होंने dkim column को NOT NULL बनाया है, तो अगर किसी email में Dkim-Signature header ही न हो, तब यह कैसे handle होगा, यह जानना चाहूँगा

• हाल ही में मैंने अपनी app में Gmail integration करने की कोशिश की इस process में मैंने बहुत समय लगाया, लेकिन अंत में Gmail support छोड़ दिया Gmail to SQLite कहता है कि credentials process 6 steps में खत्म हो जाता है, लेकिन वास्तव में ऐसा नहीं था 6 steps पूरे होने के बाद Google ने फिर बताया कि app publish नहीं हुई है, publish करने पर फिर बताया कि मैं Workspace user नहीं हूँ इसलिए internal app नहीं बना सकता external app में बदलने पर फिर अलग verification process माँगा गया, जिसमें domain, address, details, permissions की वजह, video explanation, review time वगैरह शामिल थे मुझे लगता है कि Google की यह जटिल प्रक्रिया आम users से करवाना बहुत ज़्यादा है अपना अनुभव काफ़ी हैरान करने वाला था

  • पुराना तरीका अपनाओ: IMAP के लिए app password बनाओ और वही इस्तेमाल करो Google की माँगी हुई झंझटों से बचना बेहतर है

  • Google से सिर्फ एक API key लेने के लिए जितने steps से गुज़रना पड़ता है, वह सच में पागलपन की हद तक झंझटभरा है किसी को पता है कि इसे इतना जटिल क्यों बनाया गया है?

• कुछ साल पहले मैंने Gmail जैसे बड़े email datasets को visualize करने वाला एक tool बनाया था: https://github.com/terhechte/postsack

  • यह सच में बहुत बढ़िया है थोड़ा disk-usage visualization tool जैसा feel देता है, लेकिन यहाँ focus mail volume पर है क्या इसमें size दिखाने का कोई option है जिससे पता चले कि कौन-सा sender मेरी storage में सबसे ज़्यादा जगह ले रहा है? वैसे website का SSL certificate expire हो चुका है

  • दिलचस्प लग रहा है readme में gmvault का link अब काम नहीं कर रहा, क्या सही link यह है: https://github.com/gaubert/gmvault ?

  • यह काफ़ी दिलचस्प लगता है मैंने भी qdirstat के साथ ऐसा कुछ DIY करने की कोशिश की थी, लेकिन इस मामले में emails को folder structure या date के हिसाब से sort करना पड़ता है, और अलग-अलग मानदंडों पर फिर से regroup करना आसान नहीं होता वैसे qdirstat की cache files बनाना बहुत आसान है, इसलिए कई files जैसे data को visualize करने में यह काफ़ी उपयोगी हो सकता है

• यह अफ़सोस की बात है कि अब सिर्फ app password से login नहीं किया जा सकता, और OAuth client registration जैसी जटिल प्रक्रिया से गुज़रना पड़ता है अपना ही email होने के बावजूद ऐसा लगता है जैसे Google self-access वाले open standard को छीन रहा हो

  • free Gmail address पर मिलने वाला spam, freelancers के paid address की तुलना में बहुत ज़्यादा है, और Gmail servers से आने वाला spam मेरे non-Gmail account पर भी ज़्यादा आता है खासकर जब मैंने देखा कि freelancer email दूसरे mail systems में बार-बार spam के रूप में चिह्नित हो जाता है, तब से Google ecosystem से बाहर निकलने की इच्छा और बढ़ी है लेकिन Google-dependent routine से बाहर कैसे निकलूँ, यह समझ नहीं आता; थोड़ा बोझ जैसा महसूस होता है

  • मुझे यह बात समझ नहीं आ रही app password होने पर IMAP के ज़रिए पूरे account का access मिल जाता है

  • मैं जानना चाहता हूँ कि app-specific passwords को open standard क्यों माना जाता है, लेकिन OAuth को नहीं

• यह सच में बहुत बढ़िया है नई feature request: email body से unsubscribe links निकालकर frequent senders के हिसाब से आसानी से unsubscribe करने की सुविधा होनी चाहिए

• मैंने भी कल बिल्कुल यही किया था, क्योंकि मैं domain के हिसाब से आने वाले emails की संख्या की list बनाना चाहता था code quality बहुत अच्छी नहीं है, लेकिन यहाँ है: https://github.com/hugoferreira/gmail-sqlite-db

  • मैंने भी यही कोशिश की थी कि domain और sender के हिसाब से group कर सकूँ

• मुझे पता ही नहीं था कि यह संभव है, धन्यवाद

• इससे मुझे थोड़ी Archiveopteryx (Postgres-आधारित IMAP server) की याद आई: https://github.com/aox/aox AOX का schema मुझे हमेशा बहुत अच्छा लगा है, लेकिन अभी तक उसे ठीक से इस्तेमाल करने का मौका नहीं मिला मैं उसे मुख्यतः email analysis या search के लिए इस्तेमाल करना चाहता था

• मैं सोच रहा हूँ कि इसमें bandwidth cost कितनी आएगी सिर्फ मेरा Gmail data ही 40GB से ज़्यादा है, तो क्या इस tool को इस्तेमाल करने पर transfer की वजह से bill आएगा? हाँ, Google Takeout से पूरा email archive मुफ़्त में डाउनलोड करके file parse कर लो तो समस्या आसान हो जाती है फिर भी, यह tool शुरुआत करने के लिए काफ़ी तेज़ और आसान लगता है

• मुझे लगता है इसका नाम कुछ imap to sqlite जैसा होना चाहिए यह किसी एक email provider तक सीमित क्यों है?

  • वजह यह है कि यह tool Gmail के लिए खास तौर पर optimized है यह OAuth और Google के API access का उपयोग करता है IMAP तरीका कहीं ज़्यादा जटिल और धीमा है, और Google की bandwidth limits से भी टकराता है

  • जानकारी के लिए, मैंने कई सालों तक अपने Gmail account का backup IMAP से लेने की कोशिश की, यहाँ तक कि Gmail-specific tools से भी, लेकिन एक बार भी सफल नहीं हुआ जो sync tools ठीक चलते भी थे, वे लगभग एक महीने बाद किसी खास mail को fetch न कर पाने की वजह से रुक जाते थे शायद वह cold storage state में होता होगा इसलिए मुझे लगा कि Google के native API का उपयोग बेहतर रहेगा अभी मैं Google Takeout से सीधे mbox ले लेता हूँ, और अब बिना किसी समस्या के तेज़ी से पूरा backup हो जाता है, जो लगभग आधे दिन में पूरा हो जाता है कमी बस यह है कि इसमें continuous automatic updates नहीं होते वैसे, मैं अब पहले ही दूसरे mail service (Infomaniak) पर migrate कर चुका हूँ, और यह सोचकर अच्छा लगता है कि मैंने पहले से अपना independent domain ले रखा था