服务器数据可能被作为客户端命令的结果发送，或者可能被服务器单方面发送。源于特定命令的服务器数据，和单方面发送的服务器数据，二者之间没有语法上的差异。
服务器完成结果响应表示操作的成功或者失败。它具有与开始操作的客户端命令一样的标签。然而，如果有多于一个的命令在行进中，服务器完成响应的 标签将标识该响应适用的命令。可能的服务器完成响应有三种：OK（表示成功），NO（表示失败），或者BAD（表示协议错误，如：未知命令，或者命令语法 错误）。 服务器应当严格遵照本文档的语法大纲。任何带有协议语法错误，包括（但不限于）少了、多了空格或者参数，都应该被拒绝，并且服务器应当给客户端一个BAD服务器完成响应。
IMAP4rev1客户端的协议接收端从服务器读取一条响应行。它可以根据响应的第一个标记――可以是标签，一个“*”，或者一个“+”，做出动作作为响应。 客户端必须一直准备着接收任何服务器响应，包括非请求的服务器数据。服务器数据应当存储下来，以便客户端可以参照它存储的副本，而不是发送命令至服务器去请求数据。某些服务器数据则必须存储下来。 这个主题在服务器响应一节中有更细节的讨论。
2.3. 邮件属性
除了邮件文本，每个邮件都有一些与其相关的属性。这些属性可以被单独收回，或者与其它属性、或者邮件文本组合。
2.3.1. 邮件号
IMAP4rev1的邮件通过两个数值中的一个访问：唯一标识符，或者邮件序列号。 2.3.1.1. 唯一标识符（UID）的邮件属性
分配给每一个邮件的32位值，和唯一标识符的值（见下）形成一个64位的值，这个值永远不能指向这个邮箱中的其它任何邮件，或者它后面的同名邮 箱。分配时，邮箱中的唯一标识符严格地按升序排列；每个邮件添加至邮箱时，它将被派予一个比它先加进来的邮件的唯一标识符更大的唯一标识符。与邮件序列号 不同，唯一标识符可以是不连续的。 在其会话存活期，一个邮件的唯一标识符不能改变，也不应该在不同的会话间改变。唯一标识符在不同会话间的改变必须使用下面谈到的唯一标识符校验 机制审查。永久唯一标识符要求客户端刷新其状态，以区别于与服务器的前面一个会话（例如：无连接，或者离线访问的客户端）；这将在[IMAP-DISC] 进一步地讨论。
与每个邮箱关联，有两个值维护着唯一标识符的指针：后续唯一标识符的值，和当前唯一标识符的值。 后续唯一标识符的值，是以后分配给这个邮箱中的新邮件的预留值。若非当前唯一标识符的值也改变了（见下），后续唯一标识符的值必须具有以下两个 特点。
第一，若非新的邮件被加进邮箱，后续唯一标识符的值不能改变；第二，一旦新的邮件被加进邮箱，后续唯一标识符必须改变，即使这些新的邮件随后被删除 了。 注意：后续唯一标识符，是被用来提供这样一种手段，即客户端判断从上一次确认它的值后，是否有新的邮件被发送到邮箱。并不一定任何邮件都有唯一标识符。客户端只能推测，一旦它获得后续唯一标识符，此后到达的邮件的唯一标识符大于等于这个值。
当邮箱被选中时，唯一标识符的值将通过一个非标签化的OK响应的唯一标识符校验响应码发送。如果早先会话的唯一标识符不能永存于这个会话中，则唯一标识符的值必须大于早先会话的唯一标识符。
注意：理想情况下，唯一标识符可以一直永存。尽管本文档承认，不能永存的情况在特定服务器环境下是不可避免的，但我们极力鼓励避免这个问题的邮件存储实现技术。例如：
1）邮箱中的唯一标识符必须永远严格按升序排序。如果物理邮件存储被非IMAP代理刷新，则邮箱中的唯一标识符应当刷新，因为这种刷新（非IMAP代理刷新）导致旧的唯一标识符不再严格按升序排序了。
2）如果邮件存储没有唯一标识符的存储机制，那么它必须在每个会话刷新唯一标识符，并且每个会话必须具有一个唯一标识符校验值。
3）如果一个邮箱被删除，并且之后一个新的同名邮箱被创建，服务器必须保持区别于之前邮箱的唯一标识符的记录，或者分配给新邮箱一个新的唯一标 识符校验码。在这里，一个好的唯一标识符校验码，是代表邮箱创建日期或者时间的32位数。使用一个常数，如1,是没问题的，但这只是在这样前提下――确保 唯一标识符永远不再被使用，即使一个邮箱被删除（或者重命名），及一个新的同名邮箱不久被创建。
4）邮箱名、唯一标识符校验码、唯一标识符，三者的联合必须永远指向服务器上的一个固定邮件。特别的，实际日期、[RFC-2822]大小、邮 戳、主体结构及邮件文本（RFC822、RFC822.HEADER、RFC822.TEXT、及所有BODY[?]获取数据项）必须永不改变。这并不包 括邮件号、及可以通过一个STORE命令设置的属性（例如，FLAGS）。
2.3.1.2. 邮件序列号的邮件属性
邮箱中，从1到邮件总数的一个相对位置。这个位置必须是按升序排序了的唯一标识符。每当新的邮件被加进来，它就被分配一个比它加进来之前该邮箱中的邮件总数大1的邮件序列号。
在会话存活期，邮件序列号可以重新分配。例如，当一个邮件被从邮箱中永久删除，其后的所有邮件的邮件序列号就减小。邮箱的邮件总数也减小。类似的，一个新加进来的邮件将被分配一个邮件序列号――之前被删除了的其它邮件所持有的邮件序列号。 邮件序列号，不仅可以用于通过邮箱的相对位置访问邮件，还可以用于数学运算。例如，如果接收到一个非标签化的“11 EXISTS”，且之前接 收了一个非标签化的“8 EXISTS”，那么，已经有邮件序列号为9、10、11的三个新邮件到达。另外一个例子，如果一个有523个邮件的邮箱中的邮 件287的唯一标识符是12345，那么，实际上，该邮箱中，有286条邮件的唯一标识符小于12345,有236个邮件的唯一标识符大于12345.
2.3.2. 标记的邮件属性
与邮件相关联的一个0串或者已命名的符号串。向该串中新增时，设置一个标记，从该串中删除时，清除该标志。IMAP4rev1中有两种标记。两种标记的实例都可以是永久化的，或者会话化的。
系统标记是指在本文档中预告确定的。所有的系统标记以“/”开头。一些系统标记（/Deleted和/Seen）在其它地方的描述中有特殊的语义。目前定义的系统标记有： /Seen 邮件已读 /Answered 邮件已回复 /Flagged
邮件标记为紧急或者特别注意。 /Deleted
邮件为删除状态。 /Draft
邮件未写完（标记为草稿状态）。 /Recent
邮件是新到达邮箱的。这个会话是关于这个邮件的第一个会话；如果这个会话是可读写的，后续会话将看不见这个邮件的/Recent设置符。客户端不能修改该标记。
一个会话，如果不能判断它是不是关于一个邮件的第一个会话，那么就应当考虑这个邮件是新的。
如果多个连接同时选中了同一个邮箱，哪个连接会看到带有/Recent设置符的、新到达的邮件，哪个连接会看到没有/Recent设置符的邮件，这还没有定义。 关键词是由服务器实现体定义的。关键词并不以“/”开头。服务器可以允许客户端定义新邮箱中的关键词（更多信息参看PERMANENTFLAGS响应码的描述）。 一个标记可以是永久的，或者会话化的（标记的生命周期为某个会话）。对于永久标记，客户端可以增加，或者从邮件标记集中永久删除；即，当前和后续会话将可以看见永久标记集中的任何变化。对会话标记的改变只在其会话内是可视的。 注意：/Recent系统标记是会话标记的一个特例。/Recent不能在一个STORE或者APPENT命令中作为一个变量，也不能被改变。
2.3.3. 实际日期的邮件属性
服务器上邮件的实际日期和时间。它是反映何时接收到邮件的日期和时间，而不是[RFC-2822]头部中的日期和时间。按照SMTP的定义，通 过SMTP发送的邮件，其实际日期和时间反映的是这个邮件的最后发送日期和时间。通过IMAP4rev1的APPEND命令发送的邮件，其实际日期和时间 反映的是APPEND命令描述中所指定的。其它情形下，实际日期和时间遵照实现体的定义。
2.3.4. [RFC-2822]大小的邮件属性
同于[RFC-2822]版中的表述，即邮件中的字节串的长度。
2.3.5. 信封结构的邮件属性
[RFC-2822]邮件头部的一个语法表示。注意，IMAP信封结构与SMTP的不同。
2.3.6. 主体结构的邮件属性
[MIME-IMB]邮件主体结构信息的解析表示。
2.4. 邮件文本
IMAP4rev1允许获取邮件的全部[RFC-2822]文本，也允许获取它的一部分。特别的，获取[RFC-2822]邮件头部、[RFC-2822]邮件主体、一个[MIME-IMB]主体部分、或者一个[MIME-IMB]头部，也是可以的。
3. 状态和流程图
一旦客户端和服务器间的连接建立完成，一个IMAP4rev1连接就会处于4种状态中的某一种。初始状态在服务器的欢迎中标识。大多数命令只在 特定的状态中才是正确的。当连接处于不适当的状态时，客户端尝试一个不适当的命令引发协议错误，服务器将以一个BAD或者NO（取决于服务器的实现体）命 令完成结果响应。
3.1. 未认证状态
在未认证状态下，大多数命令在得到许可前，客户端必须提供认证证书。若非连接已经是预认证了的，一个连接开始时，就进入了未认证状态。
3.2. 认证状态
在认证状态下，客户端是认证了的，它必须先于影响邮件的命令被许可前，选择一个邮箱以访问。当一个预认证连接开始，被认可的认证证书已经提供，选择一个邮箱发生错误后，或者一个成功的CLOSE命令后，就进入了认证状态。
3.3. 选中状态
在一个选中状态，一个邮箱被选中以访问。当一个邮箱被成功选中时，就进入了这个状态。
3.4. 注销状态
在注销状态下，连接正在被终止。一个客户端请求（通过LOGOUT命令），或者客户端、服务器的单方面动作，都会导致进入这个状态。
如果客户端请求注销状态，服务器必须在关闭连接前发送LOGOUT命令的一个非标签化BYE响应和一个标签化OK响应；客户端在关闭连接前，必须读取这个LOGOUT命令的标签化OK响应至。 在没有发送一个包含原因的、非标签化BYE响应的情况下，一个服务器不能单方面关闭连接。一个客户端不应单方面关闭连接，而应当发出一个LOGOUT命令。如果服务器发现客户端单方面关闭了连接，服务器可以忽略这个非标签化BYE响应，并简单地关闭它的连接。 +———————-+
|connection established| +———————-+ || //
+————————————–+ | server greeting |
+————————————–+ || (1) || (2) || (3) // || ||
+—————–+ || ||
|Not Authenticated| || || +—————–+ || || || (7) || (4) || || || // // ||
|| +—————-+ ||
|| | Authenticated |<=++ || || +—————-+ || || || || (7) || (5) || (6) || || || // || ||
|| || +——–+ || || || || |Selected|==++ || || || +——–+ || || || || (7) || // // // //
+————————————–+ | Logout |
+————————————–+ ||