TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
Bichon：把 IMAP 信箱同步成可全文搜尋的自架郵件歸檔工具
Bichon 是 rustmailer 以 Rust 開發的開源自架郵件歸檔伺服器，持續從 IMAP 同步信件、用 Tantivy 建全文索引、靠 BLAKE3 去重，內建 WebUI 與 REST API。它只做歸檔不做收發信，採 AGPL-3.0 授權；內容涵蓋它的能力、三層儲存設計，以及採用前要先接受的幾條硬邊界。
用 AI 摘要這篇文章：
Bichon 是用 Rust 寫的開源自架郵件歸檔伺服器，會持續從你授權的 IMAP 帳號把信同步下來，建立全文索引，再透過內建的 WebUI 與 REST API 讓你搜尋與管理。它屬於 自架信箱工具這個光譜，但做的事很不一樣：Gmail Cleaner 之類的工具處理的是批量退訂與清理，Bichon 處理的是長期保存與跨帳號搜尋。最該先講清楚的一條是，它只歸檔、不能收發信，這條邊界會直接決定它適不適合你。
有幾件事先說在前面，免得你抱錯期待：Bichon 標榜的「高效能」是作者用語，實際搜尋速度、在特定企業郵件伺服器的相容性，都得跑起來才會知道。下面涉及效能與相容性的描述，都是 README 的設計說明，不是實測結論。
歸檔伺服器和郵件客戶端，是兩件事
README 開頭就劃了一條線：Bichon 是 archiver（歸檔器），不是郵件客戶端。它不負責寫信、回信、轉寄，README 的 FAQ 把這條寫得很直白「cannot send, forward, or reply」。它內建一個 SMTP 伺服器，但那個 SMTP 是用來「收信」的接收端，不是讓你把信寄出去的管道。這條設計反映 Bichon 刻意選的定位：把長期保存、往後找得到這件事做到位，把溝通交還給一般郵件客戶端。
這個定位會直接改變你怎麼用它。你不會把 Bichon 開著回信，你會讓它在背景持續同步帳號、維護本地索引，需要的時候進 WebUI 搜十年前某封信的附件。跨帳號統一搜尋是它相對於一般郵件客戶端的主要差異點：多個信箱的資料同步進同一個本地資料庫後，可以在一個介面裡一起查。如果你的需求是「我要一個會幫我發信的工具」，到這裡就可以停下來，Bichon 不是答案；如果你要的是「把多年累積的信變成一個我自己掌控、可以快速翻找的資料庫」，再繼續往下看。
同步、索引與去重：三層儲存怎麼把信收進來
Bichon 的工程核心，是它把三個本來需要外部服務的角色，全部嵌入單一執行檔。README 的 Architecture 區塊畫出三層儲存：memdb 負責帳號、使用者、角色、設定這類後設資料；Tantivy 是全文索引引擎，用 Zstd 壓縮，分信件本體與附件兩個索引；bichon-blob 是它自己寫的 log-structured blob 儲存，也是 Zstd 壓縮。換句話說，你不需要在旁邊再多架一個 PostgreSQL 或 Elasticsearch，Bichon 把這三層全部自己扛。對自架者來說，這代表部署門檻降很多，只要一個容器或一個執行檔加一個資料目錄。
同步這端走的是標準 IMAP。登入方式有兩條：傳統帳號密碼（PLAIN／LOGIN），以及 OAuth 2.0（SASL XOAUTH2），後者支援 token 自動刷新與 PKCE。對 Gmail、Outlook 這類已經停用「應用程式專用密碼」或建議走 OAuth 的服務，OAuth2 路徑比密碼登入更接近官方推薦做法，這也是 Bichon 和 其他需要接 Google／Microsoft 帳號的自架工具共通的整合方式。同步是 UID 為基礎的增量抓取，第一次抓完之後只下載新信，當 IMAP 伺服器的 UIDVALIDITY 改變時會觸發快取重建。抓信的範圍可以用日期、資料夾名稱或數量限定，也能為單一帳號指定 SOCKS5 代理。背後的排程是 README 架構圖裡寫的每 10 秒 reconcile 一次：比對本地與遠端的 UID 差異，有新信就增量抓、UID 變了就整批重建；同時也支援用 cron 表達式為每個帳號設下載排程，例如只在深夜同步、或只在工作時段歸檔，避免白天把頻寬吃滿。手動同步與自動同步有互斥鎖，同一帳號不會同時跑兩個下載工作。
最值得拆開來看的是它的去重機制。每一封進來的信會先用 BLAKE3 算出內容雜湊，附件會從 MIME 樹裡拆出來、各自算雜湊，再以未解碼的原始位元組存在 bichon-blob；信件本體裡原本放附件的位置，會被換成一個 <<BICHON_DETACH_HASH:xxx>> 佔位標記，另存一份。這意味著同一封信在多個帳號、多個資料夾出現時，內容只會存一份；同一個附件到處轉寄，也只佔一次空間。要取回原始信件時，把佔位標記換回對應的附件 blob，README 寫可以做到 byte-identical（逐位元組相同）的還原。這套設計的實際壓縮與去重比率會因人而異，但架構本身是為了「長期收很多信、又不想讓磁碟爆掉」這個情境設計的。
索引建好之後，搜尋能下的條件相當細。除了主旨、內文、收件人這些基本欄位，還能依日期區間、大小區間、是否含附件、附件檔案類型與內容分類篩選，再加上 Tantivy facets 做的標籤組合，邊篩邊帶出即時數量。對話串檢視會把跨資料夾的同一封信往來拉成一條線，看得到完整上下文；聯絡人檢視則把所有授權帳號的寄件人與收件人去重，整理成一份跨帳號通訊錄。儀表板提供信件數量趨勢、主要寄件人、儲存用量分佈與各帳號活躍度，統計範圍依使用者權限縮限。Bichon 不只是把信存下來，還圍繞「往後要怎麼把資料撈出來」這件事把搜尋與瀏覽介面一起做起來。
起手式：一行 Docker 與幾個不能省的環境變數
README 把 Docker 列為推薦安裝方式，起服務只要一行指令：拉 rustmailer/bichon:latest 映像檔，把本機一個資料目錄掛到容器的 /data，對外開 15630 埠，再設兩個必要的環境變數。BICHON_ROOT_DIR 指定所有資料放哪（必須是絕對路徑），BICHON_ENCRYPT_PASSWORD 是用來加密 IMAP 密碼與 OAuth token 的金鑰，AES-256-GCM 等級。啟動後打開 http://localhost:15630 就進 WebUI。偏好 binary 的人也可以從 Releases 頁下載 Linux（GNU／MUSL）、macOS、Windows 版本，原理一樣。
第一次登入用預設管理員 admin／admin@bichon，這組帳號在 README 標為必須立刻改掉，路徑是 Settings → Profile。如果改完忘了，可以用 bichon-admin 這個 CLI 工具重設管理員密碼。多使用者情境下，Bichon 內建五個 RBAC 角色（Admin、Manager、Member、AccountManager、AccountViewer），外加 22 項細項權限與自訂角色，可以把不同使用者綁到不同帳號、限定能讀的範圍。小團隊想共用一台歸檔伺服器時，這層權限設計會用得上。
誰會真的用到，誰會踩空
Bichon 的典型使用者，是那種「信箱就是我的第二大腦」、同時操作多個帳號、而且不願意把這些信交給第三方雲端搜尋服務的人。它和 把個人音樂收進自架服務是同一種思路，只是換成郵件：資料留在自己機器上、搜尋索引也在自己機器上。如果你已經有 Google Takeout 匯出的 MBOX、本機累積的 EML 目錄、Thunderbird 的本地設定檔，或舊的 Outlook PST，Bichon 的 CLI 工具 bichon-cli 支援這幾種格式直接匯入，也能把帳號資料匯出成 MBOX。
會踩空的是兩種人。第一種是要收發信功能的人，前面提過 Bichon 不做這件事，把它當 Thunderbird 或 Gmail 替代品會直接失望。第二種是「完全不想碰指令與 Docker」的人，Bichon 雖然有 WebUI，但從零到跑起來仍需要設環境變數、掛資料目錄、處理反代與憑證，沒有到手即用的一鍵安裝包。對追求 本地優先與資料主權、又願意花一個晚上架設的人，這套工具的取向才會對上。
採用前要接受的幾條硬邊界
第一條是檔案系統的限制。README 用 IMPORTANT 等級標明，Bichon 不支援把資料直接寫進網路檔案系統（NFS、CIFS／SMB 等），BICHON_ROOT_DIR、BICHON_INDEX_DIR、BICHON_DATA_DIR 三個目錄都必須在本地檔案系統上，否則可能資料損毀。直白講，想「把 Bichon 跑在某台機器、資料掛遠端 NAS」這個常見配置是行不通的；要在 NAS 上用，得讓容器直接跑在 NAS 上，不必再把資料遠端掛載過來。
第二條是 OAuth 與帳號相容性。雖然 Bichon 支援 IMAP 自動設定（從郵件網域探測伺服器）與 OAuth2，但企業 Exchange、某些託管郵件的 OAuth 流程或非標準 IMAP 實作，會不會一次通，文件沒辦法保證，得實際接一次才知道。
第三條是預設 WebUI token 7 天過期，長期自動化存取要另外用 WebUI 或 API 建立長效 API token。
把整份郵件交給一個自架工具，安全和隱私是不能略過的門檻，這裡也只能轉述 README 的設計而非第三方稽核：儲存的 IMAP 密碼與 OAuth token 用 AES-256-GCM 加密，金鑰是你自己設的 BICHON_ENCRYPT_PASSWORD，所以這組密碼一旦遺失，等於把存取憑證鎖死；信件裡的外部圖片與追蹤像素預設被擋掉，要逐封信在 WebUI 放行才會載入，這對把信搬離原信箱、又不想一次觸發所有追蹤請求的人是加分的設計；多使用者環境下存取權限在 API 層強制，帳號層級的隔離讓使用者只能讀到自己被授權的帳號。要不要採信這套設計，最終取決於你對自己部署環境與網路暴露面的掌握，Bichon 本身沒有提到獨立的安全稽核報告。
第四條是還沒做的功能。README 的 Roadmap 把幾個常被問的功能列為未完成：MCP Server（讓 LLM 搜尋與分析郵件）、S3 相容的儲存後端、企業 SSO（OIDC／SAML）、以及同步後自動清理遠端信箱騰出空間。如果你的需求已經落在這幾項，現階段不是 Bichon 能直接滿足的，要嘛等路線圖推進、要嘛自己接它的 REST API 補。
硬體需求方面，README 的 FAQ 給出作者建議：4 核 CPU、2GB 以上 RAM，足以應付 10 個以上帳號與 200GB 以上歸檔資料。要強調這是作者的建議規格，不是實測出來的瓶頸數字；實際消耗會看你同步的帳號數、信量與索引規模。作者用「lightweight」「high-performance」描述這套工具，這兩個詞在這裡只能當作開發者的自我定位，不能用來承諾在你的資料量下一定跑得輕快。
授權、活躍度與最後判斷
Bichon 採用 AGPL-3.0（GNU Affero General Public License v3.0），這是一條強 copyleft 授權，關鍵差別在於：如果你修改了 Bichon 又對外提供服務，依授權條款必須公開修改後的原始碼。純個人自架、自己使用不會觸發這條義務，但如果打算產品化或整合進對外服務，法務評估要先做。倉庫掛在 rustmailer 這個 GitHub 帳號下，README 的版權標示為 rustmailer.com，從命名可以看出它和 rustmailer 郵件相關專案屬於同一個開發者體系。
專案活躍度方面，截至 2026 年 8 月，GitHub metadata 顯示，倉庫建立於 2025 年 11 月中，最近一次推送就在這一兩天內，超過 1800 顆星、70 多個 fork。屬於新專案但維持活躍開發，採用風險在成熟度（功能與文件可能持續變動），沒有棄坑疑慮。完整 API 文件走 OpenAPI 3.0，WebUI 內建 18 種語言介面，整合自動化有官方文件可循。
綜合判斷，Bichon 適合「會架 Docker、願意接受 AGPL、明確知道只要歸檔不要發信」的自架者，把多年信箱變成一個本地、可搜、自己掌控的資料庫。它不適合要收發信、要 NAS 遠端掛載、或要企業 SSO 與雲端儲存後端的人。如果你的情境落在前一組，Bichon 把 IMAP 同步、Tantivy 全文索引與 BLAKE3 去重塞進單一自架服務的這個取捨，值得花一個晚上架起來試。想先確認它能不能接通你的郵件服務，最低成本的做法是先只授權一個次要帳號、用 Docker 跑起來，看 OAuth 或 IMAP 一趟同步是否完成、WebUI 搜尋是否找得到那封測試信，再決定要不要把主力帳號也交給它。
