摘要

  • RFC 5233 为 Sieve 地址比较增加了 :user 和 :detail，但没有统一规定某个分隔符，也没有建立通用的“加号地址”格式。
  • 本地编码仍由收件邮件系统掌握；在某些投递路径中，信封 to 保留了可见邮件头中没有的收件人细节。

加号是本地写法，解释边界才是标准的一部分

地址中的附加细节可以把邮件放进特定文件夹、标识列表订阅，或区分语音邮箱。加号是常见示例之一，却不是唯一方式。2008 年 1 月发布的 RFC 5233 为 Sieve 增加了 :user 与 :detail 两种地址部分，方便过滤器进行比较；它描述的是可比较的部分，而不是全网统一的地址语法。

地址的本地部分由接收邮件系统解释。RFC 5233 画出两种布局：详细信息跟在用户部分后面，例如 +；也可以放在前面，例如 。如果分隔符序列在本地部分出现多次，如何切分由实现决定，通常取决于所在邮件系统的格式。实现必须与该系统使用或允许的编码方法一致；如何定义或查询这种方法，则不在 RFC 的范围内。因此，某家服务商把 + 当作细节边界，并不意味着其他系统也必须如此。

若地址没有编码出详细信息，:user 就表示整个本地部分，相当于 Sieve 的 :localpart。此时 :detail 不会匹配所请求的键。若详细部分存在但长度为零，它的值则是空字符串。规范区分了“没有这个部分”和“这个部分存在但为空”。

RFC 5233 还区分地址来自哪里。address 测试读取结构化邮件头；可选的 envelope 测试读取传输信封。若规则要按邮件如何抵达某个特定收件人来分类，规范在多数情况下建议使用信封 to。邮件列表、别名和虚拟域可能使信封成为唯一保留该收件人细节的位置。若把本地格式套用到外部地址，例如发件人地址，结果可能不一致或错误。

RFC 5233 取代了 RFC 3598 的早期文字；修订说明将编码方法改为通用表述，并补入关于信封与外部地址的提示。IANA 注册了 subaddress 能力名，但注册名称并不保证每个邮件系统都接受某种标记地址。Sieve 可以比较邮件系统提供的本地解释，却不能替系统定义解释方式，也无法据此证明邮箱如何创建或配置。

来源