KechuAI

Himalaya：用 Rust 写的无状态命令行邮件客户端，专为脚本与 Agent 而生

工具
Rust
命令行
邮件
IMAP
Agent
开源
2026/9/28
·

阅读时间: 大约 11 分钟

Himalaya：用 Rust 写的无状态命令行邮件客户端，专为脚本与 Agent 而生

Himalaya 信封列表输出：ID、标志位、主题、发件人、日期分列（官方截图）

邮件是办公自动化里绕不开的一环，但传统终端邮件客户端——mutt、aerc、alpine——都是 TUI（终端用户界面）：一旦启动，终端就锁进一个事件循环，靠快捷键操作。这种范式适合人交互，却不适合脚本和 Agent。Himalaya 由开发者 soywod 用 Rust 编写，走的是另一条路：它是一个无状态的 CLI（命令行界面），列信封、读邮件、打标记、下附件、写 Sieve 过滤规则，都是一条独立的 shell 命令，每次调用自开 TCP+TLS+SASL 会话。本文基于其 GitHub 官方 README，对这一项目做一次拆解。

一、为什么是”无状态 CLI”而不是 TUI

README 在 FAQ 里把这件事讲得很直白：mutt/aerc/alpine 启动后占用整个终端进入事件循环；Himalaya 没有事件循环，你就是在 shell 里敲命令。这一区别在今天变得格外有价值：

  • 天然可脚本化：himalaya envelope search ... 的输出可以直接管道给 jq、awk；加 --json 就是结构化数据；
  • 天然可被 Agent 调用：大模型 Agent 操作邮件时，不需要模拟 TUI 按键，只需要生成命令行；官方甚至维护了一个 OpenClaw SKILL，等于把它包装成 Agent 可直接调用的工具；
  • 与既有工具链正交：官方 TUI（himalaya-tui）仍在开发中，但 CLI 本身已经是其他前端（Vim 插件、Emacs 插件、Raycast 扩展、dfzf）的公共底座。

二、协议覆盖面：一个工具打通主流邮件后端

Himalaya 的协议栈在同类 CLI 里算相当全的，后端用 Cargo feature 按需编译：

类别支持情况
标准协议IMAP、SMTP、ManageSieve（Sieve 过滤脚本）、JMAP
厂商原生 APIGmail REST API、Microsoft Graph（Outlook / Microsoft 365）
本地存储Maildir、m2dir、pimdir
认证anonymous、login、plain、oauthbearer、xoauth2、scram-sha-256；JMAP basic/bearer
TLSRustls（ring 加密后端）、Rustls（aws crypto，需 feature）、Native TLS（需 feature）
代理SOCKS5 / HTTP，走 $ALL_PROXY、$HTTP_PROXY
自动发现PACC、Thunderbird Autoconfiguration、RFC 6186 SRV、RFC 8620 JMAP session

典型用法长这样：

himalaya mailbox list
himalaya envelope list --page 2
himalaya envelope search from alice and after 2026-01-01 order by date desc
himalaya flag add --flag seen 1 2 3 5
himalaya message read 42
himalaya attachment download 42

它有两层 API：一层是跨后端的”共享 API”（mailboxes/envelopes/flags/messages/attachments），另一层是每个后端暴露自己的原生 API（如 himalaya imap raw 'a1 SEARCH ...'、himalaya jmap mailbox query、himalaya gmail messages list -q ...、himalaya msgraph mail-folders list），需要直连厂商特性时不必绕过抽象层。

三、配置：TOML 多账户 + 向导自动发现

首次运行 himalaya 且没有配置文件时，向导会问你一个邮箱地址，然后并行探测 PACC、Thunderbird Autoconfiguration、RFC 6186 SRV、RFC 8620 JMAP 解析，合并结果并为每项服务选最安全的端点，再按对方宣告的认证方式测试连接，最后写入磁盘。配置文件依次查找 $XDG_CONFIG_HOME/himalaya/config.toml、~/.config/himalaya/config.toml、~/.himalayarc。

几个有代表性的账户配置值得一提：

  • Gmail：不能用账号密码走 PLAIN，需要两步验证下的应用专用密码；想用 Gmail 原生 REST API 则换成 OAuth 2.0 bearer token；
  • Outlook / Microsoft 365：微软已停用基本认证，必须用 OAuth 2.0（oauthbearer / xoauth2）；
  • Proton Mail：Proton 不直接暴露 IMAP/SMTP，需要本地跑 Proton Bridge，再连它暴露的本地 IMAP/SMTP 端口；
  • Fastmail：可用应用密码走 IMAP/SMTP，也可用 API token 走原生 JMAP；
  • iCloud：IMAP 用户名是邮箱前缀、SMTP 用完整地址，且必须用专用 App 密码。

密钥读取上，所有 *.password / *.token 字段都支持两种写法：raw 直接写明文（仅供测试），或 command 调用外部密码管理器（如 pass show gmail）打印到 stdout。这是一种把”密钥存储”完全交给用户已有工具的设计。

四、v2 的两个重要取舍

官方 README 的 FAQ 明确记录了 v2 相比旧版的两处”退步”，这正是它上手门槛的来源：

  1. 移除了原生 keychain 支持。官方建议改用 pass、secret-tool、gopass 等第三方密钥管理 CLI 作为 command 提供密钥；
  2. 不再内置 OAuth 流程。Gmail/Outlook 等需要 OAuth 的场景，要先用外部 token broker（官方自家的 ortie或同类工具）拿到 access token，再通过 token.command 喂给 Himalaya。

另外，每次调用都新开一次 TCP+TLS+SASL 握手，对高频脚本不友好；官方建议配合 sirup——它在 Unix socket 上常驻一个预认证的 IMAP/SMTP 会话，让 Himalaya 直连复用。

五、客观分析：优势与局限

优势：

  1. 协议覆盖真全：IMAP/SMTP/JMAP/ManageSieve 标准协议 + Gmail/Outlook 原生 API + 三种本地 Maildir 变体，一个工具顶过去好几个脚本；
  2. 无状态 CLI 模型契合自动化：--json 输出 + shell 管道 + Agent SKILL，是目前最适合被程序调用的邮件接口之一；
  3. 工程严谨：Rust 编写、Cargo feature 裁剪后端、自动发现并行探测、TLS 多后端可选、日志遵循 RUST_LOG 与 NO_COLOR 约定；
  4. 可持续的资金来源：由 NLnet 基金会与欧盟 NGI 系列计划资助（2022→2027 连续四期），MIT/Apache-2.0 双许可，不是无人维护的个人玩具。

局限与存疑：

  1. 对普通用户不友好：OAuth 要自己装 ortie、密钥要自己接 pass、Outlook 还要走 xoauth2，配置 TOML 有学习成本；
  2. 每次调用重新握手：高频脚本必须额外搭 sirup，否则延迟累积明显；
  3. TUI 仍在开发中：日常人机交互体验还不能和 mutt/aerc 比，CLI 本身更偏”给程序用”而非”给人天天读信”；
  4. 功能偏工程师向：富文本 MIME 撰写、签名/加密需要再链式调用外部 composer（如 mml），开箱即用的”写邮件”体验不如图形客户端。

六、谁该关注

  • 想把邮件接进自动化脚本、CI、或自己的 Agent 工作流的开发者；
  • 重度使用 IMAP/JMAP、却反感图形客户端同步与遥测的极客；
  • 已经在用 pass / gopass 管理密钥、习惯 TOML 配置的 Nix/Arch 用户。

如果你只是想要一个”装上就能用”的桌面邮件客户端，Himalaya 现阶段不是它；但如果你需要一个可编程、可脚本化、可被 Agent 调用的邮件底座，它在同类里几乎是目前覆盖面最广、设计最对路的选择。

参考来源