MailFathom：把 IMAP 信箱同步進自有 PostgreSQL 的 MCP 檢索服務

適合誰

MailFathom 把多個 IMAP 信箱同步進一個由你自行運作的 PostgreSQL 資料庫，對這份副本建立索引，再以 MCP（Model Context Protocol）工具交給 AI 使用。它適合：

• 想讓 AI 幫自己查信件、回答郵件相關問題，而不想在網頁信箱裡反覆搜尋的人；
• 已有自架條件、願意自行運作資料庫與服務的個人或小團隊；
• 在意資料邊界，希望郵件副本與索引只落在自己機器上的使用者；
• 手裡有多個 IMAP 信箱、想讓 AI 在同一處一起檢索的人：多個帳號同步進同一個資料庫。

使用前提與不適合的情況：

• 它不是託管服務：PostgreSQL 和 MailFathom 本身都要你自行運作與維護，不想管伺服器的人不適合；
• 證據只說明了 IMAP 信箱同步，是否支援其他郵件協定、行事曆或附件深度解析均未說明，未確認；
• 標記、草稿、寄送這類寫入操作預設全部關閉，每個帳號、每個憑證都要個別授權後才會開啟，期待開箱即寫的人要先接受這套授權流程。

3 分鐘完成第一次嘗試

推薦主路徑只有一條：複製官方儲存庫並執行快速上手腳本。

git clone https://github.com/fathomise/MailFathom.git
cd MailFathom
scripts/quick-start-compose.sh

前提：一台你可控的機器，並接受郵件副本會存進你運作的 PostgreSQL。腳本所需連接埠、環境變數等細節證據未寫明，執行前先讀腳本確認。之後把服務以 MCP 接入你的 AI 用戶端，接入設定證據未給出，以儲存庫說明為準。

第一次呼叫建議用 list_accounts：屬於讀取類工具，不涉及標記、草稿、寄送這些寫入動作；成功訊號是 AI 回傳已同步帳號的清單。想再進一步，可呼叫 search_emails 以關鍵字搜尋信件，結果按詞法排序；設定嵌入模型後，排序還會參考語意相似度。

讀取查的都是同步進資料庫的副本；多久同步一輪、與真實收件匣時差多大，證據未說明，未確認。

注意：唯讀不等於零風險——讀取工具能看到你同步進資料庫的全部郵件；哪些信箱進入副本、同步範圍如何控制，證據未說明，未確認。

使用案例

案例一：按關鍵字找回舊信。情境：記得某封信提過某個詞，又不想逐頁翻收件匣。做法：讓 AI 呼叫 search_emails，給出關鍵字。可期待的結果：按詞法排序（設定嵌入模型後含語意相似度）的比對信件清單；需要全文時再用 get_email_content，一次最多取十封完整內容。

案例二：跨多封信提問。情境：這件事前後說了什麼，這類需要綜合多封信件的問題。做法：呼叫 ask_mail，用一句自然語言提問。可期待的結果：它根據你同步的郵件回答，並逐條標註引用了哪些信件；涵蓋範圍取決於已同步進資料庫的郵件。

兩個案例都只用讀取能力。要標記、草稿或寄送，必須先逐帳號、逐憑證個別開啟對應寫入權限——這是官方設計，不是故障。

使用邊界

• 讀寫性質：讀取類工具（list_accounts、list_emails、search_emails、get_email_content、ask_mail）與寫入操作（標記、草稿、寄送）嚴格分開；寫入能力預設關閉，須逐帳號、逐憑證個別授權後開啟。寫入作用於真實信箱還是本地同步副本，官方未說明，未確認；是否提供撤銷路徑，同樣未確認。
• 憑證與資料：同步的對象是你的 IMAP 信箱，副本與索引都存在你自己的 PostgreSQL 裡；IMAP 憑證如何提交、如何儲存、是否加密，證據未說明，未確認。
• 檢索與回答的品質邊界：search_emails 預設按詞法排序，語意相似度要設定嵌入模型後才生效；ask_mail 的回答和引用都建立在已同步郵件之上，問不到沒同步進來的內容。
• 副作用與確認點：開啟每一項寫入授權都是應當想清楚的確認點——只開確實需要的那一項；寫入操作的具體效果證據未說明，首次嘗試建議不開寫入授權，只用讀取工具。
• 工具範圍：官方說明二十一個工具就是全部表面；此外的能力沒有證據支持，不要按「應該也行」預期。
• 尚未確認的關鍵資訊：寫入操作的作用位置、IMAP 憑證的儲存方式、除快速上手腳本外的其他安裝方式、具體設定項與效能上限、同步頻率，證據均未涵蓋；授權條款類型為 AGPL-3.0-only（來源標題標註），全文未收錄，請以官方儲存庫為準。