Feature License zh

English · Tiếng Việt · 中文

Plan and license（方案与授权）

从 1.6.0 起，SkimMail 在 Community 层级可以永久免费自托管，只有少量按实 例计算的限制，并且可以通过一个离线的、已签名的 license key 解锁更高层级—— 没有授权服务器，应用它时不需要联网，SkimMail 这边也不需要任何账号。

解决什么问题

想要自我造血的自托管软件通常会在两个不讨喜的选项里选一个：把免费层级砍到几 乎不能用，或者要求一个正在运行的授权服务器——这会把一个自托管产品变成又一 个可能宕机、把你锁在自己邮件之外的东西。SkimMail 的 entitlement 系统两者都 不是：Community Edition 是一个完整、真正能用的邮箱阅读器，限制对一个人来说 足够宽松；而一个能解锁更多功能的 key，是一个已签名的离线令牌，你粘贴一次即 可——用二进制里早已内置的密码学来验证，在应用的那一刻，从不会向远程服务器 再次核实。

位置

Settings ▸ Plan & License，仅所有者。

三个层级

资源	Community	Sponsor	Pro
账户	10	25	无限制
Connections（出口代理/隧道）	3	5	无限制
Groups	2	5	无限制
存储	5 GB（仅展示——见下文）	15 GB（仅展示）	无限制
登录数（AUTH_MODE=users）	1	3	无限制

只要没有应用 license，或者已应用的 license 过期或被吊销，Community 就是回 落的默认值。Sponsor 的 3 个登录名额是让 owner/operator/viewer 角色模型（见 用户与角色）真正有意义的最小数字——Community 的其他数 字描述的是一个人的正经配置，而不是一个团队。

这些限制是按实例计算的，不是按用户计算的。 按用户计算会让任何人通过再 创建一个登录账号来突破 Community 的 10 账户上限；这里每一个用量条背后的计 数查询都是有意不按用户过滤、覆盖整个数据库的。

应用一个 key

粘贴 license 文本，或者拖入它自带的文件，然后保存。一个 key 是一个紧凑的两 段式令牌——一段 JSON payload 和一段 Ed25519 签名，都用 base64url 编码，中间 用 . 连接——对照构建时就烧录进二进制的公钥进行验证。应用它时不会向任何地 方发送任何东西：整个检查在本地完成，所以它在隔离网络的实例上和联网实例上工 作得一样好。

签名错误或缺失的 key 会被直接拒绝（什么都不会被保存），界面会提示它无效。 一个能通过验证但已经过期的 key 仍然会被保存并显示出来——它的层级、被授 权人名字和日期都会为了透明而显示——与此同时，生效中的每一项限制都会完全回 落到 Community，直到你应用一个当前有效的 key。替换一个已有的 key，或者彻底 移除它回到 Community，在这个界面上都只需要一次点击。

key 过期或被吊销时会发生什么

Entitlement 只在创建时把关——从不影响恢复，也从不影响读取。 如果你有 22 个已配置的账户，此时一个 Sponsor key 失效了，这些账户不会有任何一个消 失、停止同步，或变成只读：全部 22 个都会照常工作。改变的只是你无法再新 增第 23 个账户、connection 或 group，除非续期这个 key，或者删到 Community 的上限以下。同样的思路也解释了为什么存储从不被强制执行——见下 文。

界面把过期和被吊销当作相关但不同的两件事来处理：一个被吊销的 key （它的 id 出现在 SkimMail 已签名的吊销名单上）会被标记为「被吊销」而不是仅 仅「过期」，这样你就知道应该去问 license 本身出了什么问题，而不是以为自己 的订阅只是自然到期了。

吊销机制，以及它如何在不需要联网的情况下仍然可信

每一个 SkimMail 构建都自带一份烧录好的被吊销 license id 基线，单凭这一点就 足以让一个离线实例永远正常工作。在此之上，一个已经选择开启周期性自更新检查 （见运维）的实例，会在同一个周期里顺带拉取最新的已签名吊 销名单——绝不会为此单独制造一个新的网络依赖——并且只有在拉取到的名单严格新 于当前缓存的名单时才会接受它，这是专门为了阻止网络攻击者永远重放一份旧的、 但签名确实真实的名单，来隐藏一次你本该得知的吊销事件。这里任何一种失败——离 线、关闭了更新检查、签名错误——都会被静默吞掉，只留下烧录好的基线作为底线； 它从不会阻塞产品里的任何其他东西。

什么真正被强制执行，什么只是提示

上面那四个数字并不是以同样的方式被执行的：

• 账户、connection 和 group 会在你试图再新增一个的那一刻被检查——添加 一个 IMAP 或 OAuth 账户、添加一个出口代理/隧道、或添加一个 group，一旦你 已经达到该层级的上限，都会以「limit reached」被拒绝。
• 登录数用同样的方式检查，但只从 skimmail user add 这个 CLI 命令触发 （见用户与角色）——产品里没有自助的「创建用户」界 面需要在 UI 层把关。
• 存储从不被强制执行，这是刻意的。 显示的数字是对你数据目录做的一次真 实的 filepath.Walk，每次打开这个界面都会重新计算，但它只用于展示： SkimMail 里没有任何东西会因为你超过了某个存储数字而拒绝一次写入——无论是 一次邮件同步保存附件，还是缓存一段正文。相比之下，「邮箱因为设置页面上的 一个数字而不再接收新邮件」被认为是更糟的结果，所以宁可用一个诚实但不强制 的仪表。

限制

起始版本	1.6.0
角色	所有者
层级	Community · Sponsor · Pro
执行点	创建账户/connection/group 时，以及 skimmail user add；从不作用于存储
应用 key 是否需要联网	否
检查吊销是否需要联网	否——best-effort，顺带在可选的更新检查里进行

它不做什么

• 不限制任何内容。 邮件数量、邮箱大小、缓存正文大小都不受层级影响——受 影响的只有你能创建的账户、connection 和 group 数量，以及能有多少人登录。
• 应用或验证一个 key 都不需要联网。 签名检查完全在本地完成；只有可选 的吊销名单刷新才会发起网络请求，而且它从不会阻塞应用或使用一个 key。
• 验证密钥无法用环境变量覆盖，这一点和自更新密钥（UPDATE_PUBKEY）不 同。它被有意设计为一个构建时常量——如果允许用环境变量覆盖，任何人都能生 成自己的密钥对，用两条命令自签一份「无限制」license，从而让整个系统失效。
• 无法恢复被某个限制挡住的东西。 删到 Community 上限以下是手动操作；而 且根据「用户与角色」一页所说，在 1 个名额的限制下删错用户可能会是一个真 正的死结；CLI 提供了 --reassign-to 选项正是为了应对这种情况。

另请参阅

• 用户与角色 —— 登录数限制、skimmail user CLI，以 及 Community 1 个名额的实例在删除用户时意味着什么
• 运维 —— 吊销名单刷新所搭乘的那个可选更新检查
• LICENSE / COMMERCIAL-TERMS.md（位于仓库中）—— 各层级背后的法律条款； 这一页只描述软件的行为方式

---

SkimMail · skimmail@base101.app · 2026-09-15 · commit dffbb18