//
+——————————-+
|both sides close the connection| +——————————-+
（1）未预认证的连接（OK欢迎） （2）预认证的连接（PREAUTH欢迎） （3）被拒绝的连接（BYE欢迎）
（4）成功LOGIN或者AUTHENTICATE命令 （5）成功的SELECT或者EXAMINE命令
（6）CLOSE命令，或者失败的SELECT、EXAMINE命令 （7）LOGOUT命令，服务器关闭，或者连接已关闭
4. 数据格式
IMAP4rev1使用文本型的命令和响应。IMAP4rev1中的数据可以是很多形式中的一种：原语、数字、字符串、圆括符列表、或者NIL。注意，一个特殊的数据项可能有几种形式；例如，使用“astring”语法定义的一个数据项可以是一个原语，或者一个字符串。
4.1. 原语
一个原语由一个以上普通字符组成。
4.2. 数字
一个数字由一个以上的数字字符组成，表示一个数值。
4.3. 字符串
一个字符串的两种形式：或者是原义字符串，或者是引用字符串。原义形式是普遍的字符串形式。处理原义字符串时，存在字符空间限制情况，为避免空间过载，就可以使用引用字符串。
一个原义字符串是一连串的0或者更多的字节数（包括CR和LF），左花括号形（“{”），字节数的长度，右花括号（“}”），和CRLF。如果 是从服务器发送至客户端的原义字符串，CRLF是紧跟在字节数据后的。如果是从客户端发送至服务器的原义字符串，在发送字节数据（和其余命令）前，客户端 必须等待接收一个连续请求命令（稍后讲述）。
一个引用字符串是一连串的0或者更多的7位字符，除CR和LF外，每个的后面都带有两个引用符（<”>）。 空字符串表示成“”（在两个双引号之间有0个字符的引用字符串），或者{0}，其后跟着CRLF（一个原义的空字符串表示成{0}）。
注意：即使字节数的长度为0,正在传送一个原义字符串的客户端也必须等待一个连续请求命令。
4.3.1. 字节及二进制字符串
通过使用[MIME-IMB]内容传输编码，就可以支持8位文本型的和二进制的邮件。IMAP4rev1实现体可以传送8位或者原义型的泛八进制字符，但只有当标识了[CHARSET]的时候才可以这样做。
虽然定义了一个二进制的主体编码，但是未编码的二进制字符串是不被接受的。一个“二进制字符串”是带有NUL字符的任意字符串。实现体必须在传送数据前，把二进制数据编码成文本形式，如BASE64。带有总数超量的CTL字符的字符串可能被认为是二进制。
4.4. 圆括符列表
表述为“圆括符列表”的数据结构；一连串的数据项，以空格为分隔，起始端和终止端带有圆括号。使用多级圆括符表示巢时，一个圆括符列表可以包含有其它的圆括符列表。
空列表表示成（）――一个没有成员的圆括符列表。
4.5. NIL
“NIL”，这是个特殊的形式，它表示字符串或者圆括符列表的数据项不存在，它与空字符串“”或者空圆括符列表是有区别的。
注意：NIL永不使用于带有任何原语形式的数据项。例如，一个“NIL”的邮箱名是一个邮箱名为NIL的邮箱，而不是一个不存在的邮箱名。这是 因为邮箱使用“astring”语法，它是原语型或者字符串型的。相对的，一个NIL地址名是一个不存在的个体名，因为地址名使用“nstring”语 法，它是NIL或者一个字符串，而永远不会是一个原语。
5. 操作的考虑
这里列出了下面的规则，以确保所有的IMAP4rev1实现体恰当有效的沟通。
5.1. 邮箱命名
邮箱名是7位的。客户端实现体不能试图创建8位的邮箱名，应当把LIST或者LSUB返回的任意8位邮箱名解释为UTF-8。服务器实现体应当 禁止8位邮箱名的创建，LIST或者LSUB不应当返回8位的邮箱名。关于如何表示非ASCII的邮箱名，更多信息请参看5.1.3一节。
注意：8位的邮箱名在本协议的早期版本中并未定义。一些站点使用一个本地的8位字符序列表示非ASCII邮箱名。这种用法是不能有效沟通的，现在而言也是不正规的。
不区分大小写的邮箱名INBOX是一个特殊的邮箱名，它被保留下来，表示“该服务器上该用户的主邮箱”。所有其它邮箱名的解释都是依赖于实现体的。 特别的，本文档未指定是否区分非INBOX邮箱名的大小写。一些服务器实现体全部区分大小写；一些服务器实现体保留新创建的邮箱名的大小写状 态，而其它的则是不区分大小写的；还有一些服务器实现体则强制命名为特定形式。客户端实现体必须与其中的任何一种做好交互。如果一个服务器实现体把非 INBOX邮箱名解释为不区分大小写的，则它必须特别使用5.1.3一节中所描述的国际命名约定。
创建一个新的邮箱名，有一些客户端的考虑：
1）原语类（参见正式语法一节）的任意一个字符要求邮箱名表述为一个引用字符串或者原义字符串。
2）CTL和其它生僻字符很难表述在用户界面，所以最好避免。
3）虽然通配符列表字符（“%”和“*”）在邮箱名中是正确的，但是因为与通配符的解释相冲突，所以很难把LIST和LSUB命令用于这样的邮箱名。 4）通常，保留一个字符（取决于服务器实现体）用于层级分隔。
5）“#”和“&”这两个字符有约定语上的意义，应当避免以其它意义使用它。
5.1.1. 邮箱层级命名
如果需要输出分层的邮箱名，邮箱名必须是从左到右的层级，并使用一个字符分隔不同层级。在一个邮箱名中，所有层级的分层使用同一个层级分隔字符表示。
5.1.2. 邮箱命名空间的约定
按照约定，任何邮箱名的第一个分层元素以“#”开头，它标识剩余名称的名称空间。这使得消除具有各自名称空间的、不同类型的邮箱存储间的含糊意义成为可能。
例如，提供访问USENET网络组的实现体可以使用“#news”名称空间把USENET网络组的名称空间与其它邮箱的网络组名称空间分割开 来。Comp.mail.misc网络组可能有一个“#news.comp.mail.misc”的邮箱名，而邮箱名
“comp.mail.misc”可 以指向一个不同的对象（如，一个用户的本地邮箱）。
5.1.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-”。
5.2. 邮箱大小和邮件状态更新
任何时候，服务器可以发送客户端未请求的数据。有时，这种行为是有必要的。例如，代理而不是服务器，可能向邮箱中增加邮件（比如，新邮件发 送），改变了邮箱中的邮件标记（比如，多个代理同时访问同一个邮箱），或者从邮箱中
删除邮件。在处理一个命令的过程中，如果发现一个邮箱大小改变了，服务 器必须自动发送邮箱大小的新信息。服务器应当自动发送邮件标记的新信息，而无需客户端明确请求这些新信息。
关于邮件的删除，客户端的服务器通告存在着特殊规则，以防止同步错误；更多细节参见EXPUNGE响应的描述。特别的，发送一个可能减小邮箱中邮件数量的EXISTS响应，这是不允许的；只有EXPUNGE响应可以这样做。 在记忆服务器数据方面，无论什么样的实现体，客户端实现体必须记忆邮箱大小的新信息。不能假定初始选中邮箱后的的任何命令都返回邮箱的大小。
5.3. 没有命令在行进中的响应
当没有命令在行进中时，不允许服务器实现体发送一个非标签化响应（EXPUNGE除外）。发送这些响应的服务器实现体必须处理流控制。特别的，它们必须：（1）确保数据大小不超过优先传输的可用窗体大小，或者（2）使用非阻塞式写入。
5.4. 自动注销计时器
如果服务器有一个静止的自动注销计时器，那么这个计时器的持续时间必须不少于30分钟。在这个间隔里，来自客户端的任何命令应当重设这个自动注销计时器。
5.5. 多个命令在行进中
受多义规则（见下）和优先数据流的流控制约束的影响，客户端可能不等到一个命令的完成结果响应就发送另外一个命令。类似的，受多义规则的影响， 服务器可能在处理当前命令的实现前，就开始处理另外一个命令。不过，在任何后续命令初始化前，任何连续请求响应和连续命令必须协调。
因为一个命令可能影响到其它命令的结果，一个多义可能导致异常。客户端不应当未等待一个多义的返回结果就发送多个命令。如果服务器发现了一个可能存在的多义，它必须按照客户端给出的顺序完成命令的执行。
最常见的多义例子是，一个命令可能影响其它命令的结果，例如，一个邮件标记的FETCH和同一个邮件标记的STORE。 一个不常见的多义例子是，允许一个非标签化EXPUNGE响应的命令（除了FETCH，STORE，SEARCH），因为一个非标签化响应可以 使一个后续命令的序列号无效。这个问题不会发生于FETCH，STORE，或者SEARCH命令，因为这些命令中的任何一个在行进中时，服务器禁止发送 EXPUNGE响应。因此，如果客户端发送FETCH，STORE，或者SEARCH之外的任意命令，则必须在发送一个带有邮件序列号的命令前，就等待直 至得到完成结果响应。 注意：UID FETCH，UID STORE，和UID SEARCH命令不同于FETCH，STORE，和SEARCH。如果客户端发送了一个UID命令，它必须在发送一个带有邮件序列号的命令前，就等待直至得到一个完成结果响应。
例如，下面的非等待式命令序列是无效的：