邮箱命名的规则

我不是女神ヾ 2022-02-25 20:12 342阅读 0赞

最近用到邮件相关协议，现总结邮箱名命名规则如下：  
邮箱名是7-bit的。客户端实现体不能试图创建8-bit的邮箱名，应当把LIST或者LSUB返回的任意8-bit邮箱名解释为UTF-8。服务器实现体应当禁止8-bit邮箱名的创建，LIST或者LSUB不应当返回8-bit的邮箱名。  
注意：8-bit的邮箱名在本协议的早期版本中并未定义。一些站点使用 一个本地的8-bit字符序列表示非ASCII邮箱名。这种用法是不能有效沟通的，现在而言也是不正规的。  
不区分大小写的邮箱名INBOX是一个特殊的邮箱名，它被保留下来，表示“该服务器上该用户的主邮箱”。所有其它邮箱名的解释都是依赖于实现体的。

特别的，本文档未指定是否区分非INBOX邮箱名的大小写。一些服务器实现体全部区分大小写；一些服务器实现体保留新创建的邮箱名的大小写状态，而其它的则是不区分大小写的；还有一些服务器实现体则强制命名为特定形式。客户端实现体必须与其中的任何一种做好交互。如果一个服务器实现体把非 INBOX邮箱名解释为不区分大小写的，则它必须特别使用5.1.3一节中所描述的国际命名约定。

创建一个新的邮箱名，有一些客户端的考虑：  
1）原语类（参见正式语法一节）的任意一个字符要求邮箱名表述为一个引用字 符串或者原义字符串。  
2）CTL和其它生僻字符很难表述在用户界面，所以最好避免。  
3）虽然通配符列表字符（“%”和“\*”）在邮箱名中是正确的，所以很难把LIST 和LSUB命令用于这样的邮箱名,因他们与通配符的解释相冲突。  
4）通常，保留一个字符（取决于服务器实现体）用于层级分隔。  
5）“\#”和“&”这两个字符有约定语上的意义，应当避免以其它意义使用它。  
1、 邮箱层级命名  
如果需要输出分层的邮箱名，邮箱名必须是从左到右的层级，并使用一个字符分隔不同层级。在一个邮箱名中，所有层级的分层使用同一个层级分隔字符表示。  
2、 邮箱命名空间的约定  
按照约定，任何邮箱名的第一个分层元素以“\#”开头，它标识剩余名称的名称空间。这使得消除具有各自名称空间的、不同类型的邮箱存储间的含糊意义成为可能。  
例如，提供访问USENET网络组的实现体可以使用“\#news”名称空间把USENET网络组的名称空间与其它邮箱的网络组名称空间分割开 来。Comp.mail.misc网络组可能有一个“\#news.comp.mail.misc”的邮箱名，而邮箱名“comp.mail.misc”可以指向一个不同的对象（如，一个用户的本地邮箱）。  
3、邮箱的国际命名约定  
按照约定，IMAP4rev1的国际邮箱名用“UTF-7”中所描述的UTF-7编码的修订版本描述。在执行本协议的一个早期版本的服务器上，修订版UTF-7同样是可以用的。  
在修订版UTF-7中，除“&”外的US-ASCII打印字符都可以表示邮箱名；即八进制值为0×20-0×25和0×27-0×7e的字符。字符“&”（0×26）表示成两个八进制串“&-”。  
所有其它字符（八进制值为0×00-0×1f和0×7f-0xff）表示成修订版BASE64,它具有“UTF-7”之后的一个修订――“，”替代“/”使用。修订版BASE64不能用来表示任何可以表示自身的US-ASCII打印字符。  
“&”用来转换至修订版BASE64,“-”用来转换回US-ASCII。不存在从BASE64至US-ASCII的隐式转换，且无效 转换（BASE64下的“-&”；注意，US-ASCII下的“&-”意为“&”）也是不允许的；就是说，一个以非 ASCII ISO-10646字符结尾的邮箱名必须以一个“-”结尾。

这些修订是为了修正与UTF-7的以下错误：  
1）UTF-7使用“+”字符实现转换；这跟邮箱名称中的“+”，特别是USENET 网络组名称的一般用法相冲突。  
2）UTF-7的编码是BASE64，它使用“/”字符；这跟“/”作为层级分隔符 的普遍用法相冲突。  
3）UTF-7禁止“/”的未编码使用；这跟“/”作为层级分隔符的普遍用法相 冲突。  
4）UTF-7禁止“”的未编码合用；这跟一些服务器将“”作为根目录标记 的用法相冲突。  
5）UTF-7允许选择多种形式表示同样的字符串；特别的，US-ASCII打印字 符可以表示成编码后的形式。

虽然修订版UTF-7是一个约定，它在服务器建立了用一个嵌入的“&”字符处理任意邮箱名的一些请求。特别的，服务器实现体必须保留一 个修订版UTF-7名称的修订版BASE64部分的准确形式，并把这些文本视为区分大小写的，即使邮箱名是不区分大小写的或者部分区分大小写、部分不区分 大小写的。

服务器实现体应当用一个嵌入的“&”字符――用作CREATE的一个变量，检验任意邮箱名：正确修订版UTF-7语法中，不含有多余的 转换符，也不含有可表示自身的任意US-ASCII打印字符的修订版BASE64编码。但是，客户端实现体不能依赖服务器做这个，也不应当试图用一个嵌入 的“&”字符创建一个邮箱名，除非它用修订版UTF-7的语法编译。

不遵照修订版UTF-7约定、输出一个邮件存储的服务器实现体必须转换成修订版UTF-7的、含有非ASCII字符或者“&”字符的任意邮箱名。

例如，这是一个混合有英文、中文和日文文本的邮箱名：  
~peter/mail/&U,BTFw-/&ZeVnLIqe-

例如，字符串“&Jjo!”不是一个正确的邮箱名，因为它的“！”前没有至US-ASCII的转换符。正确的形式是 “&Jjo!-”。字符串“&U,BTFw-&ZeVnLIqe-”是不允许的，因为它含有多余的转换符。正确的形式是 “&U,BTF2XlZyyKng-”。

在此推荐一款邮件透明加密产品：天御云安的隐密邮很新颖，使用安全邮件网关对邮件透明加密，用户完全感知不到邮件网关的存在，但是邮件在服务器上却穿上了盔甲，任你黑客攻破服务器，看到的邮件却是一堆乱码。