5. 操作注意事项 (Operational Considerations)
此处列出以下规则以确保所有 IMAP4rev2 实现能够正确互操作。
5.1 邮箱命名 (Mailbox Naming)
在 IMAP4rev2 中，邮箱名称以 Net-Unicode [NET-UNICODE] 编码 (这与 IMAP4rev1 不同)。客户端实现可以 (MAY) 尝试创建 Net-Unicode 邮箱名称，并且必须 (MUST) 将 LIST 返回的任何 8 位邮箱名称解释为 [NET-UNICODE]。服务器实现必须 (MUST) 禁止创建不符合 Net-Unicode 的 8 位邮箱名称。但是，服务器可以 (MAY) 接受非规范化的 UTF-8 邮箱名称，并在创建邮箱之前将其转换为 Unicode 规范化形式 C (NFC) (根据 Net-Unicode 要求)。选择接受此类非规范化 UTF-8 邮箱名称的服务器必须 (MUST) 在所有具有邮箱名称参数的 IMAP 命令中接受它们。特别是，SELECT <name> 必须打开使用 CREATE <name> 成功创建的同一个邮箱，即使 <name> 是非规范化的 UTF-8 邮箱名称。
不区分大小写的邮箱名称 INBOX 是一个特殊名称，保留用于表示"此服务器上此用户的主要邮箱"。(请注意，对于某些服务器上的某些用户，此特殊名称可能不存在，例如，如果用户无权访问个人命名空间。) 所有其他名称的解释取决于实现。
特别是，本规范对非 INBOX 邮箱名称的大小写敏感性不持任何立场。某些服务器实现在 ASCII 范围内完全区分大小写；其他服务器保留新创建名称的大小写但在其他方面不区分大小写；还有一些服务器将名称强制转换为特定的大小写。客户端实现必须能够与所有这些服务器进行交互。
创建新邮箱名称时，有一些客户端注意事项：
-
任何属于 atom-specials 之一的字符 (参见第 9 节中的"正式语法") 都将要求邮箱名称表示为引用字符串或字面量。
-
CTL 和其他非图形字符难以在用户界面中表示，最好避免使用。服务器可以 (MAY) 拒绝创建包含 Unicode CTL 字符的邮箱名称。
-
虽然列表通配符字符 ("%" 和 "*") 在邮箱名称中有效，但由于与通配符解释的冲突，很难将此类邮箱名称与 LIST 命令一起使用。
-
通常，一个字符 (由服务器实现确定) 被保留用于分隔层次结构级别。
-
按照惯例，两个字符 "#" 和 "&" 具有特殊含义，除非在该惯例中使用，否则应避免使用。分别参见第 5.1.2.1 节和附录 A.1。
5.1.1 邮箱层次命名 (Mailbox Hierarchy Naming)
如果希望导出分层邮箱名称，邮箱名称必须 (MUST) 是从左到右的层次结构，使用单个 ASCII 字符来分隔层次结构级别。在单个名称内的所有层次结构级别都使用相同的层次结构分隔符字符。
5.1.2 命名空间 (Namespaces)
个人命名空间 (Personal Namespace): 服务器认为在特定连接上的已认证用户的个人范围内的命名空间。通常，只有已认证用户才能访问其个人命名空间中的邮箱。它是属于用户并分配用于邮箱的命名空间部分。如果用户存在 INBOX，则它必须 (MUST) 出现在用户的个人命名空间内。在典型情况下，服务器上的每个用户应该 (SHOULD) 只有一个个人命名空间。
其他用户命名空间 (Other Users' Namespace): 由其他用户的个人命名空间中的邮箱组成的命名空间。要访问其他用户命名空间中的邮箱，当前已认证用户必须 (MUST) 被明确授予访问权限。例如，经理通常会向其行政支持人员授予对其邮箱的访问权限。在典型情况下，服务器上的每个用户应该 (SHOULD) 只有一个其他用户命名空间。
共享命名空间 (Shared Namespace): 由旨在在用户之间共享且不存在于用户个人命名空间内的邮箱组成的命名空间。
服务器使用的命名空间可以 (MAY) 因用户而异。
5.1.2.1 历史邮箱命名空间命名约定 (Historic Mailbox Namespace Naming Convention)
按照惯例，任何以 "#" 开头的邮箱名称的第一个层次元素标识名称其余部分的"命名空间"。这使得可以消除不同类型的邮箱存储之间的歧义，每种邮箱存储都有自己的命名空间。
例如，提供对 USENET 新闻组访问的实现可以 (MAY) 使用 "#news" 命名空间将 USENET 新闻组命名空间与其他邮箱的命名空间分开。因此，comp.mail.misc 新闻组将具有邮箱名称 "#news.comp.mail.misc"，而名称 "comp.mail.misc" 可以引用不同的对象 (例如，用户的私人邮箱)。
包含 "#" 字符的命名空间对 IMAP URL [IMAP-URL] 不友好，并且在 URL 中需要将 "#" 字符表示为 %23。因此，服务器实现者可以 (MAY) 考虑使用不包含 "#" 字符的命名空间前缀。
5.1.2.2 常见命名空间模型 (Common Namespace Models)
此协议的先前版本未定义默认服务器命名空间。已经演变出两种常见的命名空间模型：
"个人邮箱" (Personal Mailbox) 模型，其中呈现的默认命名空间仅包含用户的个人邮箱。要访问共享邮箱，用户必须使用转义机制来到达另一个命名空间。
"完整层次结构" (Complete Hierarchy) 模型，其中呈现的默认命名空间包括用户的个人邮箱以及他们有权访问的任何其他邮箱。
5.2 邮箱大小和消息状态更新 (Mailbox Size and Message Status Updates)
服务器可以在任何时候发送客户端未请求的数据。有时，本规范和/或扩展要求此类行为。例如，服务器以外的代理可能会向邮箱添加消息 (例如，新消息传递)；更改邮箱中消息的标志 (例如，多个代理同时访问同一个邮箱)；甚至从邮箱中删除消息。如果在处理命令期间观察到邮箱大小更改，服务器必须 (MUST) 自动发送邮箱大小更新。服务器应该 (SHOULD) 自动发送消息标志更新，而无需客户端明确请求此类更新。
关于服务器通知客户端删除消息存在特殊规则以防止同步错误；有关更多详细信息，请参阅 EXPUNGE 响应的描述 (第 7.5.1 节)。特别是，不允许 (NOT) 发送会减少邮箱中消息数量的 EXISTS 响应；只有 EXPUNGE 响应才能执行此操作。
无论客户端在记住来自服务器的数据方面做出什么实现决策，客户端实现必须 (MUST) 记住邮箱大小更新。它不得 (MUST NOT) 假设初始邮箱选择后的任何命令都将返回邮箱的大小。
5.3 无命令进行时的响应 (Response When No Command in Progress)
允许服务器实现在没有命令进行时发送未标记的响应 (EXPUNGE 除外)。发送此类响应的服务器实现必须 (MUST) 处理流控制注意事项。具体来说，它们必须 (MUST) 要么 (1) 验证数据大小不超过底层传输的可用窗口大小，要么 (2) 使用非阻塞写入。
5.4 自动登出计时器 (Autologout Timer)
如果服务器具有在认证后应用于会话的不活动自动登出计时器，则该计时器的持续时间必须 (MUST) 至少为 30 分钟。在该间隔期间从客户端接收任何命令都会重置自动登出计时器。
请注意，本规范对成功客户端认证之前使用的自动登出计时器没有任何限制。特别是，允许服务器使用缩短的预认证计时器来保护自己免受拒绝服务攻击。
5.5 进行中的多个命令 (命令管道化) (Multiple Commands in Progress / Command Pipelining)
客户端可以 (MAY) 在不等待命令的完成结果响应的情况下发送另一个命令，但需遵守歧义规则 (见下文) 和底层数据流上的流控制约束。类似地，服务器可以 (MAY) 在将当前命令处理完成之前开始处理另一个命令，但需遵守歧义规则。但是，任何命令继续请求响应和命令继续都必须 (MUST) 在启动任何后续命令之前进行协商。
例外情况是如果命令会影响其他命令的结果而导致歧义。如果服务器检测到可能的歧义，它必须 (MUST) 按照客户端给出的顺序将命令执行完成。
歧义的最明显示例是当一个命令会影响另一个命令的结果时。一个例子是 FETCH 会导致设置 \Seen 标志和 SEARCH UNSEEN 命令。
命令允许未标记的 EXPUNGE 响应 (FETCH、STORE 和 SEARCH 以外的命令) 时会出现不明显的歧义，因为未标记的 EXPUNGE 响应可以使后续命令中的序列号无效。对于 FETCH、STORE 或 SEARCH 命令，这不是问题，因为禁止服务器在这些命令中的任何一个正在进行时发送 EXPUNGE 响应。因此，如果客户端发送 FETCH、STORE 或 SEARCH 以外的任何命令，则必须 (MUST) 等待完成结果响应后再发送带有消息序列号的命令。
注意：在 UID FETCH、UID STORE 和 UID SEARCH 正在进行时允许 EXPUNGE 响应。如果客户端发送 UID 命令，则必须 (MUST) 等待完成结果响应后再发送使用消息序列号的命令 (这可能包括 UID SEARCH)。UID SEARCH 参数中的任何消息序列号都与 UID SEARCH 返回的任何未标记的 EXPUNGE 响应生效之前的消息相关联。
例如，以下非等待命令序列是无效的：