邮件 MCP 如何避免破坏用户邮箱状态

dev.to · AI#MCP#邮件#状态一致性

Editor brief · 编辑速览

作者因现有邮件连接器在线程回复、转发和附件操作上的不足，自建 Mailbox MCP。文章以误改已读状态、拆散会话及发件记录重复或缺失为例，讨论写入型 MCP 的工程要求。

文章思维导图

Knowledge map

拖拽缩放

AI deep read

AI 深度解读

AI 帮你处理了一上午邮件，关掉聊天窗口，再打开 Outlook：未读标记还在吗？回复有没有串错会话？已发送邮件是不是恰好一份？Mailbox MCP 作者认为，这些才是邮件 AI 是否可靠的验收标准。

这位从 2002 年起运营邮件和 Web 服务器的开发者，因为现成连接器的回复、转发和附件处理不顺手，自己做了一个邮件 MCP 服务。它最有参考价值的地方，是如何让 AI 接入已有系统，同时守住用户依赖的状态和操作习惯。

AI 处理邮件，先守住哪些状态

作者看重的邮件任务，多数不是代写，而是查找、回忆和归档：找出与供应商谈定的价格，列出本周尚未回复的邮件并起草回复，把昨天的报价连同新版 PDF 转发出去，或者把会计发来的邮件归入 Finance。

作者称，原本需要十分钟翻找的工作，AI 几秒就能完成。不过，原文没有给出这部分效率的对照测试。

邮箱又是多个客户端共享的真实工作空间。AI 读取邮件，如果顺手清掉未读标记，就改变了用户的待办依据；发送邮件更无法靠关闭聊天窗口撤销。因此，作者先定了几条行为规则：读取不标记已读，删除移入 Trash，草稿存进真实 Drafts，回复保持会话关系，已发送邮件在 Sent 中恰好保留一份。

AI 的操作结果，要经得起用户打开原有客户端检查。

作者把邮件客户端称为验收依据（oracle）。涉及邮箱状态的功能，最后都要由人在真实客户端里检查。内部测试可能和实现共享同一个错误假设，例如测试根本没检查 Sent，自然发现不了漏存副本。

标题里的「不留痕迹」，指的是不留下异常状态。正常草稿、回复标记和已发送记录，反而必须留下。

回复和附件，为什么不能只看是否发送成功

按照 RFC 5322 第 3.6.4 节，正确回复需要延续父邮件的身份。原文示例中，新邮件拥有自己的 Message-ID: <reply-789@example.com>，通过 In-Reply-To: <parent-456@example.com> 指向父邮件，再由 References: <root-123@example.com> <parent-456@example.com> 保留会话链，主题为 Subject: Re: Revised quote。

这些字段决定客户端如何拼接会话。作者还处理了长引用链裁剪、避免 Re: Re: Re: 堆叠，以及 AW、SV、Antw、Odp 等其他语言的回复前缀。

Reply-all 要从 To 和 Cc 中移除自己的地址及别名；原文引用要同时提供纯文本和干净的 HTML，并带上「On [date], [name] wrote:」这样的引述行。原邮件还要设置 \Answered，让 Outlook 显示回复箭头。发送成功只是其中一步。

附件则暴露了另一个接口设计问题：让模型输出文件的 base64，成本很高。Base64 每 3 字节变成 4 个字符，一个 5 MB PDF 会膨胀到约 700 万字符。模型逐字生成这些内容，既慢，也可能超过会话容量。

Mailbox MCP 因此让模型传文件引用，由服务器在发送时获取字节：

{
  "to": "sam@example.com",
  "subject": "Revised quote",
  "text": "Here's the revised quote we talked about.",
  "attachments": [
    { "fileRef": "<an attachment ref from read_email>" },
    { "url": "https://example.com/terms.pdf" },
    { "uploadId": "<files someone dropped on a one-off upload page>" }
  ]
}

注意 attachments 的三条路径：fileRef 引用 read_email 返回的已有附件，url 指向网络文件，uploadId 对应通过一次性页面上传的文件。

这里节省的是文件正文穿过模型产生的 token，工具参数仍然进入上下文。模型需要理解附件时，读取内容的成本也不会自动消失。原文没有展开 URL 获取权限、上传有效期等细节。

IMAP 的细节，决定邮箱会不会被悄悄改坏

读取邮件时，作者统一使用 BODY.PEEK。RFC 3501 规定，它不会隐式设置 \Seen，因此 AI 查看邮件不会清掉未读标记。

定位文件夹也不能只猜名字。Sent 可能叫 Sent Items、Sent Messages，或其他语言的名称。支持 RFC 6154 的服务器可以通过 LIST "" "*" RETURN (SPECIAL-USE) 返回特殊用途标记，以 \Sent 和 \Trash 识别文件夹，比匹配名称可靠。

能力探测还要放在登录后。作者测试的一台 Dovecot 服务器，欢迎消息只公布 4 项能力，登录后却有 38 项。只读欢迎消息未必报错，却可能一直走低效路径，例如用复制加删除代替移动。

Sent 副本更麻烦：有些服务商发送后自动保存，有些普通 IMAP 主机不会。Mailbox MCP 每次发送后，用该邮件的精确身份搜索 Sent；找到就不添加，否则追加一份。

Microsoft 365 则需要另一条发送路径。按原文所述，Microsoft 在 2022 年关闭了 Exchange Online 的 IMAP、POP 密码登录，不少租户也关闭 SMTP AUTH。Mailbox MCP 使用 Microsoft 登录，并通过 Microsoft Graph 发送邮件。

作者提供的实测包括：单次会话经 IMAP 读取 26,930 封邮件，涉及 6.63 GB 数据；Sent Items 最终留下 0 份重复副本；经 SMTP 发往外部域名约 10 秒送达。最后一项是 SMTP 测量，不能拿来证明 Graph 的发送延迟。

我的判断

我认同作者把客户端状态放在验收中心。邮件和日历、文件、工单一样，已有一套用户熟悉的行为约定。MCP 工具如果只验证接口返回成功，就容易漏掉后续使用中的问题。

附件引用方案也值得借鉴。模型适合决定使用哪个文件，文件搬运交给服务端处理。这比要求模型输出大段编码数据，更符合各自的职责。

但原文仍是一篇作者自述。没有竞品对照、完整测试矩阵，也没交代测试服务器配置。26,930 封邮件和 6.63 GB 说明作者做过一定规模的验证，不能直接推广成所有邮箱环境下的可靠性结论。

发送后查一次 Sent，也不足以单独证明严格的「恰好一次」。

服务商延迟保存、搜索可见性延迟、请求超时重试，都可能影响结果。原文没有说明这些情况如何收敛。目前能确认的是作者报告测试后没有重复副本。

产品边界也要一起看：每封邮件的附件总量上限为 20 MB，这是产品限制；不支持 Microsoft 365 的 Full Access 或 Send As 共享、委托邮箱；不提供备份、导出、复制和迁移，也不能恢复已经删除的邮件。日历需要单独连接。

此外，它是远程 MCP 服务。原文没有充分说明凭据存储、数据保留和权限隔离。接入业务邮箱前，这些仍需核实。

能拿来做什么

给现有系统开发 MCP 工具时，把验收写成用户可观察的结果。例如邮件读取后仍未读、草稿能在 Outlook 编辑、删除后能在 Trash 找回，再让测试覆盖这些结果。
在 Node 服务中处理附件时，可以参考 fileRef、url、uploadId 的引用方式，让服务端搬运字节，并补齐权限、大小和有效期校验。
日常 AI 邮件协作可以先采用「只生成草稿」：让 AI 找出待回复事项，把草稿放进 Drafts，再由自己检查并发送。作者描述了这种用法，但原文没有说明是否提供强制禁发权限。
如果要试接 Mailbox MCP，原文给出的 Claude Code 命令如下。它通过 Microsoft 登录、Gmail app password 或 IMAP 信息连接邮箱，同一 MCP URL 也可用于 Claude、ChatGPT、Cursor、VS Code 和 Zed；作者称提供免费层。

claude mcp add --transport http --scope user work-mail \
  https://mcp.mailbox-mcp.com/db/mcp/YOUR-MAILBOX-KEY

注意 --scope user 设置的是 Claude Code 配置范围；命令中的 YOUR-MAILBOX-KEY 需要替换为自己的邮箱连接标识。