Stalwart v0.16：全新基石

# Stalwart v0.16：全新基础 来源：https://stalw.art/blog/stalwart-0-16/ 经过三个多月的专注开发，我们非常高兴地宣布发布 Stalwart v0.16（https://github.com/stalwartlabs/stalwart）。这无疑是我们发布过的最雄心勃勃的版本，实打实的数百项新功能、改进和修复覆盖了服务器的每一个角落。 有件事我们要先说清楚：初次接触 v0.16 时，你会觉得它像是一款全新的产品。一些长期存在的概念已被重构，少数已被移除，同时引入了许多新概念。这是深思熟虑后的选择。Stalwart 已持续开发近五年，其功能集和用户规模都远远超出了最初配置和管理层的设计承载范围。我们没有选择继续在这些限制上打补丁，而是借此机会重建了基础。回报是更为简洁的架构，以及一长串此前根本无法实现的功能，其中很多已经在社区愿望清单上躺了多年。 下面我们来看看亮点。 ## 全新 WebUI（https://stalw.art/blog/stalwart-0-16/#a-brand-new-webui） WebUI（https://github.com/stalwartlabs/webui）已完全重写。它拥有焕然一新的现代外观，并解决了多年来积压的 76 项增强请求和 bug 修复。如果你曾经觉得缺少什么功能，现在很可能已经有了。 Stalwart v0.16 WebUI 最受期待、也最重要的新增功能是：全新 WebUI 支持对接外部 OIDC 提供商进行身份验证。使用 Keycloak、Authentik、Authelia、Zitadel 或任何其他标准兼容的身份提供商登录，现在都已成为原生支持的一等流程，完整支持 audience 和 scope 校验、group claims，以及面向公共客户端的 PKCE（RFC 7636）。这是社区最频繁的诉求之一，如今终于实现。 ## 通过 JMAP 和全新 CLI 实现统一管理（https://stalw.art/blog/stalwart-0-16/#unified-management-via-jmap-and-a-new-cli） 在之前的版本中，Stalwart 通过与其原生 JMAP 接口并存的 REST API 进行管理。在 v0.16 中，REST API 已被移除。所有配置和管理操作现在都是 JMAP 对象，可通过已为邮件、日历、通讯录和文件提供服务的同一个 `/jmap` 端点访问。 这次改动带来的好处再怎么强调都不为过。JMAP（RFC 8620）是一项规范完善、传输高效的协议，原生支持批量操作、推送通知和细粒度变更追踪。在实践中，这意味着数十项配置变更可以在一次往返中完成，任何 JMAP 客户端库都可以驱动管理界面，单一的认证流程即可同时覆盖邮件访问和管理。将配置以 JMAP 对象的形式集中在数据存储中，还消除了一整类运维困惑：不再有“文件中的配置”与“数据库中的配置”之分，并且在集群部署中，配置在所有节点上天然保持一致。 与 WebUI 一起，我们还推出了全新的 CLI（https://github.com/stalwartlabs/cli）。新的 `stalwart-cli` 构建在相同的 JMAP 管理 API 之上，可以配置和管理 Stalwart 的方方面面。它专为日常管理、脚本化部署和基础设施即代码（Infrastructure-as-Code）工作流而设计。`stalwart-cli apply` 子命令接收一份声明式计划文件，并以幂等方式调和线上服务器状态以匹配该计划：创建缺失的、更新变更的、移除计划中不再声明的。这自然契合 Ansible、Terraform、NixOS 及类似工具，并遵循 CockroachDB、Consul、Elasticsearch 和 HashiCorp Vault 等项目的相同模式——即基础设施即代码工具直接面向 API，而非配置文件。 新的 CLI 对于 AI Agent 来说也是一个非常友好的交互界面。由于每一项操作都映射到一个具有清晰 schema 的、定义良好的 JMAP 对象，Agent 可以自主发现能力、规划变更并以幂等方式应用，无需任何定制化的集成工作。 ## 自动化 DNS 管理（https://stalw.art/blog/stalwart-0-16/#automated-dns-management） 在之前的版本中，Stalwart 仅管理 ACME DNS-01 挑战所需的 `TXT` 记录。在 v0.16 中，它可以处理现代邮件与协作服务器所需的每一种 DNS 记录：`MX`、`TXT`、`CNAME`、`SRV`、`CAA` 和 `TLSA`。服务器会自动计算你的部署应当发布的记录，并与 DNS 提供商保持同步。 这开箱即用就覆盖了认证和发现的大部分场景。SPF、DKIM 和 DMARC 记录与 autoconfig 和 autodiscover 的 `SRV` 记录一同管理，还包括用于证书签发授权的 `CAA` 记录（含支持账户级签发的 `accounturi` 参数），以及用于 DANE 的 `TLSA` 记录。当 ACME 证书续期时，`TLSA` 记录会自动刷新，因此启用 DANE 的域名在证书轮换期间不再面临验证断档的风险。 在提供商侧，v0.16 内置支持 Route53、Google Cloud DNS、Bunny、Porkbun、DNSimple 和 Spaceship，同时支持使用 `SIG(0)` 签名的 RFC 2136 动态更新，方便运行自有权威 DNS 的运维人员使用。 ## 自动化 DKIM 轮换（https://stalw.art/blog/stalwart-0-16/#automated-dkim-rotation） DKIM 密钥轮换是所有人都知道应该做、却几乎没人真正去做的事情之一，因为它繁琐且容易出错。在 v0.16 中，Stalwart 接管了整个流程。它可以自动生成 DKIM 密钥、按计划轮换，并通过新的 DNS 管理层发布匹配的 `TXT` 记录，确保已发布的密钥始终与服务器用于签名的密钥保持一致。DKIM 密钥现在与其余配置一起存储在数据库中，这意味着在集群部署中轮换可以自然运作，无需任何手动协调。 ## 掩码邮箱（Masked Emails）（https://stalw.art/blog/stalwart-0-16/#masked-emails） 掩码邮箱（Masked Emails）是一次性的、按服务区分的邮箱地址，邮件会被路由到用户的真实收件箱。用户无需把主邮箱交给每个新闻通讯、网店或论坛，而是可以为每个服务生成一个唯一的掩码地址。如果某个服务泄露了数据库或开始发送垃圾邮件，对应的掩码地址可以单独禁用，不会影响其他服务，也无需触碰用户的真实地址。这是当今最有效的隐私工具之一，并且与 Stalwart 的目录其余部分无缝集成。 此功能属于企业版（Enterprise edition）。 ## 安全增强（https://stalw.art/blog/stalwart-0-16/#security-enhancements） v0.16 对安全性进行了重大升级。用户密码现在可以在设置时通过 `zxcvbn` 强度估算器进行检查，从根本上杜绝弱凭证进入系统。密码还可以设置明确的过期和轮换策略，用户账户也可以限制在特定 IP 范围内，使得账户只能从预期的网络中使用。 应用密码（App passwords）和 API 密钥也得到了同等甚至更进一步的加强。两者现在都可以限定在特定的权限集范围内，而不是继承所属账户的全部权限，这意味着单个 IMAP 客户端或单个自动化脚本使用的令牌可以被精确限制在所需的最小权限。两者还支持人类可读的标签、过期日期和 IP 地址限制，因此长期凭证可以被审计、轮换和限制，而无需完全撤销。 总而言之，这些功能让 Stalwart 部署的凭证面变得更容易理解和加固。 ## 其他亮点（https://stalw.art/blog/stalwart-0-16/#other-highlights） 还有许多其他新增功能值得一提。在账户配置方面，v0.16 实现了新的《邮件、日历和通讯录服务器设置自动配置》草案（https://datatracker.ietf.org/doc/html/draft-eggert-mailmaint-uaautoconf-04），该草案有望取代目前客户端使用的碎片化的 autoconfig 和 autodiscover 机制，同时增加了对仍然依赖该机制的环境的 MS Autodiscover V2 支持。 目录层增加了域名别名、别名描述、无需删除即可禁用别名的能力；企业版还支持账户归档与恢复、以及按域的目录后端。ACME 层新增了 `DNS-PERSIST-01` 挑战、按需证书续期和证书详情视图。Sieve 脚本现在可以在不删除的情况下停用。集群管理更加清晰，支持自动节点 ID 生成、统一的集群管理，以及面向专用队列节点的新出站 MTA 角色。 除此之外，目录、MTA、JMAP、IMAP、WebDAV、CalDAV、OIDC 和存储后端等模块还修复了数十个 bug。如果你一直在关注某个问题，很可能已在 v0.16 中得到解决。 ## 升级指南（https://stalw.art/blog/stalwart-0-16/#upgrading） 由于架构变更的范围，v0.16 是一次**包含多项破坏性变更的重大升级**。在没有完整阅读升级文档（https://github.com/stalwartlabs/stalwart/blob/main/UPGRADING/v0_16.md）之前，请勿直接升级生产环境。我们还强烈建议先在容器或一次性虚拟机中启动一个全新的 v0.16 实例，熟悉新的 WebUI 和 CLI，然后将你在那里构建的任何设置导出为 `apply` 计划，以便在迁移后回放应用到生产环境。 如果在升级过程中遇到任何问题，欢迎前往专门的 v0.16 升级讨论帖：https://github.com/stalwartlabs/stalwart/discussions/3004。我们会密切关注。 这个版本的开发历时三个多月，代表了 Stalwart 历史上最大的一次单步跨越。感谢所有提交 bug、贡献代码、测试预发布版本并在 issue 和讨论中保持交流的每一个人：v0.16 在很大程度上也是属于你们的版本。我们迫不及待想听到你们用它构建出什么。