FETCH + NOOP + STORE STORE + COPY + FETCH COPY + COPY CHECK + FETCH
下面是有效的非等待式命令序列的例子： FETCH + STORE + SEARCH + CHECK STORE + COPY + EXPUNGE
UID SEARCH + UID SEARCH非等待命令序列可能有效，可能无效，这取决于第二个UID SEARCH是否包含邮件序列号。
6. 客户端命令
本节描述IMAP4rev1命令。这些命令按照其被允许的状态组织。被多种状态允许的命令，只在其被允许的最小状态里列出（例如，在登录和选中状态都有效的命令，在登录状态中列出）。 命令参数，在下面的命令描述中标识为“参数:”，通过功能描述，而不是语法。命令参数的准确语法在正式语法一节中描述。
一些命令导致特定的服务器响应返回；它们在下面的命令描述中标识为“响应:”。响应一节中有这些响应的描述信息，正式语法一节中有这些响应的准 确语法。将服务器数据作为任意命令的一个结果传送，这是有可能的。这样，不特别请求服务器数据的命令描述成“此命令无特定响应”，而不是“无”。 命令描述中的“结果:”指明一个命令可能的标签化状态响应，和这些状态响应的任何特定解释。 只有成功的、改变状态的文档化命令才会改变一个连接的状态。一个被拒绝命令（BAD响应）永远不会改变一个被选中邮箱的连接状态。一个失败命令（NO响应）一般不会改变被选中邮箱的连接状态；SELECT和EXAMINE命令例外。
6.1. 客户端命令－任意状态
以下命令在任何状态下都有效：CAPABILITY，NOOP，和LOGOUT。
6.1.1. CAPABILITY命令
参数：无
响应：请求非标签化响应：CAPABILITY 结果：OK－capability完成 BAD－未知命令，或者参数无效
CAPABILITY命令请求服务器支持的功能列表。在（标签化）OK响应之前，服务器必须发送一个非标签化的、带有“IMAP4rev1”作为其功能列表之一的CAPABILITY响应。
一个以“AUTH=”开头的capability名，表示服务器支持这种特定的认证机制。所有这些名称，在定义上，都是本文档的一部分。例如， 一个实验性的
“blurdybloop”认证者的认证capability可以是“AUTH=XBLURDYBLOOP”，而不是 “XAUTH=BLURDYBLOOP”或者“XAUTH=XBLURDYBLOOP”。
其它的capability名参考本文档的扩展版、修订版、或者改正版。更多信息参见CAPABILITY响应的文档。除非有明确的客户端动作激活capability，否则，超出本文档IMAP4rev1基本集的capabilities是不可用的。 客户端和服务器必须实现STARTTLS，LOGINDISABLED，和AUTH=PALIN（“IMAP-TLS”中有描述）的capabilities。重要信息参看安全考虑一节。
关于站点形式或者实现体特定的capability信息参看题为“客户端命令－试验/扩展”一节。 例子：
C: abcd CAPABILITY
S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI LOGINDISABLED
S: abcd OK CAPABILITY completed C: efgh STARTTLS
S: efgh OK STARTTLS completed
S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN S: ijkl OK CAPABILITY completed
6.1.2. NOOP命令
参数：无
响应：此命令无特定响应（见下） 结果：OK－noop完成
BAD－未知命令，或者参数无效
NOOP命令总是成功的。它什么也不做。
因为任何命令都可以返回一个状态更新作为非标签化数据，NOOP命令可以用作新邮件的周期性检测，或者在一个静止期间内的邮件状态刷新（实现这个，用这种方法是比较好的）。NOOP命令还可以用来重设服务器上任何静止的自动注销计时器。 例子：
C: a002 NOOP
S: a002 OK NOOP completed ?
C: a047 NOOP S: * 22 EXPUNGE S: * 23 EXISTS S: * 3 RECENT
S: * 14 FETCH (FLAGS (/Seen /Deleted)) S: a047 OK NOOP completed
6.1.3. LOGOUT命令
参数：无
响应：要求非标签化的响应：BYE 结果：OK－logout完成
BAD－未知命令，或者无效参数
LOGOUT命令告知服务器，客户端准备关闭连接。服务器必须在（标签化）OK响应前，发送一个BYE非标签化响应，并随后关闭这个网络连接。 例子：
C: A023 LOGOUT
S: * BYE IMAP4rev1 Server logging out S: A023 OK LOGOUT completed
(Server and client then close the connection)
6.2. 客户端命令－未认证状态
在未认证状态下，AUTHENTICATE或者LOGIN命令建立认证并进入认证状态。AUTHENTICATE命令为各种认证技术、隐藏保护 和整数验证提供了一套常见的的机制；而LOGIN命令使用一个传统的用户名和简单文本密码对，没有建立隐藏保护或者整数验证的措施。
STARTTLS命令是建立会话隐藏保护和整数验证的一种可选形式，但是它不建立认证或者进入认证状态。
服务器实现体可能允许未建立认证就访问特定邮箱。这可以通过“ANONYMOUS”中描述的ANONYMOUS“SASL”认证者实现。以前的 一个约定是使用用户
ID“anonymous”的LOGIN命令；这种情况下，要求一个密码，尽管服务器可能选择接受任意密码。对匿名用户的约束依赖于实 现体。
一旦被认证（包括匿名用户），就不可能再进入未认证状态。
除了一般命令（CAPABILITY，NOOP，和LOGOUT），未认证状态下以下命令也是正确的：STARTTLS，AUTHENTICATE和LOGIN。关于这些命令的重要信息请参看安全考虑一节。
6.2.1. STARTTLS命令
参数：无
响应：此命令无需特定响应
结果：OK－starttls完成，开始TLS对话 BAD－未知命令，或者无效参数
在来自服务器端的标签化OK响应末尾的CRLF之后，一个“TLS”对话就开始了。一旦一个客户端发出一个STARTTLS命令，它就不能再发送其它命令，直到服务器响应出现并且“TLS”对话结束。
服务器保持未认证状态，即使客户端证书在“TLS”对话期间是受支持的。这不排除像EXTERNAL（“SASL”中定义的）的认证机制使用“TLS”对话决定的用户标识。
一旦“TLS”开始，客户端必须丢弃关于服务器功能的缓存信息，且应当重新发出CAPABILITY命令。这对保护免受修改功能列表指向STARTTLS的中间者攻击是有必要的。服务器可以在STARTTLS后发出不同功能。 例子：
C: a001 CAPABILITY
S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED S: a001 OK CAPABILITY completed C: a002 STARTTLS
S: a002 OK Begin TLS negotiation now
S: * CAPABILITY IMAP4rev1 AUTH=PLAIN S: a003 OK CAPABILITY completed C: a004 LOGIN joe password S: a004 OK LOGIN completed
6.2.2. AUTHENTICATE命令
参数：认证机制名
响应：可请求的连续数据
结果：OK－authenticate完成，当前为认证状态
NO－authenticate失败：不支持的认证机制，被拒绝的证书 BAD－未知命令，或者无效参数，认证对话被取消
AUTHENTICATE命令向服务器指出一个[SASL]认证机制。如果服务器支持被请求的认证机制，则它执行一个认证协议对话来认证并确认 客户端。它也可以为后续协议交互构建一个OPTIONAL安全层。如果被请求的认证机制不被支持，则服务器通过发送一个标签化NO响应来拒绝 AUTHENTICATE命令。
AUTHENTICATE命令不支持[SASL]的可选“初始响应”特性。[SASL]5.1一节，说明了如何处理使用一个初始响应的认证机制。
[SASL]的这个协议的片面描述的服务名称是“imap”。
认证协议对话由认证机制特定的、一系列服务器邀请和客户端响应组成。一个服务器邀请由一个以“+”开头，后跟一个BASE64编码的字符串的命 令连续请求响应组成。如果客户端希望取消一个认证对话，它就发出由一个“*”组成的一个行。如果服务器接收到这样一个响应，它必须通过发送一个标签化的 BAD响应来拒绝AUTHENTICATE命令。
如果一个安全层是通过[SASL]认证对话构建的，那么，紧跟在结束客户端的认证对话的CRLF、及服务器的标签化OK响应的CRLF之后，它就起效了。
客户端和服务器实现体必须自己执行AUTHENTICATE命令时，并不要求它实现[IMAP－TLS]中描述的简单机制以外的任何认证机制。同时，不要求一个认证机制被支持于任意安全层。
注意：一个服务器实现体必须执行一个不允许任何简单文本型密码机制的配置，除非STARTTLS命令已经启动，或者提供了保护会话免受密码窥探 的其它机制。在没有保护机制避免密码窥探的情况下使用简单文本型密码机制，服务器站点不应当使用这样的配置。客户端和服务器实现体应当执行不使用简单文本 型密码的其它[SASL]机制，像[SASL]中描述的GSSAPI机制和（或者）[DIGEST-MD5]机制。
服务器和客户端可以支持多个认证机制。服务器应当在其CAPABILITY命令的响应中列出其支持的认证机制，以便客户端知道使用何种认证机制。
在一个成功的AUTHENTICATE命令的标签化OK响应里，服务器可以包含进一个CAPABILITY响应码，以便自动发送功能。如果一个 客户端认出这些自动的功能，它就无需发送一个CAPABILITY命令。只有在一个安全层没有被AUTHENTICATE命令构建的时候，才能这样做，因 为作为一个AUTHENTICATE命令的一部分的标签化OK响应，是不受加密或者整数验证的保护的。在这种情况下，[SASL]要求客户端重新发出一个 CAPABILITY命令。
如果一个AUTHENTICATE命令以一个NO响应宣告失败，客户端可以通过发出另外一个AUTHENTICATE命令尝试另外一个认证机 制。它也可以通过使用LOGIN命令尝试认证（更多细节参看6.2.3一节）。就是说，客户端可以按降序请求认证类别，LOGIN命令则是最后的选择。 在认证对话期间，从客户端传送至服务器的授权标识被服务器解释为正处于优先级的用户名，即正请求的用户。 例子：
S: * OK IMAP4rev1 Server C: A001 AUTHENTICATE GSSAPI S: +
C: YIIB+wYJKoZIhvcSAQICAQBuggHqMIIB5qADAgEFoQMCAQ6iBwMFACAAAACjggEmYYIBIjCCAR6gAwIBBaESGxB1Lndhc2hpbmd0b24uZWR1oi0wK6ADAgEDoSQwIhsEaW1hcBsac2hpdmFtcy5jYWMud2FzaGluZ3Rvbi5lZHWjgdMwgdCgAwIBAaEDAgEDooHDBIHAcS1GSa5b+fXnPZNmXB9SjL8Ollj2SKyb+3S0iXMljen/jNkpJXAleKTz6BQPzj8duz8EtoOuNfKgweViyn/9B9bccy1uuAE2HI0yC/PHXNNU9ZrBziJ8Lm0tTNc98kUpjXnHZhsMcz5Mx2GR6dGknbI0iaGcRerMUsWOuBmKKKRmVMMdR9T3EZdpqsBd7jZCNMWotjhivd5zovQlFqQ2Wjc2+y46vKP/iXxWIuQJuDiisyXF0Y8+5GTpALpHDc1/pIGmMIGjoAMCAQGigZsEgZg2on5mSuxoDHEA1w9bcW9nFdFxDKpdrQhVGVRDIzcCMCTzvUboqb5KjY1NJKJsfjRQiBYBdENKfzK+g5DlV8nrw81uOcP8NOQCLR5XkoMHC0Dr/80ziQzbNqhxO6652Npft0LQwJvenwDI13YxpwOdMXzkWZN/XrEqOWp6GCgXTBvCyLWLlWnbaUkZdEYbKHBPjd8t/1×5Yg== S: + YGgGCSqGSIb3EgECAgIAb1kwV6ADAgEFoQMCAQ+iSzBJoAMCAQGiQgRAtHTEuOP2BXb9sBYFR4SJlDZxmg39IxmRBOhXRKdDA0uHTCOT9Bq3OsUTXUlk0CsFLoa8j+gvGDlgHuqzWHPSQg== C:
S: + YDMGCSqGSIb3EgECAgIBAAD/////6jcyG4GE3KkTzBeBiVHeceP2CWY0SR0fAQAgAAQEBAQ=
C: YDMGCSqGSIb3EgECAgIBAAD/////3LQBHXTpFfZgrejpLlLImPwkhbfa2QteAQAgAG1yYwE=
S: A001 OK GSSAPI authentication successful