摘要

  • RFC 6154 于 2011 年 3 月定义可选的 IMAP 特殊用途属性。服务器可在 LIST 回复里为邮箱标上 \Sent、\Drafts、\Trash 等角色，让客户端不靠显示名称猜用途。
  • \Sent 可能意味着服务器自动保存已发邮件，也可能只是告诉客户端应该把副本存到这里。同一邮箱可带多个属性，多个邮箱也可能共用一个属性。
  • 扩展 LIST 可声明 SPECIAL-USE 能力；可选的 CREATE USE 和 METADATA 机制让客户端请求或修改角色，服务器有权拒绝无法支持的配置。IANA 邮箱属性登记表协调这些标记的名称。

文件夹名称不是协议

同一个邮箱账户装在两台设备上，一台把已发副本存进“Sent Mail”，另一台没认出这个名字，又建了一个“已发送”。用户随后要在两个地方拼凑自己写过的邮件。也可能两台都以为服务器会自动归档，而服务器正等客户端来存。表面上是设置麻烦，实际丢失的是一份可追溯的通信记录。

1999 年的 IMAP 实施建议已经谈到“Sent Mail”“Trash”等惯用名称。惯例对人有帮助，对程序却太松。服务器可以另取名称，用户可以重命名，文件夹也可能在保留名称的同时改变用途。客户端拿一串展示给人的文字推断存储行为，等于把配置协议写成猜谜。

RFC 6154把用途放进服务器的 LIST 回复。它最初列出七种标记：\All、\Archive、\Drafts、\Flagged、\Junk、\Sent、\Trash。服务器可以让这些标记与邮箱的其他属性一起返回。文件夹可以继续叫用户熟悉的任何名字；客户端找的是协议里的角色，而不是在不同语言里辨认“已发送”的拼写。

这是一次很小的责任重新分配。刚接入的客户端不知道服务器如何布置邮箱，服务器知道自己给哪些邮箱安排了哪些用途。让服务器作出声明，客户端便不用逼用户充当翻译器。声明本身不是替用户选工作流；它先把服务器掌握的布局信息交出来。

\Sent 标记不会替你存信

RFC 6154 对 \Sent 给出两种情形：有的服务器自动把已发邮件副本放进去，有的服务器仅建议客户端在这里保存。客户端若等着后一种服务器替它归档，文件夹会空着；若遇到前一种服务器又自行存一份，用户可能看到重复邮件。标记帮助找到约定位置，却没有替双方决定由谁执行动作。

其他角色也保留实际差异。\All 往往是虚拟视图，还可能排除 \Trash 和 \Junk 中的邮件。\Archive 的归档含义由服务器界定。\Drafts 可以是聚合带草稿标志邮件的虚拟邮箱，也可以只是客户端应当存草稿的目的地。\Trash 可能体现服务器的删除模型，或成为不直接使用 IMAP \Deleted 标志的客户端的废纸篓。统一的名字让客户端能发问，没有把所有服务器改造成同一台机器。

数量也没有统一答案。一个邮箱可以没有特殊标记，可以有一项，也可以有多项；同一个 \Sent 还可能出现在多个邮箱上。角色通常跟用户有关：两人共享一个物理邮箱，不代表它同时是两人的已发送邮箱。把标准属性读成“全账户必有唯一文件夹”，只是给老猜测套上一件新制服。

IANA 的 IMAP 邮箱属性表保存这些名称和规范来源。它让不同客户端知道 Sent 是同一个角色词汇，却不会记录某封邮件到底是谁放进哪只文件夹。登记表负责语义字典，运行中的邮箱负责事实。

发现、请求、拒绝是三件事

该扩展借用了扩展 LIST 框架。支持扩展用法的服务器在 CAPABILITY 中声明 SPECIAL-USE。客户端可要求只列出有特殊用途的邮箱，也可要求列表带上属性；前一种选择已隐含后一种返回。普通 LIST 回复也可以直接带这些属性，而普通用法没有单独的能力字符串。只盯着一行能力列表，可能看漏实际返回的角色。

RFC 6154 还给 CREATE 增加可选的 USE 参数。客户端想新建带某种角色的邮箱，得看服务器是否另行声明 CREATE-SPECIAL-USE。服务器可以拒绝冲突，可以把旧邮箱的角色移给新邮箱，也可以允许同一角色出现多次。若它无法按所请求角色创建邮箱，必须拒绝整个创建请求，不留下一个“建好了但角色没配上”的半成品。

支持 IMAP METADATA 的服务器可使用 /private/specialuse 保存现有邮箱的角色，并可允许客户端修改。修改要经过服务器校验；不能把不支持的角色或不接受的重复配置照单全收。改显示名称、改角色、搬动邮件，各有不同的请求和回执。

角色甚至可能触发自动动作。RFC 6154 举了 \Junk 的安全例子：若服务器把判为垃圾的邮件自动投进该邮箱，而用户把这个角色指定给共享邮箱，误判的正常邮件就可能暴露给别人。标记不只是图标；当服务器依标记行动时，它是配置杠杆，服务器必须决定允许谁扳动。

规范说明角色如何声明和申请，却不能说明某个具体账户的一封信最后落在哪里。需要有日期的 CAPABILITY/LIST 回复、任何 CREATE 或 METADATA 变更，以及邮件副本的实际去向。文件夹门牌是最弱的证据。