Problem
deep-research（2026-07-29）在把 MailKit compose 擴充判為死路的同時，指出一條沒有任何來源測過的旁支：
MailKit 的 MEMessageSecurityHandler / MEMessageEncoder —— MEEncodedOutgoingMessage(rawData:isSigned:isEncrypted:)，Apple 文件明寫其 rawData 是「The full encoded RFC822 message including headers and body」。
限制是「結果若既未簽章也未加密，其 data 會被忽略」—— 但能否以「宣告 isSigned 並帶一個 trivial 簽章」繞過，完全未經測試。
若可行，這是**唯一一條「留在 Mail 生態內、卻能在序列化時刻完全控制 MIME」**的路徑：Sent 記錄、帳號機制、附件、UI 整合全部保留，而 body 由我方決定。
Type
question（探路 spike）
Expected
回答：security extension 的 encoder 鉤子能否作為通用的 body 替換點，且不觸發 wrapper。
Actual
無人測過。deep-research 明列為 open question。
為什麼值得一試
對照另外兩條路徑的代價：
| 路徑 |
留在 Mail 內 |
需 Accessibility |
需 Automation TCC |
Sent 記錄 |
| rich paste（#306） |
✅ |
❌ 需要 |
❌ 需要 |
✅ |
| IMAP APPEND + SMTP（#308） |
❌ |
✅ 不需 |
✅ 不需 |
⚠️ SMTP 直送會失去 |
| MEMessageEncoder（本 issue） |
✅ |
✅ 不需 |
✅ 不需 |
✅ |
若成立，它在四個維度上同時最優。
已知風險（誠實記錄）
- 語意挪用 —— 這是安全擴充的鉤子，拿來做排版修正屬 off-label。Apple 可能在任何版本收緊。
- 需要 trivial 簽章的假設未驗證 —— 「宣告
isSigned 就會採用 rawData」是推測，不是文件承諾。
- 使用者體驗副作用 —— 訊息可能被標示為已簽章，收件端看到簽章標記或驗簽失敗。
- 部署成本 —— MailKit extension 需獨立 target、簽章、使用者在 Mail 設定中啟用。相較目前的 MCP binary 是完全不同的分發模型。
第 3 點可能就足以否決這條路 —— 為了排版而讓每封信帶上假簽章，代價可能高於 wrapper 本身。這點應在投入實作前先判斷。
探路步驟
關聯
Problem
deep-research（2026-07-29）在把 MailKit compose 擴充判為死路的同時，指出一條沒有任何來源測過的旁支：
若可行，這是**唯一一條「留在 Mail 生態內、卻能在序列化時刻完全控制 MIME」**的路徑：Sent 記錄、帳號機制、附件、UI 整合全部保留，而 body 由我方決定。
Type
question（探路 spike）
Expected
回答：security extension 的 encoder 鉤子能否作為通用的 body 替換點，且不觸發 wrapper。
Actual
無人測過。deep-research 明列為 open question。
為什麼值得一試
對照另外兩條路徑的代價：
若成立，它在四個維度上同時最優。
已知風險（誠實記錄）
isSigned就會採用 rawData」是推測，不是文件承諾。第 3 點可能就足以否決這條路 —— 為了排版而讓每封信帶上假簽章，代價可能高於 wrapper 本身。這點應在投入實作前先判斷。
探路步驟
MEMessageSecurityHandler/MEMessageEncoder的完整 API 契約與 Apple 文件措辭isSigned: true，確認收件端的可見後果關聯