- เครื่องมือบรรทัดคำสั่งที่พัฒนาด้วย Python สำหรับแปลงข้อมูลอีเมลที่ได้รับจาก Gmail ให้เป็นฐานข้อมูล SQLite เพื่อให้จัดการและวิเคราะห์ได้อย่างเป็นระบบ
- พัฒนาในรูปแบบโอเพนซอร์ส จึงสามารถขยายต่อและปรับแต่งได้อย่างอิสระ ทั้งสำหรับบุคคลและองค์กร
- เมื่อเทียบกับการจัดการอีเมลทั่วไป สามารถทำคิวรีที่รวดเร็วและวิเคราะห์เชิงลึกได้ด้วยคำค้นหาหรือเงื่อนไขที่ต้องการ
- ย้ายข้อมูลได้สะดวก และเหมาะอย่างยิ่งสำหรับการทำแบ็กอัปและจัดเก็บถาวรของอีเมลปริมาณมากอย่างมีประสิทธิภาพ
- เมื่อเทียบกับโอเพนซอร์สประเภทเดียวกัน มีจุดเด่นด้านความสะดวกในการตั้งค่า เช่น การพึ่งพาส่วนประกอบน้อย การกำหนดค่าสภาพแวดล้อมที่เรียบง่าย และการทำดัชนีอัตโนมัติ
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
สิ่งที่สงสัยคือทำไมถึงแยกเฮดเดอร์บางตัวออกมาจากสคีมา ยกตัวอย่างเช่นฟิลด์อย่าง recipients, subject, sender ก็สามารถใส่รวมไว้ในรายการ json เดียวชื่อ headers ได้ทั้งหมด เลยสงสัยว่าจำเป็นต้องแยกออกมาต่างหากไปทำไม ถ้าเป็นเรื่องประสิทธิภาพ ก็ยังสามารถเก็บ headers ไว้เป็น json blob แล้วดึงเฉพาะฟิลด์ที่ต้องใช้มาเป็น generated column ได้อยู่ดี ผมคิดว่าถ้าทำแบบนี้จะเป็นโมเดลที่ทรงพลังมาก เพราะผู้ใช้สามารถเพิ่ม generated column ที่มีการทำดัชนีได้อย่างอิสระตามคิวรีที่ต้องการผ่านการ alter table ตัวอย่างเช่น ถ้าต้องการคิวรี dkim status ก็แค่เพิ่มด้วย ALTER TABLE แล้วสร้างดัชนีได้ง่าย มันยืดหยุ่นมากเพราะสามารถขยายฟิลด์ได้ตามต้องการ จึงเหมาะกับหลายกรณีใช้งาน
จริง ๆ ไม่ต้องมี generated column ก็ได้ SQLite สร้างดัชนีบน expression ได้โดยตรง เพราะงั้นอย่างเช่นดัชนีของ subject ก็สร้างจาก json_extract ได้เลย และเอาดัชนีนี้ไปใช้ในคิวรีได้ทุกเมื่อที่ต้องการ ผมรู้สึกว่าการสร้างแค่ดัชนีแยกไว้แบบนี้แล้วใช้งานผ่าน view มีประโยชน์มากกว่าการไป ALTER ตารางหลัก
การเพิ่มดัชนีเพื่อคิวรีครั้งเดียวเฉพาะกิจดูไม่ใช่นิสัยที่ดีเท่าไร ปกติผมจะชอบแยกออกมาเฉพาะคอลัมน์ที่รู้แน่ว่าจะใช้อย่างสม่ำเสมอในอนาคต โดยเฉพาะในกรณีอย่างเฮดเดอร์อีเมลที่โครงสร้างค่อนข้างคงที่ การยัดเฮดเดอร์ทั้งหมดไว้ใน json เดียวอาจทำให้เปลี่ยนสคีมาทีหลังได้ง่าย แต่สุดท้ายก็เหมือนย้ายภาระจากตอนเขียนไปไว้ที่คิวรีตอนอ่าน และบางกรณีก็เปิดโอกาสให้เกิดความล้มเหลวแบบเงียบ ๆ ได้ด้วย
ผมเองก็ใช้แพตเทิร์นคล้ายกันบ่อย ๆ ใน postgres คือแยกฟิลด์ที่จำเป็นแน่ ๆ ออกมาเป็นคอลัมน์ก่อน แล้วเอา metadata เพิ่มเติมไปรวมไว้ในคอลัมน์ json พอผ่านไปสัก 2 เดือน ก็เติมฟิลด์ที่จำเป็นจริงกลับมาจาก json แล้วค่อยปรับให้ API ยังทำงานต่อได้ หรือสร้าง view ขึ้นมาก็ได้ตามสะดวก วิธีนี้ช่วยได้มากในการหลีกเลี่ยงอาการโตแล้วปวดใจจากการยัดทุกอย่างลง mongo หรือ filesystem แบบไม่คิดตั้งแต่แรกแล้วมานั่งเสียดายทีหลัง
เห็นว่าทำคอลัมน์ dkim เป็น NOT NULL เลยสงสัยว่าถ้าอีเมลไม่มีเฮดเดอร์ Dkim-Signature อยู่เลยจะจัดการอย่างไร
ช่วงหลังผมลองทำ Gmail integration ให้แอปตัวเอง ใช้เวลาไปกับเรื่องนี้เยอะมาก แต่สุดท้ายก็ยอมแพ้กับการรองรับ Gmail เขาบอกว่า Gmail to SQLite จบได้ใน 6 ขั้นตอนของกระบวนการ credential แต่ของจริงไม่ใช่แบบนั้น พอทำครบ 6 ขั้นตอน Google ก็แจ้งต่ออีกว่าตัวแอปยังไม่ได้ publish และพอ publish แล้วก็ยังแจ้งอีกว่าใช้แอปภายในไม่ได้เพราะไม่ใช่ผู้ใช้ Workspace ถ้าเปลี่ยนเป็น external app ก็ต้องผ่านขั้นตอนยืนยันเพิ่มเติมอีกต่างหาก ทั้งโดเมน ที่อยู่ รายละเอียด เหตุผลของสิทธิ์การใช้งาน วิดีโออธิบาย และเวลาในการตรวจสอบ ผมคิดว่าการให้ผู้ใช้ทั่วไปต้องมาเจอกระบวนการซับซ้อนแบบที่ Google บังคับนั้นหนักเกินไปมาก ประสบการณ์ตรงนี้ทำให้ผมอึ้งไปเลย
ใช้วิธีเก่าไปเลยก็ได้ คือเปิด IMAP แล้วใช้ app password จะได้หลีกเลี่ยงขั้นตอนจุกจิกที่ Google บังคับ
การจะเอา API key จาก Google สักอันนี่ขั้นตอนยุ่งยากแบบบ้าคลั่งจริง ๆ อยากรู้ว่ามีใครพอรู้ไหมว่าทำไมถึงออกแบบให้เป็นแบบนี้
เมื่อหลายปีก่อนผมเคยทำเครื่องมือสำหรับ visualization ของอีเมลปริมาณมากอย่าง Gmail: https://github.com/terhechte/postsack
อันนี้เจ๋งมาก ให้ความรู้สึกคล้ายเครื่องมือแสดงภาพการใช้พื้นที่ดิสก์ แต่โฟกัสที่ปริมาณเมลโดยตรง อยากรู้ว่ามีตัวเลือกแสดงขนาดเพื่อดูไหมว่าใครกินพื้นที่เก็บข้อมูลของเรามากที่สุดตามผู้ส่ง แล้วก็ขอแจ้งว่าใบรับรอง SSL ของเว็บไซต์หมดอายุแล้ว
ดูน่าสนใจดี เห็นลิงก์ gmvault ใน readme ใช้ไม่ได้แล้ว เลยสงสัยว่าลิงก์ที่ถูกต้องใช่อันนี้ไหม https://github.com/gaubert/gmvault
ดูน่าสนใจมาก ผมเองก็เคยทำอะไรคล้าย ๆ กันแบบ DIY ด้วย qdirstat แต่กรณีนี้ต้องจัดเรียงตามโครงสร้างโฟลเดอร์อีเมลหรือวันที่ และเอากลับมาจัดใหม่ตามเกณฑ์หลากหลายแบบได้ยาก อนึ่ง ไฟล์แคชของ qdirstat สร้างได้ง่ายมาก เลยเอาไปใช้ประโยชน์ได้ดีเวลาอยากทำ visualization ของข้อมูลที่เหมือนไฟล์หลาย ๆ แบบ
น่าเสียดายมากที่ตอนนี้แม้แต่การล็อกอินด้วย app password อย่างเดียวก็ทำไม่ได้แล้ว และต้องไปผ่านขั้นตอนซับซ้อนอย่างการลงทะเบียน oauth client เพิ่ม ทั้งที่มันเป็นอีเมลของผมเอง แต่กลับรู้สึกเหมือน Google กำลังพราก open standard ที่ผมเข้าถึงได้ด้วยตัวเองออกไป
สแปมที่เข้ามาใน Gmail ฟรีมีมากกว่าที่เข้ามาในอีเมลแบบเสียเงินสำหรับงานฟรีแลนซ์ของผมอย่างท่วมท้น และสแปมจากเซิร์ฟเวอร์ Gmail ก็เข้ามายังบัญชีที่ไม่ใช่ Gmail ของผมมากกว่าด้วย โดยเฉพาะพอเริ่มรู้สึกว่าอีเมลฟรีแลนซ์ของผมโดนระบบเมลฝั่งปลายทางตีเป็นสแปมบ่อย ๆ ก็ยิ่งอยากออกจาก ecosystem ของ Google มากขึ้นเรื่อย ๆ แต่ก็ยังนึกไม่ออกว่าจะหลุดจากรูทีนที่พึ่งพา Google อยู่ได้อย่างไร เลยรู้สึกหนักใจ
ผมไม่ค่อยเข้าใจ ถ้ามี app password ก็เข้าถึง IMAP ได้เต็มรูปแบบอยู่แล้ว
สงสัยว่าทำไมถึงมองว่า app-specific password เป็น open standard แต่ไม่มอง oauth ว่าเป็น open standard
เจ๋งมาก ขอฟีเจอร์ใหม่: อยากให้มีฟังก์ชันดึงลิงก์ยกเลิกการสมัครจากเนื้อหาอีเมล เพื่อจะได้ยกเลิกอีเมลจากผู้ส่งที่ส่งมาบ่อย ๆ ได้ง่าย
เมื่อวานผมก็เพิ่งลองทำแบบเดียวกันเลย เพราะอยากลิสต์จำนวนอีเมลที่ได้รับแยกตามโดเมน โค้ดคุณภาพไม่ค่อยดี แต่เอาไว้ที่นี่: https://github.com/hugoferreira/gmail-sqlite-db
ไม่รู้มาก่อนเลยว่าแบบนี้ทำได้ ขอบคุณ
ทำให้นึกถึง Archiveopteryx (IMAP server บน Postgres) อยู่บ้าง: https://github.com/aox/aox ผมชอบสคีมาของ AOX มาโดยตลอด แต่ยังไม่เคยมีโอกาสได้ลองใช้งานจริงจังสักที ส่วนใหญ่ผมอยากใช้มันกับงานวิเคราะห์หรือค้นหาอีเมล
สงสัยว่าค่าใช้จ่ายด้านแบนด์วิดท์ของสิ่งนี้จะเป็นเท่าไร บัญชี Gmail ของผมอย่างเดียวก็เกิน 40GB แล้ว เลยสงสัยว่าถ้าใช้เครื่องมือนี้จะโดนคิดค่าทราฟฟิกจนมีบิลตามมาหรือเปล่า แน่นอนว่าถ้าใช้ Google Takeout เพื่อดาวน์โหลดอีเมลทั้งหมดฟรีแล้วค่อย parse ไฟล์ทีหลังก็แก้ปัญหาได้ง่ายกว่า แต่ถึงอย่างนั้น เครื่องมือนี้ก็ดูน่าจะเริ่มต้นได้เร็วและง่ายกว่ามาก
รู้สึกว่ามันน่าจะชื่อ "imap to sqlite" มากกว่าไหม สงสัยว่าทำไมถึงจำกัดไว้กับผู้ให้บริการอีเมลรายเดียว
เหตุผลคือเครื่องมือนี้ทำมาเฉพาะสำหรับ Gmail เพราะมันใช้ OAuth และ API access ของ Google วิธีแบบ IMAP ซับซ้อนกว่า ช้ากว่ามาก และยังติดข้อจำกัดด้านแบนด์วิดท์ของ Google อีกด้วย
ข้อมูลเพิ่มเติมคือ ผมพยายามสำรองบัญชี gmail ของตัวเองผ่าน imap มาหลายปีแล้ว (แม้จะใช้เครื่องมือที่ทำมาเพื่อ gmail โดยเฉพาะก็ตาม) แต่ไม่เคยสำเร็จสักครั้ง แม้แต่เครื่องมือซิงก์ที่ดูเหมือนจะทำงานได้ก็จะรันอยู่ประมาณหนึ่งเดือน ก่อนจะหยุดเพราะดึงเมลบางฉบับมาไม่ได้ในที่สุด อาจเป็นเพราะมันอยู่ในสถานะ cold storage ก็ได้ เพราะงั้นผมเลยคิดว่าการใช้ API เฉพาะของ Google น่าจะดีกว่า ตอนนี้ผมใช้ Google Takeout เอาไฟล์ mbox มาโดยตรงได้แล้ว และสำรองข้อมูลได้ครบ เร็ว และไม่มีปัญหาเลย ซึ่งดีมาก (ใช้เวลาราวครึ่งวัน) ข้อเสียคือมันอัปเดตต่อเนื่องแบบอัตโนมัติไม่ได้ อนึ่ง ตอนนี้ผมย้ายไปใช้บริการเมลเจ้าอื่นแล้ว (Infomaniak) และดีใจมากที่ตัวเองมีโดเมนอิสระอยู่ก่อนแล้ว