[feature] gh-egress 機械閘攔不到 email 形狀字串與 Message-ID（sister concern from PsychQuant/che-apple-mail-mcp#465）

[kiki830621]

Problem

gh-egress.sh 的機械閘（不分嚴格等級、一律生效）目前只攔三項：家目錄的絕對路徑、~/.claude.json 的原文內容、未經確認的 mention token；另有一個 reply 標記的後盾。程式註解還刻意把 email 形狀的 user@host 排除在 mention 閘之外（為了避免誤通知）。

結果：email 地址、Message-ID、UUID 這類識別資訊，完全只靠 LLM 自審。

為什麼現在變得重要

PsychQuant/che-apple-mail-mcp#465 要新增一個回傳 macOS unified log 原始行的工具（使用者明確要求要有原始行）。該 issue 的實測（macOS 27.2、Mail 16.0，10 分鐘窗口、19,172 筆事件）：

項目	筆數	比例
含 email 形狀字串	5,455	28%
含 UUID 形狀字串	925	4.8%
含 <private> 遮蔽	1,490	7.8%

原始行進入 AI 的對話 context 後，如果被貼進公開 repo 的 issue 或 comment，唯一的把關就是 LLM 自審。這把風險從「偶發」變成「只要用這個工具就常態出現」。

Type

feature

Priority

P3（我的假設：目前沒有已發生的外流事件，所以不急；但上述工具上線後這個缺口會被頻繁踩到，維護者可以上調）

Expected

候選做法（open questions，由 diagnose 決定）：

• 機械閘新增一項：偵測 email 形狀字串與 Message-ID: 標頭形狀，命中時依嚴格等級 refuse 或 warn。
• 要處理誤報：公開專案裡合法出現的 noreply 地址、文件範例、commit author 都長得像 email，所以需要 allowlist，或只在 enforce 等級 refuse、其餘等級只 warn。
• 與 mention 閘「email 形狀不算 mention」的設計不衝突：那條是為了避免誤通知，這條是為了避免外洩，兩個目的分開處理。

Actual

讀 gh-egress.sh 的檔頭註解與 net_refuse 呼叫：機械閘只有上述三項加一個 reply 標記後盾；沒有任何 email、Message-ID、UUID 的偵測。在這個 repo 與 PsychQuant/che-apple-mail-mcp 以關鍵字搜尋，沒有重複的 issue。

Impact

所有經 gh-egress.sh 派送的 egress，特別是會把外部資料（日誌、郵件、逐字稿）帶進 issue 或 comment 的工作流。

不在範圍

• 不要求 100% 偵測：機械閘本來就是 last resort，不取代 LLM 自審。
• 不改變 LLM 自審流程本身。

Source: surfaced during /idd-diagnose PsychQuant/che-apple-mail-mcp#465 sister concern surfacing (Step 3.6)