为 Himalaya 邮件客户端添加 In-Reply-To 支持

背景

最近在做一个Agent项目，需要解析邮件的会话上下文。Agent 需要通过 In-Reply-To 和 References 这两个邮件头来构建邮件线程（conversation threading），从而理解”这封邮件是对哪封邮件的回复”。

我使用的邮件客户端是 Himalaya —— 一个用 Rust编写的 CLI 邮件管理工具，通过 IMAP 协议连接 Outlook 邮箱。看起来，只要能在获取邮件列表时拿到 In-Reply-To 头，问题就解决了。

https://github.com/pimalaya/himalaya

Himalaya 能获取哪些数据？

先从 Himalaya 的 envelope list 命令入手。这个命令用来获取邮件列表（信封信息），默认每页 25 条。

通过阅读源码，我发现它只能逐文件夹获取，不支持跨文件夹列表。调用链路是：

himalaya envelope list -m INBOX
  → EmailClientStd::list_envelopes(&mailbox, page, page_size, ...)
    → ImapEnvelopeList (io-email)
      → IMAP SELECT + FETCH

IMAP ENVELOPE 里有什么？

IMAP 的 FETCH (ENVELOPE) 命令返回的数据结构（RFC 3501 §7.4.2）是：

ENVELOPE (date subject from sender reply-to to cc bcc in-reply-to message-id)

注意，In-Reply-To 是 IMAP ENVELOPE 响应的一部分，服务器会返回它！但是 References 不在 ENVELOPE 中，需要额外 FETCH 邮件头才能获取。

为什么拿不到 In-Reply-To？

顺着代码追到了 io-email 库 —— 这是 Pimalaya 生态的核心抽象层，定义了所有后端共用的 Envelope 结构体：

pub struct Envelope {
    pub id: String,
    pub message_id: Option<String>,
    pub flags: BTreeSet<Flag>,
    pub subject: String,
    pub from: Vec<Address>,
    pub to: Vec<Address>,
    pub date: Option<DateTime<FixedOffset>>,
    pub size: u64,
    pub has_attachment: Option<bool>,
    // ← 没有 in_reply_to 字段！
}

再看 IMAP 解析函数 envelope_from()：

MessageDataItem::Envelope(env) => {
    // 提取了 subject, date, message_id, from, to
    // env.in_reply_to 被丢弃了 —— 没有字段存储它
}

问题很清楚：IMAP 服务器返回了 In-Reply-To，但 io-email 的数据结构里没有这个字段，数据在解析时被丢弃了。

顺带发现的 Thread 支持情况

在调查过程中，还顺便摸清了 Himalaya 对邮件线程（threading）的支持情况：

测试 v1.2.0 的 himalaya envelope thread -f INBOX 时，日志输出：

WARN: server does not support UID THREAD, falling back to client-side threading
Error: cannot fetch IMAP messages: request timed out

Outlook 的 IMAP 服务器不支持 THREAD 扩展，客户端回退方案需要拉取全部邮件头来自己计算线程，直接超时了。

给上游提 Issue 和 PR

问题的根源在 io-email 库。这是一个很小的改动：

1. Envelope 结构体加一个 in_reply_to: Option<String> 字段
2. envelope_from() 里从 IMAP ENVELOPE 响应补提取一行代码

我给上游仓库提了 Issue #1，描述了问题和方案，然后提交了 PR。

不过，开源项目的合并节奏不可控。为了不被阻塞，我决定先 fork 到自己的仓库继续开发。

Fork 并适配 Himalaya

在 Ezzzi-Y/io-email 的 fork 中添加了 in_reply_to 字段后，修改 Himalaya：

Cargo.toml — 切换依赖到 fork：

io-email.git = "https://github.com/Ezzzi-Y/io-email.git"

src/shared/envelope/list.rs 和 search.rs — 添加 --with-in-reply-to CLI flag：

• 表格模式：需要显式传 --with-in-reply-to 才显示该列（因为 In-Reply-To 通常是较长的 Message-ID 字符串，默认显示会让表格过宽）
• JSON 模式：始终包含 in-reply-to 字段，无需额外 flag

用法：

# 表格显示
himalaya envelope list -m INBOX --with-in-reply-to

# JSON 输出（Agent 消费）
himalaya envelope list -m INBOX --json

总结

整个过程的链路：

Agent 需要 In-Reply-To 构建上下文
  → Himalaya envelope list 不返回该字段
    → io-email 的 Envelope 结构体没有 in_reply_to 字段
      → IMAP ENVELOPE 响应其实包含这个数据，只是被丢弃了
        → 给上游提 Issue + PR
          → Fork 到本地，Himalaya 加 --with-in-reply-to flag

一个小字段的缺失，追了三层依赖才发现根因。这也体现了 Himalaya 的架构特点：应用层薄，协议逻辑全在底层库。改一个小字段，需要同时动 io-email（数据结构 + 协议解析）和 himalaya（CLI 展示）两个仓库。

---

• 上游 Issue: https://github.com/pimalaya/io-email/issues/1
• Fork: https://github.com/Ezzzi-Y/io-email.git