2026 年 5 月发布的 RFC 9979 将 $maskedemail 定义为提示邮件经由针对特定联系人的隐藏地址收到的关键词。结论很直接：客户端应把它当作服务端提供的收件线索，分别验收服务器支持情况、标记有无和界面表现；不能据此自动停用别名、认定发件人可信，或承诺匿名与绝对隐私。
这篇文章适合维护 IMAP／JMAP 客户端与收件系统的开发者，以及负责邮件功能验收的 QA 人员。
长期管理多个邮箱别名的用户也可以据此判断：标记能说明什么，又有哪些事情仍需在邮件服务本身确认。
最后更新于 2026 年 11 月 13 日；标准状态与标记定义核对自 RFC 9979 原文及 IANA 关键词登记表。
开发者：先把标记定义和界面职责分开
RFC 9979 是信息类文档，并非互联网标准轨道规范。它定义 $maskedemail 的含义，并把它登记为 IMAP 与 JMAP 共用的提示性关键词；具体含义是邮件经由为某个发件人或联系人设立的别名收到。RFC 原文的状态说明与标记定义和 IANA 登记表都可用于复核这条边界。
对客户端而言，关键不是“看到别名就必须弹窗”，而是能读取关键词时，能否准确解释它。RFC 说支持该关键词的客户端可以为邮件提供提示，例如掩码图标；这是可选的客户端体验，不是统一界面规范。把图标、筛选或别名管理入口写成 RFC 强制行为，会把产品选择误报成协议要求。
开发实现时，可以把这几项分别验收：
- 关键词识别：读取消息属性时，能区分
$maskedemail与普通地址文本。 - 提示呈现：有标记时，提示只说明邮件经由别名收到，不暗示别名已泄露或来信已通过安全认证。
- 操作分层：若产品支持查看或停用别名，核实这项操作是否由服务端另行提供；标记自身并不创建、启用或停用地址。
- 协议语义：IMAP 与 JMAP 都有关键词机制，但各自读取和呈现消息属性的方式不同，不能只测其中一条路径就宣称两种协议都兼容。RFC 9051 的 IMAP 标志与关键词说明和 RFC 8621 的 JMAP Email keywords 属性适合作为协议层对照。
服务端：在投递里程碑核实标记生成
RFC 对这项关键词的定义不止是“邮件有别名”：登记说明标记由服务器在投递时设置。服务端团队应沿着别名匹配 → 邮件投递 → 消息属性持久化 → 客户端读取这条链检查，而不是让客户端从收件人地址长相自行猜测。
测试报告要区分三种状态：已在指定环境观察到标记；已确认该环境支持，但本次样本没有标记；当前环境支持情况未知。第三种不等于实现缺陷，更不能从一个测试服务器的结果推断其他服务器也会生成标记。IANA 将该关键词登记为适用于 IMAP 与 JMAP、用途有限；登记本身也不能代替逐个服务端产品的实现核验。
协议观察点也要分清：
- IMAP 邮箱别名：检查选中邮箱返回的标志和邮件获取结果，确认
$maskedemail是否出现在关键词集合中。IMAP 服务器对关键词的持久化能力受邮箱状态和服务器实现影响；RFC 9051 对PERMANENTFLAGS的说明可帮助排查“客户端读不到”与“服务器不持久化”的差别。 - JMAP 邮箱别名：读取 Email 对象的
keywords属性，并确认键值对应测试邮件。JMAP 的keywords是消息属性集合，与 IMAP 的关键词语义有关联，但客户端仍须按 JMAP 的对象格式读取；RFC 8621 描述了这套属性结构。 - 登记核对：RFC 5788 建立的关键词登记机制后来扩展到 JMAP；RFC 5788 的文档说明和 IANA 当前登记信息可用于核对名称及适用范围，不能用来证明某个具体服务器已部署。
QA：按输入状态拆开验收
QA 不应只拿一封“带图标”的邮件做演示。最低限度要准备带 $maskedemail 的测试邮件、不带该标记但实际投递到别名的邮件，以及普通地址来信；对每封样本同时记录协议响应、测试地址、邮件原始信息和界面结果。这样才能看出客户端是正确处理缺失标记，还是把别名地址、发件人地址和标记状态混为一谈。
| 测试输入 | 协议／服务端核对 | 预期界面与判断 |
|---|---|---|
带 $maskedemail 的别名来信 |
确认测试服务器确实返回关键词，并与测试地址及原始邮件对应 | 可显示别名收件提示；不得把它呈现成发件人认证或安全保证 |
| 不带标记的别名来信 | 记录服务器支持状态；确认邮件本身是否正常到达 | 不应伪造标记提示；先标记为支持情况待查，不直接判定地址失效 |
| 普通地址来信 | 核对关键词确实缺失，避免复用上一条测试结果 | 按普通邮件呈现，不出现别名提示 |
| 有停用入口的界面 | 单独检查入口调用的服务端能力和操作结果 | 不得把“显示标记”当成“地址可停用”的证据 |
这张表的判断重点是分开报告：客户端读取是否正确、服务端是否提供标记、邮件是否实际收到，是三个独立结果。缺少 $maskedemail 时，如果来信正常到达，测试记录应写“当前样本未观察到标记，服务端支持情况待确认”，而不是把它记为地址失效。
产品与维护团队：按发布里程碑留验收记录
产品文案可以说“此邮件经由别名收到”，但不能把提示扩大成“该地址已泄露”“发件人已验证”或“邮件绝对匿名”。RFC 描述了隐私增强用途，并举出客户端可提供提示、甚至可关联停用别名的可能体验；这不等于所有服务端都提供停用操作，也不等于每个客户端都必须显示相同控件。
建议在每次兼容验收中记录：客户端版本与协议、服务器及测试环境、服务器支持状态、测试邮件是否含标记、读取到的消息属性、界面呈现、关联操作是否真实可用。报告中再把内容分成三栏：RFC 定义、产品实测行为、团队建议。这样当服务端或客户端实现变化后，可以定位变化发生在哪一层，而不是只凭“图标还在不在”判断兼容。
对长期收件用户来说，$maskedemail 有助于识别某封邮件是否经由别名到达，但不会替代别名服务的有效期、转发规则或停用能力核验。关于临时地址与长期别名各自适合什么用途，可以先看一次性邮箱与邮箱别名的区别；如需逐项检查长期别名的退出与停用事项，可参考邮箱别名退出检查清单。
如果目标只是临时注册、试用或收一次验证码，InboxCloak 的临时收件箱页面说明无需注册即可使用；这与 RFC 9979 标记是否受支持是两回事，也不应被当作 IMAP／JMAP 兼容性测试结果。(inboxcloak.com)
常见问题
RFC 9979 里的 $maskedemail 是什么？
它是附着在邮件上的提示性关键词，用来表示这封邮件经由针对特定联系人的隐藏地址或别名收到。它不创建地址、不认证发件人，也不证明邮件绝对安全；显示什么提示由客户端产品设计决定。
邮件客户端必须显示 $maskedemail 图标吗？
不必。RFC 9979 说明支持该关键词的客户端可以提供提示，例如图标，但没有规定所有客户端都必须显示同一种标记或采用统一界面。产品可以选择显示文字、图标或不单独呈现，但不应把可选体验描述为标准强制要求。
服务器没提供 $maskedemail，就代表别名不能收信吗？
不能这样判断。标记由服务器在投递时设置，而实际部署支持情况可能不同；没有看到标记，只能说明当前测试路径没有观察到它。先核对服务器支持声明、协议读取结果和测试地址，再单独检查邮件是否正常送达。
怎么验收 IMAP 或 JMAP 的邮箱别名标记？
使用已知会设置标记的测试环境，分别准备带标记邮件、普通邮件和不带标记的别名来信；对照 IMAP 关键词或 JMAP Email 的 keywords，再核对客户端显示、原始邮件和测试地址。把服务器是否支持与客户端是否正确呈现分开记录。