IMAP中有一些協議約定語。它們涉及到協議說明的某些方面，嚴格講，這些方面不屬於IMAP協議的部分，但是它們反映了被普遍認可的實踐經驗。協議的實現體需要考慮這些約定語，並避免衝突，不管實現這些約定語與否。例如，“&”不應該用作等級定義符――因爲這與郵箱的網絡命名約定衝突，而郵箱名稱中“&”的其它使用則無礙。

1.3. 實現者需要特別注意的地方

強烈建議IMAP協議的實現者閱讀與本文相關的[IMAP實現]的推薦文章，以利於理解這個協議的難點，及如何最好地創建一個有效溝通的產品。

IMAP4rev1設計成從[IMAP2]和未發佈的IMAP2bis協議向上兼容。IMAP4rev1很好地兼容了RFC1730中描述的 IMAP4協議；RFC1730中增加的、有異常的、被證實有問題的那些功能後來被刪減了。在IMAP4rev1的發展歷程中，早期的協議中某些方面遭到了廢棄。[IMAP－OBSOLETE]中，描述了IMAP4rev1實現者使用早期的協議實現時，可能遇到的、廢棄了的命令、響應及數據格式。

[IMAP-COMPAT]討論了與IMAP2bis的其它兼容問題，與早期的協議的最一般性的差異。[IMAP－HISTORICAL]全面討論了與[IMAP2]因罕見（被擅自主張者去除了）差異而產生的兼容問題；本文是歷史關注的源頭。

IMAP起初是爲舊的[RFC-822]標準發展的，因此一些項目在它們的名稱中把“RFC822”包含進來。除了RFC822.SIZE,還有更先進的取代；例如， RFC822.HEADER在新版中是BODY.PEEK[HEADER]。在所有案例中，“RFC822”應該解釋爲升級的 [RFC-822]標準的參考。

2. 協議概述

2.1. 鏈路層

IMAP4rev1協議假定了類似TCP提供的可靠數據流。使用TCP時，IMAP4rev1服務器監聽143端口。

2.2. 命令及響應

一次IMAP4rev1連接的組成有：一次客戶端、服務器的網絡連接的建立，服務器的初始歡迎，以及客戶端、服務器的交互。這些客戶端、服務器的交互由客戶端命令、服務器數據和服務器的完成結果響應組成。

傳送於客戶端和服務器間的所有交互都是以行的形式，即，以一個CRLF爲結束標誌的字符串。一個IMAP4rev1客戶端或者服務器的協議接收端要麼是按行讀取，要麼是以一個已知的數值n，每次讀取n個字節的串。

2.2.1. 客戶端的協議發送和服務器端的協議接收

客戶端命令引發操作。每個客戶端命令以一個標識作爲前綴（典型的有字母、數字構成的短字符串，如：A0001，A0002，等等）――它稱爲“標籤”。客戶端爲每個命令生成不同的“標籤”。

客戶端必須嚴格遵守本說明中的語法大綱。發送缺損的命令，或者多餘的空格、變量都屬於語法錯誤。

客戶端沒有描述一個完整的命令，有兩種情形。一種是，一個命令參數被以一個字節數引用（參看Data Formats下的String的原義描述）；另一種是，命令參數要求服務器的反饋（參看AUTHENTICATE命令）。這再者中的任何一種情形下，服務器發送命令以不停地請求響應――如果爲字節串（如果適當）和剩餘命令準備就緒。響應用“+”作爲前綴。

注意：而如果服務器發現命令的一個錯誤，它就發送一個帶有匹配於命令（如下所描述的）的標籤的BAD完整響應，以拒絕該命令，避免客戶端再發送更多的命令。

服務器對一些其它的命令（如果多個命令相繼發生）、或者非標籤化的數據，請求發送完整的響應，這也是可能的。在兩者中的任何一種情形下，連續的請求命令仍然是懸而不決的；客戶端對響應採取相應的動作，並讀取服務器的其它響應。所有情形下，客戶端必須在初始化一個新的命令前發送一個完整命令（包括接收所有連續請求響應命令）

IMAP4rev1服務器端的協議接收端，從客戶端讀取命令行，解析該命令行及其參數，並傳送服務器數據及一個服務器命令完成結果的響應。

2.2.2. 服務器端的協議發送和客戶端的協議接收

那些沒有標識命令完成的、被服務器傳送至客戶端的數據和狀態響應，用“*”作爲前綴，並稱爲非標籤化的響應。

服務器數據可能被作爲客戶端命令的結果發送，或者可能被服務器單方面發送。源於特定命令的服務器數據，和單方面發送的服務器數據，二者之間沒有語法上的差異。

服務器完成結果響應表示操作的成功或者失敗。它具有與開始操作的客戶端命令一樣的標籤。然而，如果有多於一個的命令在行進中，服務器完成響應的標籤將標識該響應適用的命令。可能的服務器完成響應有三種：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 |
+————————————–+
||
//
+——————————-+
|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命令，它必須在發送一個帶有郵件序列號的命令前，就等待直至得到一個完成結果響應。

例如，下面的非等待式命令序列是無效的：

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

C: ijkl CAPABILITY

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

C: a003 CAPABILITY

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==

S: + YDMGCSqGSIb3EgECAgIBAAD/////6jcyG4GE3KkTzBeBiVHeceP2CWY0SR0fAQAgAAQEBAQ=

C: YDMGCSqGSIb3EgECAgIBAAD/////3LQBHXTpFfZgrejpLlLImPwkhbfa2QteAQAgAG1yYwE=

S: A001 OK GSSAPI authentication successful

注意：服務器邀請和客戶端響應中的換行是爲了編輯上的清楚，而不是實際認證符。

6.2.3. LOGIN 命令

參數：用戶名

密碼

響應：此命令無特定響應

結果：OK－login完成，當前是認證狀態

NO－login失敗：用戶名或者密碼被拒絕

BAD－未知命令，或者無效參數

LOGIN命令向服務器確認客戶端，並帶有確認該用戶的簡單文本型密碼。

在一個成功的LOGIN命令的標籤化OK響應裏，服務器可以包含進一個CAPABILITY響應碼，以便（實現）自動發送功能。如果一個客戶認出了這些自動的功能，則它無需發送一個CAPABILITY命令。

例子：

C: a001 LOGIN SMITH SESAME

S: a001 OK LOGIN completed

注意：在一個不安全網絡（比如因特網）上使用LOGIN命令有安全風險，因爲任何網絡傳輸的監控者都可以獲取簡單文本型密碼。LOGIN命令不應當使用，除非作爲最後一種方法，同時，建議客戶端實現體採取措施使LOGIN命令的任何自動使用無效。

除非STARTTLS命令已經構建，或者已經提供了保護會話免受密碼窺探的機制，否則，一個服務器實現體必須實現一個機制，在這個機制裏宣告 LOGINDISABLED功能並且不允許LOGIN命令。服務器站點不應當使用沒有這樣一個免受密碼窺探（功能）的保護機制、而允許LOGIN命令的配置。如果LOGINDISABLED功能被宣告，則一個客戶端實現體不能發送一個LOGIN命令。

6.3. 客戶端命令－認證狀態

在認證狀態下，把郵箱作爲原語實體來操作的命令是允許的。在這些命令中，SELECT及EXMINE命令將會選中一個郵箱以訪問及進入選中狀態。

除了常見的命令（CAPABILITY，NOOP，和LOGOUT），以下命令在認證狀態下也是正確的：SELECT，EXAMINE，CREATE，DELETE，RENAME，SUBSCRIBE，UNSUBSCRIBE，LIST，LSUB，STATUS，和APPEND。

6.3.1. SEELCT命令

參數：郵箱名

響應：要求非標籤化的響應：FLAGS，EXISTS，RECENT

要求OK非標籤化響應：UNSEEN，PERMANENTFLAGS，UIDNEXT，UIDVALIDITY

結果：OK－select完成，當前是選中狀態

NO－select失敗，當前是認證狀態：不存在這個郵箱，不能訪問郵箱

BAD－未知命令，或者參數無效

SELECT命令選中一個郵箱，以便這個郵箱中的郵件可以被訪問。在返回一個OK給客戶端前，服務器必須發送以下非標籤化數據給客戶端。要注意的是，這個協議的早期版本只要求FLAGS，EXISTS，和RECENT非標籤化數據；因此，客戶端實現體應當把丟失數據作爲個別情況討論。

FLAGS

郵箱中被定義的標記。更多細節參看FLAGS響應的描述。

<n>EXISTS

郵箱中郵件的數量。更多細節參看EXISTS響應的描述。

<n>RECENT

帶有/Recent標記符的郵件的數量。更多細節參看RECENT響應的描述。

OK [UNSEEN <n>]

郵箱中第一封不可視郵件的郵件序列號。如果沒有這個，客戶端就不能對這個油箱中的第一封郵件做任何相關推測，如果想找到它，就需要發出一個SEARCH命令。

OK [PERMANENTFLAGS （<list of flags>）]

客戶端可以永久修改的郵件標記的列表。如果沒有這個，客戶端應當推測所有的標記都是可以永久修改的。

OK [UIDNEXT <n>]

下一個唯一標識符的值。更多信息參考2.3.1.1一節。如果沒有這個，客戶端不能對下一個唯一標識符做任何相關推測。

OK [UIDVALIDITY <n>]

當前唯一標識符的值。更多信息參考2.3.1.1一節。如果沒有這個，服務器就不支持唯一標識符。

在一個連接中，一次只能選中一個郵箱；同時訪問多個郵箱要求多個連接。在嘗試新的選擇前，SELECT命令自動釋放對任何當前選中郵箱的選中。因此，如果一個郵箱被選中，一個失敗的SELECT命令正嘗試，則沒有郵箱被選中。

如果客戶端被允許修改郵箱，則服務器應當把“[READ-WRITE]”響應碼作爲標籤化OK響應的文本的前綴。

如果客戶端沒有修改郵箱的權限，但是有讀取權限，則郵箱以只讀方面選中，且服務器必須用“[READ-ONLY]”響應碼作爲標籤化OK響應的文本前綴，以SELECT。通過SELECT方式的只讀訪問，與通過EXAMINE方式的只讀訪問，二者的區別在於，特定的只讀郵箱可能允許基於用戶（而不是全局）的永久狀態的改變。在一個基於服務器的.newsrc文件中做了標記的網絡論壇郵件就是這種可以被修改的、帶有隻讀郵箱的、基於用戶的永久狀態的一個例子。

例子：

C: A142 SELECT INBOX

S: * 172 EXISTS

S: * 1 RECENT

S: * OK [UNSEEN 12] Message 12 is first unseen

S: * OK [UIDVALIDITY 3867529045] UID valid

S: * OK [UIDNEXT 4392] Predicted next UID

S: * FLAGS (/Answered /Flagged /Deleted /Seen /Draft)

S: * OK [PERMANENTFLAGS (/Deleted /Seen /*)] Limited

S: A142 OK [READ-WRITE] SELECT completed

6.3.2. EXAMINE命令

參數：郵箱名

響應：要求非標籤化響應：FLAGS，EXISTS，RECENT

要求OK非標籤化響應：UNSEEN，PERMANENTFLAGS，UIDNEXT，UIDVALIDITY

結果：OK－examine完成，當前是選中狀態

NO－examine失敗，當前是認證狀態：沒有這個郵箱，不能訪問郵箱

BAD－未知命令，或者無效參數

EXAMINE命令與SELECT相同，並返回同樣的輸出；不過，只讀方式時選中的郵箱是一樣的。郵箱的永久狀態下，沒有變動，包括有基於用戶的狀態的權限；特別的，EXAMINE不能使郵件丟失/Recent標記。

EXAMINE命令的標籤化OK響應文本必須以“[READ-ONLY]”開頭。

例子：

C: A932 EXAMINE blurdybloop

S: * 17 EXISTS

S: * 2 RECENT

S: * OK [UNSEEN 8] Message 8 is first unseen

S: * OK [UIDVALIDITY 3857529045] UIDs valid

S: * OK [UIDNEXT 4392] Predicted next UID

S: * FLAGS (/Answered /Flagged /Deleted /Seen /Draft)

S: * OK [PERMANENTFLAGS ()] No permanent flags permitted

S: A932 OK [READ-ONLY] EXAMINE completed

6.3.3. CREATE命令

參數：郵箱名

響應：此命令無需特定響應

結果：OK－create完成

NO－create失敗：不能創建這個名稱的郵箱

BAD－未知命令，或者無效參數

CREATE命令用給定名稱創建一個郵箱。只有當這個名稱的新郵箱被創建完成時，才返回一個OK響應。試圖創建INBOX，或者一個與已在郵箱名同名的郵箱，引發一個錯誤。創建過程中的任何錯誤都將返回一個標籤化NO響應。

如果郵箱名以服務器的層級分隔符作爲尾綴（就像通過LIST命令從服務器返回的），這就告訴客戶端準備在這個名稱的層級下創建郵箱名。不要求這個通知的的服務器實現體必須忽略這個通知。任何情況下，這個被創建郵箱的名稱（應當）沒有多餘的層級分隔符。

如果郵箱名的其它地方出現服務器的層級分隔符，服務器應當創建CREATE命令成功完成所需要的每一個層級。即，在一個以“/”作爲層級分隔符的服務器上創建“foo/bar/zap”的嘗試，如果foo/和foo/bar不存在，則應當創建它們。

如果一個被創建的郵箱，它的名稱與已經被刪除的郵箱名相同，那麼，它的唯一標識符必須大於郵箱中先前引用中用到的任何一個唯一標識符，除非新的引用有一個不同的唯一標識符值。更多細節參看UID命令的描述。

例子：

C: A003 CREATE owatagusiam/

S: A003 OK CREATE completed

C: A004 CREATE owatagusiam/blurdybloop

S: A004 OK CREATE completed

注意：這個例子的解釋依賴於，從LIST“/”是否返回爲層級分隔符。如果“/”是層級分隔符，帶有一個名爲“blurdybloop”成員的一個新層級“owatagusiam”被創建。否則，處在同一層級的兩個郵箱被創建。

6.3.4. DELETE命令

參數：郵箱名

響應：此命令無需特定響應

結果：OK－delete完成

NO－delete失敗：不能刪除這個名稱的郵箱

BAD－未知命令，或者無效參數

DELETE命令永久刪除給定名稱的郵箱。若郵箱被刪除，則返回一個標籤化的OK響應。嘗試刪除INBOX，或者一個不存在的郵箱，是錯誤的。

DELETE命令不能刪除子級。例如，如果一個郵箱有一個子級“foo.bar”（假設“.”是層級定義符），刪除“foo”不能刪除“foo.bar”。嘗試刪除一個帶有子級、並且有/Noselect屬性的郵箱名，是錯誤的（更多細節參看LIST響應的描述）。

刪除一個帶有子級、並且沒有/Noselect屬性的郵箱名，是允許的。這種情況下，這個郵箱中的所有郵件被刪除，且這個郵箱名將取得/Noselect郵箱名屬性。

刪除了的郵箱使用的最高唯一標識符的值必須保留，這樣一個新創建的同名郵箱就不會再使用先前引用的標識符，除非這個新的引用有一個不同的唯一標識符值。更多細節參看UID命令的描述。

例子：

C: A682 LIST “” *

S: * LIST () “/” blurdybloop

S: * LIST (/Noselect) “/” foo

S: * LIST () “/” foo/bar

S: A682 OK LIST completed

C: A683 DELETE blurdybloop

S: A683 OK DELETE completed

C: A684 DELTE foo

S: A684 NO Name “foo” has inferior hierarchical names

C: A685 DELETE foo/bar

S: A685 OK DELETE Completed

C: A686 LIST “” *

S: * LIST (/Noselect) “/” foo

S: A686 OK LIST completed

C: A687 DELETE foo

S: A687 OK DELETE Completed

C: A82 LIST “” *

S: * LIST () “.” Blurdybloop

S: * LIST () “.” Foo

S: * LIST () “.” Foo.bar

S: A82 OK LIST completed

C: A83 DELETE blurdybloop

S: A83 OK DELETE completed

C: A84 DELETE foo

S: A84 OK DELETE Completed

C: A85 LIST “” *

S: * LIST () “.” foo.bar

S: A85 OK LIST completed

C: A86 LIST “” %

S: * LIST (/Noselect) “.” foo

S: A86 OK LIST completed

6.3.5. RENAME命令

參數：已經存在的郵箱名

新的郵箱名

響應：此命令無需特定響應

結果：OK－rename完成

NO－rename失敗：不能重命名郵箱爲這個名稱，不能以這個名稱重命名至郵箱

BAD－未知命令，或者無效參數

RENAME命令改變一個郵箱的名稱。當且僅當郵箱被重命名完成時，才返回一個標籤化的OK響應。嘗試把一個不存在的郵箱名重命名至一個已經存在的郵箱名，是錯誤的。重命名中的任何錯誤都將返回一個標籤化的NO響應。

如果名稱有子級名，（當重命名這個名稱時）則子級名必須也被重命名。例如，重命名“foo”爲“zap”，將重命名“foo/bar”（假設“/”是層級定義符）爲“zap/bar”。

如果服務器層級分隔符出現在名稱中，那麼服務器應當創建RENAME命令成功完成所需要的每一個父級名。即，嘗試在一個以“/”爲層級分隔符的服務器上重命名“foo/bar/zap”爲baz/rag/zowie，如果baz/和baz/rag/不存在，則應當創建它們。

舊郵箱使用的最高唯一標識符的值必須保留，這樣一個新創建的同名郵箱就不會再使用先前引用的標識符，除非這個新的引用有一個不同的唯一標識符值。更多細節參看UID命令的描述。

重命名INBOX是允許的，並且有特殊的行爲。它移動INBOX中的所有郵件至一個給定名稱的新郵箱中，INBOX則爲空。如果服務器實現體支持INBOX的子級名，則這些不受INBOX重命名的影響。

例子：

C: A682 LIST “” *

S: * LIST () “/” blurdybloop

S: * LIST (/Noselect) “/” foo

S: * LIST () “/” foo/bar

S: A682 OK LIST completed

C: A683 RENAME blurdybloop sarasoop

S: A683 OK RENAME completed

C: A684 RENAME foo zowie

S: A684 OK RENAME Completed

C: A685 LIST “” *

S: * LIST () “/” sarasoop

S: * LIST (/Noselect) “/” zowie

S: * LIST () “/” zowie/bar

S: A685 OK LIST completed

C: Z432 LIST “” *

S: * LIST () “.” INBOX

S: * LIST () “.” INBOX.bar

S: Z432 OK LIST completed

C: Z433 RENAME INBOX old-mail

S: Z433 OK RENAME completed

C: Z434 LIST “” *

S: * LIST () “.” INBOX

S: * LIST () “.” INBOX.bar

S: * LIST () “.” old-mail

S: Z434 OK LIST completed

6.3.6. SUBSCRIBE命令

參數：郵箱

響應：此命令無需特定

結果：OK－subscribe完成

NO－subscribe失敗：不能訂閱這個郵箱名

BAD－未知命令，或者無效參數

SUBSCRIBE命令增加指定郵箱名至服務器的活動郵箱序列或者訂閱郵箱序列中，通過LSUB命令返回。當且僅當訂閱成功時，該命令返回一個標籤化的OK響應。

服務器可以向SUBSCRIBE證實郵箱參數以確保它的存在。但是，它不能單方面從訂閱列表中刪除一個存在的郵箱名，即使該郵箱名不存在了。

注意：這個需求是出於，一個服務器可以選擇，在一個郵箱名衆所周知的郵箱的內容過期後，常規地刪除該郵箱（比如，“system-alerts”），以便在新的內容匹配時重新創建它。

例子：

C: A002 SUBSCRIBE #news.comp.mail.mime

S: A002 OK SUBSCRIBE completed

6.3.7. UNSUBSCRIBE命令

參數：郵箱名

響應：此命令無需特定響應

結果：OK－unsubscribe完成

NO－unsubscribe失敗：不能取消訂閱該郵箱名

BAD－未知命令，無效參數

UNSUBSCRIBE從服務器的活動郵箱序列或者訂閱郵箱序列中刪除特定郵箱名，通過LSUB命令返回。當且僅當取消訂閱成功時，該命令返回一個標籤化的OK響應。

例子：

C: A002 UNSUBSCRIBE #news.comp.mail.mime

S: A002 OK UNSUBSCRIBE completed

6.3.8. LIST命令

參數：引用名，帶可能的通配符的郵箱名

響應：非標籤化的響應：LIST

結果：OK－list完成

NO－list失敗：不能列出該引用或者名稱

BAD－未知命令，或者無效參數

LIS命令返回客戶端可用的所有名稱的完整序列的一個名稱子序列。返回０,或者更多的非標籤化LIST答覆，包含名稱屬性，層級定義符，和名稱；更多細節參看LIST答覆的描述。

LIST命令應當迅速返回其數據，沒有過度的延時。例如，它不應當節外生枝地計算/Marked或者/Unmarked狀態，或者進行其它處理；如果每一個名稱需要１秒鐘的處理，那麼列出1200個名稱則需要20分鐘！

一個空的（“”空串）引用名參數表明郵箱名是通過SELECT解釋的。返回的郵箱名必須與受支持的郵箱名模式匹配。一個非空的引用名參數是一個郵箱名，或者郵箱的一個層級，它指定了被解釋的郵箱名的上下文。

一個空的（“”空串）郵箱名參數是爲返回層級定義符和引用中所給定名稱的根結點名的一個特殊請求。如果引用不是根結點，或者是一個空串，返回作爲根結點的值可能是空串。在所有情況下，都返回一個層級定義符（或者NIL－如果沒有層級）。這允許客戶端取得層級定義符（或者證實郵箱名是在同一級的），即使當前沒有那個名稱的郵箱存在。

引用和郵箱名參數被解釋成一個規範形式，它表示成一個清晰的從左到右層級。返回的郵箱名將會在解釋形式中。

注意：引用參數的解釋是基於實現體定義的。它取決於服務器實現體是否有一個“當前工作目錄”，及開頭的、可替代當前工作目錄的“折斷符”的概念，

例如，在一個輸出UNIX或者NT文件系統的服務器上，引用參數包含當前工作目錄，且郵箱名可能包含被解釋成在當前工作目錄中的名稱。

如果一個服務器沒有折斷符的概念，則規範形式應是帶郵箱名的引用名。注意，如果服務器實現了名稱空間的約定（5.1.2一節），則“#”必須被作爲折斷符對待。

如果服務器參數不是一個郵箱層級（即，它是一個/NoInferiors名稱），且/或引用參數不以層級定義符結束，則引用參數的解釋是基於實現體的。例如，一個“foo/bar”的引用和“rag/baz”的郵箱名可以解釋成“foo/bar/rag/baz”，“foo/barrage /baz”，或者“foo/rag/baz”。客戶端不應當使用這樣的一個引用參數，除非有用戶的明確請求。一個分層的瀏覽器不能對服務器的引用解釋作任何的假設，除非引用是一個郵箱層級並且以層級定義符結束。

包含於被解釋形式的、引用參數的任何部分應當以被解釋形式爲前綴。它應當與引用名稱參數有相同的形式。這個規則允許客戶端決定返回的郵箱名是否是在引用參數的上下文中，或者郵箱參數的一些相關信息是否可以代替引用參數。沒有這個上下文，可能客戶端得知道服務器名稱語義，包括什麼字符串是可以代替一個名稱上下文的折斷符。

例如，這裏是在一個基於UNIX的服務器上，引用和郵箱名可能被如何解釋的一些例子：

引用郵箱名解釋

~smith/Mail/ foo.* ~smith/Mail/foo.*

archive/ % archive/%

#news. comp.mail.* #news.comp.mail.*

~smith/Mail/ /usr/doc/foo /usr/doc/foo

archive/ ~fred/Mail/* ~fred/Mail/*

開頭的三個例子演示了引用參數的上下文中的解釋。注意，“~simth/Mail”不應當改成類似“/u2/users/smith/Mail”，否則客戶端就不可能斷定這個解釋是在引用的上下文中。

字符“*”是一個通配符，它匹配其所在位置的０個或者更多的字符。字符“%”類似於“*”，但是它不匹配一個層級定義符。如果“%”通配符是一個郵箱名參數的最後一個字符，匹配的層級也會返回。如果這些層級不是可選擇的郵箱，則它們帶着/Noselect郵箱屬性返回（更多細節參看LIST響應的描述）。

允許服務器實現體通過禁止特定的字符或者名稱，以免在特定情形下匹配一個通配符，這樣就隱藏源於通配符的、不同的可訪問郵箱。例如，一個基於UNIX的服務器可以限制“*”的解釋，以便一個初始的“/”字符不匹配。

如果對該用戶而言INBOX是受該服務器支持的，並且大寫字符串“INBOX”匹配帶有如上所述通配符的、被解釋的參數和郵箱名參數，那麼，特殊名稱INBOX包含於LIST的輸出。刪去INBOX的質疑是，SELECT INBOX是否會返回失敗；這無關於用戶的真實INBOX是否位於這個服務器或者其它服務器。

例子：

C: A101 LIST “” “”

S: * LIST (/Noselect) “/” “”

S: A101 OK LIST Completed

C: A102 LIST #news.comp.mail.misc “”

S: * LIST (/Noselect) “.” #news.

S: A102 OK LIST Completed

C: A103 LIST /usr/staff/jones “”

S: * LIST (/Noselect) “/” /

S: A103 OK LIST Completed

C: A202 LIST ~/Mail/ %

S: * LIST (/Noselect) “/” ~/Mail/foo

S: * LIST () “/” /Mail/meetings

S: A202 OK LIST completed

6.3.9. LSUB命令

參數：引用名，帶有可能的通配符的郵箱名

響應：非標籤化的響應：LSUB

結果：OK－lsub完成

NO－lsub失敗：不能列出那個引用或者名稱

BAD－未知命令，或者無效參數

LSUB命令返回的是，用戶已經聲明爲活動的、或者訂閱了的名稱序列的一個名稱子集。0個或者更多的非標籤化LSUB答覆被返回。LSUB的參數同於LIST的形式。

返回的非標籤化LSUB響應可能包含從一個非標籤化LIST響應的不同郵箱標記。如果出現這個，那麼在非標籤化LIST中的標記會被認爲是更可信的。

當使用帶有%通配符的LSUB時，一種特殊的情形就出現了。試想一下，如果“foo/bar”（帶有一個“/”層級定義符）是已訂閱的，而 “foo”不是。在LSUB響應中，LSUB的一個“%”通配符必須返回foo，而不是foo/bar，並且它必須標記爲帶/Noselect屬性的。

服務器不能單方面從訂閱列表中移除一個已經存在的郵箱名，即使那個名稱的郵箱已經不存在了。

例子：

C: A002 LSUB “#news.” “comp.mail.*”

S: * LSUB () “.” #news.comp.mail.mime

S: * LSUB () “.” #news.comp.mail.misc

S: A002 OK LSUB completed

C: A003 LSUB “#news.” “comp.%”

S: * LSUB (/NoSelect) “.” #news.comp.mail

S: A003 OK LSUB completed

6.3.10. STATUS命令

參數：郵箱名，狀態數據項名

響應：非標籤化響應：STATUS

結果：OK－status完成

NO－status失敗：沒有那個名稱的status

BAD－未知命令，或者無效參數

STATUS命令請求指定郵箱的狀態。它不改變當前被選中的郵箱，也不影響被請求的郵箱中的任何郵件的狀態（特別的，STATUS不能使郵件失去/Recent標記）。

STATUS提供了這樣一個選擇：在沒有取消選擇第一次IMAP4rev1連接中的當前郵箱的情況下，就打第二次IMAP4rev1連接，並在一個郵箱上進行一個EXAMINE命令以請求那個郵箱的狀態。

與LIST命令不同，STATUS命令不一定是快速響應的。在特定條件下，它可能是很慢的。在某些實現體中，服務器被希望以只讀方式內部打開郵箱獲取特定的狀態信息。STATUS命令不接受通配符，這一點也與LIST命令不同。

注意：STATUS命令用於訪問郵箱的狀態，而不是當前選中的郵箱。因爲STATUS命令可以使郵箱被內部打開，且這個信息是可以通過在選中郵箱上的其它手段獲取的，所以STATUS命令不應當用於當前選中郵箱。

STATUS命令不能用於“檢查選中郵箱中的新郵件”操作（關於檢查新郵件的恰當方法的更多信息，參看第7章，7.3.1和7.3.2）。

因爲STATUS命令不一定是快速響應的，所以客戶端不應當預計能夠發出一連串的STATUS命令並獲得相應的執行。

當前定義了的、可以請求的狀態數據項有：

MESSAGES

郵箱中郵件數量。

RECENT

帶有/Recent標記位的郵件數量。

UIDNEXT

郵箱的下一個唯一標識符的值。更多信息參看2.3.1.1一節。

UIDVALIDITY

郵箱的唯一標識符檢驗碼。更多信息參看2.3.1.1一節。

UNSEEN

不帶有/Seen標記位的郵件數量。

例子：

C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)

S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)

S: A042 OK STATUS completed

6.3.11. APPEND命令

參數：郵箱名，OPTIONAL位的組合列表，OPTIONAL日期/時間串，郵件原義

響應：此命令無特定響應

結果：OK－append完成

NO－append錯誤：不能添加到該郵箱，標記、或者日期/時間、或者郵件文本有錯誤

BAD－未知命令，或者無效參數

APPEND命令將原義參數像一個新郵件一樣添加到指定的目標郵箱末尾。這個參數應當是一個[RFC-2822]郵件的格式。郵件中允許8位字符串。一個不能正確保存8位數據的服務器執行體必須能夠用一個[MIME-IMB]內容轉換編碼，進行8位APPEND數據與7位（APPEND數據）之間的可逆轉換。

注意：可能有例外，比如，草稿郵件――其中被請求的[RFC-2822]頭在APPEND的郵件原義參數中被省略了。這樣做的整個關聯必須被理解並小心權衡。

如果一個組合列表被聲明，則標記位應當在結果郵件中被設置；否則，結果郵件的標記列表默認設置爲空。兩種情況下，Recent標記都要設置。

如果聲明瞭一個日期－時間，實際日期應當在結果郵件中被設置；否則，結果郵件的實際日期默認設置爲當前日期和時間。

如果插入操作因爲某種原因不能成功，郵箱必須恢復至APPEND嘗試前的狀態；不允許局部的插入操作。

如果目標郵箱不存在，服務器必須返回一個錯誤，且不能自動創建郵箱。除非確定目標郵箱不能被創建，否則，服務器必須發送響應碼 “[TRYCREATE]”作爲標籤化NO響應的文本的前綴。這給客戶端一個暗示，即它可以嘗試一個CREATE命令，並且，如果CREATE成功，還可以重試APPEND。

如果郵箱當前被選中，正常的新郵件動作應當發生。特別地，服務器應當通過一個非標籤化的EXISTS響應迅速通知客戶端。如果服務器不這樣做，客戶端可以在一個或者多個APPEND命令之後發出一個NOOP命令（或者，NOOP命令失敗，發出一個CHECK命令）。

例子：

C: A003 APPEND saved-messages (/Seen) {310}

S: + Ready for literal data

C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)

C: From: Fred Foobar [email protected]

C: Subject: afternoon meeting

C: To: [email protected]

C: Message-Id: [email protected]

C: MIME-Version: 1.0

C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

C: Hello Joe, do you think we can meet at 3:30 tomorrow?

S: A003 OK APPEND completed

注意：APPEND命令不用於郵件發送，因爲它不支持轉換[SMTP]信封信息的機制。

6.4. 客戶端命令－被選中狀態

在被選中狀態，操作一個郵箱中郵件的命令是被允許的。

除了全局命令（CAPABILITY, NOOP, 及LOGOUT），及認證狀態命令（SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, 及 APPEND），在被選中狀態時以下命令也是有效的：CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, 及UID。

6.4.1. CHECK命令

參數：無

響應：此命令無需特定響應

結果：OK－check完成

BAD－未知命令，或者無效參數

CHECK命令請求當前被選中郵箱的一個檢查站。一個檢查站指向每個取決於實現體的、與郵箱相關聯的（例如，以郵箱在硬盤中的狀態，決定它在服務器上的內存中的狀態）、並不是作爲每個命令的一部分進行常規執行的內部事務。一個檢查站可以完成實時的非瞬時數量。如果一個服務器實現體沒有這些內部事務的考慮，CHECK等效於NOOP。

一個EXISTS非標籤化響應作爲CHECK的一個結果發生，這是不一定的。NOOP，而不是CHECK，應當用於新郵件的投票。

例子：

C: FXXZ CHECK

S: FXXZ OK CHECK Completed

6.4.2. CLOSE命令

參數：無

響應：此命令無需特定響應

結果：OK－close完成，當前是認證狀態

BAD－未知命令，或者無效參數

CLOSE命令從當前被選中郵箱中永久刪除帶有/Deleted標記位的所有郵件，並從被選中狀態返回至認證狀態。沒有非標籤化EXPUNGE響應被髮送。

如果郵箱通過EXAMINE命令被選中，或者用別的方法以只讀方式選中，則沒有郵件會被刪除，也不會報錯。

甚至，一個郵箱被選中，沒有預先發送一個CLOSE命令，一個SELECT, EXAMINE, 或者LOGOUT命令就可以被髮出。 SELECT, EXAMINE, 及LOGOUT命令沒有進行刪除，就暗暗關閉了當前被選中的郵箱。然而，當很多郵件被刪除時，一個CLOSE- LOGOUT或者CLOSE-SELECT序列比一個EXPUNGE-LOGOUT或者EXPUNGE-SELECT快得多，因爲沒有非標籤化 EXPUNGE響應（客戶端可以適當忽略）被髮送。

6.4.3. EXPUNGE命令

參數：無

響應：非標籤化響應：EXPUNGE

結果：OK－expunge完成

NO－expunge失敗：不能刪除（例如，沒有權限）

BAD－未知命令，或者無效參數

EXPUNGE命令從當前被選中郵箱中永久刪除帶有/Delted標記位的所有郵件。在返回一個OK到客戶端前，每個被刪除的的郵件會引發一個非標籤化的EXPUNGE響應被髮送。

例子：

C: A202 EXPUNGE

S: * 3 EXPUNGE

S: * 5 EXPUNGE

S: * 8 EXPUNGE

S: A202 OK EXPUNGE complted

注意：在這個例子中，郵件３，４，７，及１１帶/Deleted標記位。進一步的解釋參看EXPUNGE響應的描述。

6.4.4. SEARCH命令

參數：OPTIONAL [CHARSET]聲明，檢索準則（一個或者多個）

響應：REQUIRED非標籤化響應：SEARCH

結果：OK－search完成

NO－search錯誤：不能檢索該[CHARSET]或者準則

BAD－未知命令，或者無效參數

SEARCH命令檢索郵箱以獲取符合給定準則的郵件。檢索準則由一個或者多個檢索關鍵詞組成。來自服務器的非標籤化SEARCH響應由符合檢索準則的郵件相應的郵件序列號列表組成。

當多個關鍵詞被聲明時，結果是匹配這些關鍵詞的所有郵件的交集（並起效）。例如，準則　DELETED FROM “SMITH” SINCE 1-Feb-1994 指向來自Smith的、自從１９９４年２月１日開始存放於郵箱中的所有被刪除的郵件。一個檢索關鍵詞也可以是一個或者多個檢索關鍵詞的一個組合列表（例如，使用OR和NOT關鍵詞）。

服務器實現體可能拒絕接受帶有終端內容媒體類型的[MIM－IMB]主體部分，而接受TEXT和SEARCH匹配集相應的MESSAGE。

OPTIONAL [CHARSET]聲明由其後緊跟着一個註冊了的[CHARSET]的字“CHARSET”組成。它表示，出現在檢索準則中的字符串的[CHARSET]。在以[CHARSET]而不是US-ASCII比較文本之前，[MIME-IMB]內容轉換編碼，及在[RFC- 2822]/[MIME-IMB]頭部的[MIME-HDRS]字符串，必須被解碼。US-ASCII必須受支持；其它的[CHARSET]s可能受支持。

如果服務器不支持聲明瞭的[CHARSET]，它必須返回一個標籤化的NO響應（而不是一個BAD）。該響應應當包含BADCHARSET響應碼，該響應碼可能列出受服務器支持的[CHARSET]s。

在字符串形式的所有檢索關鍵詞裏，如果該字符串是該範圍的一個子串，則郵件符合該關鍵詞。匹配是不區分大小寫的。

已定義的檢索關鍵詞如下。參數的準確語法定義參看正式語法一節。

帶有已聲明的郵件序列號集相應的郵件序列號的郵件。

ALL

郵件中所有郵件；ANDing的默認初始關鍵詞。

ANSWERED

帶有/Answered標記位的郵件。

BCC <string>

在信封結構的BCC域包含有指定字符串的郵件。

BEFORE <date>

實際日期（忽視時間和時區）早於指定日期的郵件。

BODY <string>

在郵件的主體域包含有指定字符串的郵件。

CC <string>

在信封結構的CC域包含有指定字符串的郵件。

DELETED

帶有/Deleted標記位的郵件。

DRAFT

帶有/Draft標記位的郵件。

FLAGGED

帶有/Flagged標記位的郵件。

FROM <string>

在信封結構的FROM域包含有指定字符串的郵件。

HEADER <field-name> <string>

帶有一個含指定field-name（[RFC-2822]中定義）的頭部、且在該頭部（它跟在colon之後）的文本中包含指定字符串的郵件。如果將要檢索的字符串（參數中的string）長度爲零，那麼，它將匹配帶有一個含指定field-name、內容可有可無的頭部行的所有郵件。

KEYWORD <flag>

帶有指定關鍵詞標記位的郵件。

LARGER <n>

帶有一個[RFC-2822]（定義）的、大於指定字節數的大小的郵件。

NEW

帶有/Recent標記位，但不帶有/Seen標記的郵件。它在功能上等效於“(RECENT UNSEEN)”。

NOT <search-key>

不符合指定檢索關鍵詞的郵件。

OLD

不帶有/Recent標記位的郵件。它在功能上等效於“NOT RECENT”（與“NOT NEW”相反）。

ON <date>

實際日期（忽視時間和時區）在指定日期的郵件。

OR <search-key1> <search-key2>

符合任意一個檢索關鍵詞的郵件。

RECENT

帶有/Recent標記位的郵件。

SEEN

帶有/Seen標記位的郵件。

SENTBEFORE <date>

[RFC-2822]Date: header（忽視時間和時區）早於指定日期的郵件。

SENTON <date>

[RFC-2822]Date: header （忽視時間和時區）在指定日期的郵件。

SENTSINCE <date>

[RFC-2822]Date: header （忽視時間和時區）在指定日期或者晚於指定日期的郵件。

SINCE <date>

實際日期（忽視時間和時區）在指定日期或者晚於指定日期的郵件。

SMALLER <n>

帶有一個[RFC-2822]的、小於指定字節數大小的郵件。

SUBJECT <string>

在信封結構的SUBJECT域含有指定字符串的郵件。

TEXT <string>

在郵件的頭部或者主體含有指定字符串的郵件。

TO <string>

在信封結構的TO域含有指定字符串的郵件。

UID <sequence set>

帶有指定唯一標識符集相應的唯一標識符的郵件。序列集順序排列是允許的。

UNANSWERED

不帶有/Answered標記位的郵件。

UNDELETED

不帶有/Deleted標記位的郵件。

UNDRAFT

不帶有/Draft標記位的郵件。

UNFLAGGED

不帶有/Flagged標記位的郵件。

UNKEYWORD <flag>

不帶有指定關鍵詞標記位的郵件。

UNSEEN

不帶有/Seen標記位的郵件。

例子：

C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM “Smith”

S: * SEARCH 2 84 882

S: A282 OK SEARCH completed

C: A283 SEARCH TEXT “string not in mailbox”

S: * SEARCH

S: A283 OK SEARCH completed

C: A284 SEARCH CHARSET UTF-8 TEXT {6}

C: XXXXXX

S: * SEARCH 43

S: A284 OK SEARCH completed

注意：因爲本文檔限制於７位ASCII文本，所以不可能顯示真的UTF－８。“XXXXXX”可能是實際處理中的８位數據的６個字節。

6.4.5. FETCH命令

參數：序列集，郵件數據項名稱或者宏

響應：非標籤化響應：FETCH

結果：OK－fetch完成

NO－fetch錯誤：不能獲取該數據

BAD－未知命令，或者無效參數

FETCH命令獲取郵箱中的一個郵件的相關數據。被獲取的數據項可以是一個原語，或者一個組合列表。

在正式語法中基於msg-att-static規則確認的大部分數據項，是靜態的，並且不能因爲任意特定郵件而改變。在正式語法中msg-att-static規則確認的其它數據項，可以改變，或者作爲一個STORE命令的一個結果，或者因爲外部事件。

例如，如果一個客戶端接收到它已經知道的、一個郵件的一個信封，它可以安全地忽略新傳送的信封。

有三種宏，它們指明數據項的普遍使用集，並能代替數據項使用。一個宏必須被自身所用，並且不能與其它宏或者數據項連接。

ALL

等效於：(FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)

FAST

等效於：(FLAGS INTERNALDATE RFC822.SIZE)

FULL

等效於：(FLAGS INTERNALDATE RFC822.SIZE ENVELOPE BODY)

現在已經定義的、可以被獲取的數據項有：

BODY

BODYSTRUCTURE的不可擴展形式。

BODY[<section>]<<partial>>

特定主體塊的文本。塊聲明是一個零的集合，或者根據時間分隔開的更多塊聲明。一個塊聲明或者是一個塊號，或者是以下的一個：HEADER，HEADER.FIELDS，HEADER.FIELDS.NOT，MIME，及TEXT。一個空的塊聲明指向整個郵件，包括頭部。

每個郵件有至少一個塊號。Non-[MIME-IMB]郵件，及不帶內嵌郵件的non-multipart[MIME-IMB]郵件，只有一個塊１。

郵件簇被分配連續的塊號，如果它們出現在郵件中。如果一個特定塊的類型是郵件或者郵件簇，則這個塊後面必須跟着它在塊簇中的塊號的時間。

一個類型爲MEEAGE/RFC822類型的塊也有塊號，指向MESSAGE塊域的塊集。

HEADER，HEADER.FIELDS，HEADER.FIELDS.NOT，及TEXT塊聲明可能是單個塊聲明，也可能是以一個或者多個數字型的塊聲明爲前綴――其前提是該數字型的塊聲明指向一個MESSAGE/RFC822類型的塊。MIME塊聲明必須以一個或者多個數字型的塊聲明爲前綴。

HEADER，HEADER.FIELDS，及HEADER.FIELDS.NOT塊聲明指向郵件的[RFC-2822]頭部，或者一個內嵌 [MIME-IMT] MESSAGE/RFC822郵件。HEADER.FIELDS和HEADER.FIELDS.NOT其後跟着field- name（[RFC-2822]中有定義）名稱的一個列表，並返回頭部的一個子集。HEADER.FIELDS返回的子集只包括那些帶有與列表中的名稱之一相符的一個field-name的頭部域；類似地，HEADER.FIELDS.NOT返回的子集只包含帶有一個不匹配域名稱的頭部域。域匹配是不區分大小寫的，除非用別的方法強制。子集化並不把[RFC-2822]定義的、頭部和主體之間的空行排除在外；空行包含在所有頭部獲得中，除非一個郵件沒有主體也沒有空行。

MIME塊聲明指向該塊的[MIME-IMB]頭部。

TEXT塊聲明指向郵件的文本主體，不包括[RFC-2822]頭部。

這是一個帶有它的一些塊聲明的複雜郵件的一個例子：

HEADER ([RFC-2822] header of the message)

TEXT ([RFC-2822] text body of the message) MULTIPART/MIXID

1 TEXT/PLAIN

2 APPLICATION/OCTET-STREAM

3 MESSAGE/RFC2822

3.HEADER ([RFC-2822] header of the message)

3.TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED

3.1 TEXT/PLAIN

3.2 APPLICATION/OCTET-STREAM

4 MULTIPART/MIXED

4.1 IMAGE/GIF

4.1.MIME ([MIME-IMB] header for the IMAGE/GIF)

4.2 MESSAGE/RFC822

4.2.HEADER ([RFC-2822] header of the message)

4.2.TEXT ([RFC-2822] text body of the message) MULTIPART/MIXID

4.2.1 TEXT/PLAIN

4.2.2 MULTIPART/ALTERNATIVE

4.2.2.1 TEXT/PLAIN

4.2.2.2 TEXT/RICHTEXT

獲取指定文本的一個子串是可能的。這是通過添加一個開的角符（“〈”），請求的第一個字節位置，一個時間，請求的字節的最大數，及一個閉的角符（“〉”）到塊聲明，來實現的。如果起始字節超出了文本的末尾，則返回一個空的字符串。

試圖讀取超出文本末尾內容的任何局部獲取都會被適當截斷。從第０字節開始的一個局部獲取都返回局部獲取，即使這種截斷髮生。

注意：這意味着一個1500字節的郵件的BODY[]<0.2048>將返回帶有一個大小１５００的原義的BODY[]<0>，而不是BODY[]。

注意：一個HEADER.FIELDS或者HEADER.FIELDS.NOT塊聲明的一個子串獲取，在子集化頭部之後計算。

/Seen標記是隱含標記；如果這導致標記改變，它們應當作爲FETCH響應的一部分被包含進來。

BODY.PEEK[<section>]<<partial>>

BODY[<section>]的一個替代形式，它不會暗暗設置/Seen標記。

BODYSTRUCTURE

郵件的[MIME-IMB]主體結構。它的計算是由服務器把[MIME-IMB]頭部域解釋爲[RFC-2822]頭部和[MIME-IMB]頭部。

ENVELOPE

郵件的信封結構。它的計算是由服務器把[RFC-2822]頭部解釋爲組件塊，默認爲所需要的多個域。

FLASG

爲該郵件設置的標記。

INTERNALDATE

郵件的實際日期。

RFC822

功能上等效於BODY[]，不同的是，其結果的非標籤化FETCH數據（返回RFC822）的語法。

RFC822.HEADER

功能上等效於BODY.PEEK[HEADER]，不同的是，其結果的非標籤化FETCH數據（返回RFC822.HEADER）的語法。

RFC822.SIZE

郵件的[RFC-2822]大小。

RFC822.TEXT

功能上等效於BODY[TEXT]，不同的是，其結果的非標籤化FETCH數據（返回RFC822.TEXT）的語法。

UID

郵件的唯一標識符。

例子：

C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])

S: * 2 FETCH ….

S: * 3 FETCH ….

S: * 4 FETCH ….

S: A654 OK FETCH completed

6.4.6. STORE命令

參數：序列集，郵件數據項名稱，郵件數據項值

響應：非標籤化響應：FETCH

結果：OK－store完成

NO－store錯誤：不能保存該數據

BAD－未知命令，或者無效參數

STORE命令修改郵箱中郵件相關的數據。正常地，STORE將返回數據更新後的值和一個非標籤化FETCH響應。數據項名稱中的“.SILENT”後綴保護該非標籤化FETCH，且服務器應當假定客戶端已經自行決定了該更新後的值，或者客戶端不關心該更新後的值。

注意：不管是否使用了“.SILENT”後綴，如果發現一個郵件的標記有源於外部資源的改變，服務器應當發送一個非標籤化FETCH響應。目的是使標記的狀態在沒有競爭的情況下確定。

現在已經定義了的、可以保存的數據項有：

FLAGS <flag list>

用參數替代郵件（不是/Recent）的標記。返回標記集的新值，就像那些標記集的FETCH結果一樣。

FLAGS.SILENT <flag list>

等效於FLAGS，但是不會返回一個新值。

+FLAGS <flag list>

增加參數至郵件的標記集中。返回標記集的新值，就像那些標記集的FETCH結果一樣。

-FLAGS <flag list>

從郵件的標記集中刪除參數。返回標記集的新值，就像那些標記集的FETCH結果一樣。

-FLAGS.SILENT <flag list>

等效於-FLAGS，但是不會返回一個新值。

例子：

C: A003 STORE 2:4 +FLAGS (/Deleted)

S: * 2 FETCH (FLAGS (/Deleted /Seen))

S: * 3 FETCH (FLAGS (/Deleted))

S: * 4 FETCH (FLAGS (/Deleted /Flagged /Seen))

S: A003 OK STORE completed

6.4.7. COPY命令

參數：序列集，郵箱名

響應：此命令無需特定響應

結果：OK－copy完成

NO－copy錯誤：不能複製那些郵件，或者複製到那個名稱

BAD－未知命令，或者無效參數

COPY命令複製指定郵件到特定目標郵箱的末尾。在拷貝件中，郵件的標記和實際日期應當被保存，且Recent標記應當被設置。

如果目標郵箱不存在，服務器應當返回一個錯誤。它不應當自動創建郵箱。除非確實不能創建目標郵箱，否則服務器必須發送響應碼 “[TRYCRETAE]”作爲標籤化NO響應的文本前綴。這暗示客戶端，它可以嘗試一個CREATE命令，並且如果CREATE成功，它可以重試 COPY。

如果COPY命令因爲某種原因不能成功，服務器實現體必須恢復目標郵箱狀態到COPY嘗試之前的狀態。

例子：

C: A003 COPY 2:4 MEETING

S: A003 OK COPY completed

6.4.8. UID命令

參數：命令名，命令參數集

響應：非標籤化響應：FETCH，SEARCH

結果：OK－UID命令完成

NO－UID命令錯誤

BAD－未知命令，或者無效參數

UID命令有兩種形式。在第一種形式中，它的參數是一個帶有相應的一些適當參數的COPY，FETCH，或者STORE命令。不過，參數序列中的數字是唯一標識符，而不是郵件序列號。序列集是許可的，但是有可能唯一標識符不是連續的。

一個不存在的唯一標識符將被忽略，而不會產生任何錯誤信息。一個UID FETCH命令可能只返回一個OK，沒有任何數據；一個UID COPY或者UID STORE可能只返回一個OK，沒有任何操作。

在第二種形式中，UID命令的參數是一個帶有SEARCH命令參數的SEARCH命令。這些參數的解釋同於它們僅僅跟着SEARCH；但是，一個UID SEARCH命令的一個SEARCH響應返回的數字是唯一標識符，而不是郵件序列號。例如，命令 UID SEARCH 1:100 UID 443:557返回的是，郵件序列的數字隊列1:100，及UID隊列443:557，這兩個序列集的交集相應的唯一標識符。

注意：在上面的例子中，出現了UID隊列443:557。一個不存在的唯一標識符會被忽略，而不會產生任何錯誤信息，同樣的解釋也適用於此。因此，即使UID443或者557不存在，這個隊列也是有效的，且可以包含一個存在的UID495。

還要注意，一個UID隊列559:*永遠包括郵箱中最末郵件的UID，即使559大於已分配的任何UID值。這是因爲一個隊列的內容獨立於隊列末點的順序。因此，以*作爲一個末點的任意UID隊列表示至少一個郵件（該郵件的UID是最大的），除非這個郵箱是空的。

一個非標籤化FETCH響應中的“*”後的數字永遠是一個郵件序列號，而不是一個唯一標識符，甚至對於一個UID命令響應也是如此。然而，服務器實現體必須隱式地包括UID郵件數據項作爲一個UID命令引發的任意FETCH的響應部分，不管一個UID是否被指定爲一個到FETCH的郵件數據項。

注意：包括一個UID郵件數據項作爲一個FETCH的響應部分，這個規則主要適用於UID FETCH和UID STORE命令，包括一個不含 UID作爲一個郵件數據項的UID FETCH命令。儘管其它UID命令不太可能引發一個非標籤化的FETCH，但是這個規則也適用於這些命令。

例子：

C: A999 UID FETCH 4827313:4828442 FLAGS

S: * 23 FETCH (FLAGS (/Seen) UID 4827313)

S: * 24 FETCH (FLAGS (/Seen) UID 4827943)

S: * 25 FETCH (FLAGS (/Seen) UID 4828442)

S: A999 OK UID FETCH completed

6.5. 客戶端命令－試驗/擴展

6.5.1. X<atom>命令

參數：已定義的實現體

響應：已定義的實現體

結果：OK－命令完成

NO－失敗

BAD－未知命令，或者無效參數

任何以一個X爲前綴的命令都是一個試驗命令。不屬於本文檔、本文檔的標準修正版或者一個IESG認證的試驗標準的一部分的命令，必須用X作爲前綴。

任何增加的、一個試驗命令引發的非標籤化響應也必須以一個X作爲前綴。服務器實現體不能發送任何這樣的非標籤化響應，除非客戶端通過發出關聯的試驗命令來請求它。

例子：

C: a441 CAPABILITY

S: * CAPABILITY IMAP4rev1 XPIG-LATIN

S: a441 OK CAPABILITY completed

C: A442 XPIG-LATIN

S: * CAPABILITY IMAP4rev1 XPIG-LATIN

S: a441 OK CAPABILITY completed

C: A442 XPIG-LATIN

S: * XPIG-LATIN ow-nay eaking-spay ig-gay atin-lay

S: A442 OK XPIG-LATIN ompleted-cay

7.服務器響應

服務器響應有三種形式：狀態響應，服務器數據，及命令連續請求。一個服務器響應中的信息，在下面的響應描述中定義的“內容：”，通過功能，而不是語法來描述。服務器響應的精確語法在正式語法一節中有描述。

客戶端必須一直準備着接收任何響應。

狀態響應可以是標籤化或者非標籤化的。標籤化的狀態響應表示一個客戶端命令的完成結果（OK，NO，或者BAD狀態），並且有一個與該命令匹配的標籤。

某些狀態響應，及所有的服務器數據，是非標籤化的。一個非標籤化的響應用一個“*”記號而不是一個標籤來表示。非標籤化的狀態響應表示服務器歡迎，或者那些不表示一個命令完成的服務器狀態（例如，一個緊急系統關機警告）。因爲歷史原因，非標籤化服務器數據響應也被稱爲“主動提供的數據”，雖然嚴格地講，只有單方面服務器數據是真正的“主動提供的數據”。

某些服務器數據，當客戶端接收到它們的時候，必須被記錄下來；它被記到那些數據的描述裏。這些數據承載着影響到所有後來的命令和響應的解釋的緊急信息（例如，創建或者銷燬郵件相關的更新）。

其它的服務器數據應當記錄以便以後參考；如果客戶端不需要記錄這些數據，或者沒有明顯的意圖要記錄這些數據（例如，沒有其它SEARCH命令在行進中時的一個SEARCH響應），那麼就應當忽略這些數據。

當IMAP連接在選中狀態時，單方面的、非標籤化的服務器數據的一個例子就發生了。在選中狀態，服務器確認郵箱的新郵件，這作爲命令執行的一部分。通常，這是任何一個命令的執行的一部分；因此，一個NOOP命令就可以確認新郵件。如果發現新郵件，服務器發送非標籤化的、反映郵箱的新大小的 EXISTS和RECENT響應。經常有不同的連接至相同郵箱的服務器實現體，如果另外的代理改變任意郵件標記的狀態或者刪除任意郵件，它也應當發送適當的、單方面的、非標籤化FETCH和EXPUNGE響應。

命令的連續請求響應使用標記“+”取代一個標籤。這些響應由服務器發送，以確信一個不完整的客戶端命令和命令的剩餘部分的準備就緒。

7.1. 服務器響應－狀態響應

狀態響應是OK，NO，BAD，PREAUTH和BYE。OK，NO，和BAD可以是標籤化或者非標籤化的。PREAUTH和BYE永遠是非標籤化的。

服務器響應可能包含一個可選的“響應碼”。一個響應碼由一個原語形式的四方形內的數據組成，可能後面跟着一個空格和參數。響應碼爲客戶端軟件包含其它信息或者狀態碼，而不只是OK/NO/BAD的情況，它定義於，當出現一個已經定義的、客戶端基於該額外信息可採用的動作時。

目前已定義的響應碼有：

ALERT

可讀文本，包含一個警告，這個警告必須以一種喚起用戶對該郵件的注意的式樣展現給用戶。

BADCHARSET

後面隨意地跟着字符集的一個組合列表。給定的字符集不被這個實現體支持時，一個SEARCH就失敗了。如果字符集的選擇列表給定了，那麼這就列出被這個實現體支持的字符集。

CAPABILITY

後面跟着功能的一個列表。這將會出現在初始的OK或者PREAUTH響應，以傳送一個初始的功能列表。這使得沒必要讓一個客戶端發送一個單獨的CAPABILITY命令，如果它認出了這個響應。

PARSE

可讀文本，描繪解析郵箱中的一個郵件的[RFC-2822]頭部或者[MIME－IMB]頭部時的一個錯誤。

PERMANENTFLAGS

後面跟着標記的一個組合列表，指明客戶端可以永久修改的已知標記。在FLAGS非標籤化響應中，但不在PERMANENTFLAGS列表中的任何標記，不能被永久性地設置。如果客戶端試圖存儲一個不在PREMANENTFLAGS列表中的標記，服務器或者忽略該修改，或者只存儲當前會話的剩餘部分的狀態修改。PERMANENTFLAGS列表也可以包括特殊的標記/*，它表明可以通過嘗試存儲郵箱中的那些標記，來創建新的關鍵詞。

READ-ONLY

郵箱以只讀方式選中，或者當被選中時它的連接已經從讀寫方式改變爲只讀方式了。

READ-WRITE

郵箱以讀寫方式選中，或者當被選中時它的連接已經從只讀方式改變爲讀寫方式了。

TRYCREATE

一個APPEND或者COPY嘗試失敗，因爲目標郵箱不存在（與其它一些原因相反）。這是對客戶端的一個提示，如果郵箱先通過CREATE命令被創建，這個操作就能夠成功。

UIDNEXT

後面跟着一個十進制的數字，指明下一個唯一標識符的值。更多信息參考2.3.1.1一節。

UIDVALIDITY

後面跟着一個十進制的數字，指明唯一標識符的值。更多信息參考2.3.1.1一節。

UNSEEN

後面跟着一個二進制的數字，指明不帶有/Seen標記位的第一個郵件的號數。

定義於特定的客戶端或者服務器實現體的擴展響應碼應當以一個“X”作爲前綴，直到它們被加到這個協議的一個版本中來。客戶端實現體應當忽略其不認識的響應碼。

7.1.1. OK 響應

內容：OPTIONAL響應碼，可讀文本

OK響應指明來自服務器的一個信息郵件。其標籤化時，它指明關聯命令的成功完成。可讀文本可能作爲一個信息郵件展現給用戶。其非標籤化形式指明一個純信息的郵件；信息的各類可能通過一個響應碼來指明。

其非標籤化形式也用於連接啓動時的三個可能歡迎中的一個。它指明該連接是未認證的，且需要一個LOGIN命令。

例子：

S: * OK IMAP4rev1 server ready

C: A001 LOGIN fred blurdybloop

S: * OK [ALERT] System shutdown in 10 minutes

S: A001 OK LOGIN Completed

7.1.2. NO響應

內容：OPTIONAL響應碼，可讀文本

NO響應指明來自服務器的一個錯誤。其標籤化時，它報告客戶端命令的一個協議級的錯誤；標籤指明導致該錯誤的命令。其非標籤化形式指明關聯命令不能抉擇的一個協議級錯誤；它也指明一個內部服務器失敗。可讀文本描述了這種情況。

例子：

C: … very long command line…

S: * BAD Command line too long

C: …empty line …

S: * BAD Empty command line

C: A443 EXPUNGE

S: * BAD Disk crash, attempting salvage to a new disk!

S: * OK Salvage successful, no data lost

S: A443 OK Expunge completed

7.1.3. BAD響應

內容：OPTIONAL響應碼，可讀文本

BAD響應指明來自服務器的一個錯誤。其標籤化時，它報告客戶端命令的一個協議級的錯誤；標籤指明導致該錯誤的命令。其非標籤化形式指明關聯命令不能抉擇的一個協議級錯誤；它也指明一個內部服務器失敗。可讀文本描述了這種情況。

例子：

C: …very long command line…
S: * BAD Command line too long
C: …empty line…
S: * BAD Empty command line
C: A443 EXPUNGE
S: * BAD Disk crash, attempting salvage to a new disk!
S: * OK Salvage successful, no data lost
S: A443 OK Expunge completed

7.1.4. PREAUTH響應

內容：OPTIONAL響應碼，可讀文本

PREAUTH響應永遠是非標籤化的，且是連接啓動時三種可能歡迎中的一種。它指明連接已經通過外部手段認證了；因而不需要LOGIN命令。

例子：

S: * PREAUTH IMAP4rev1 server logged in as Smith

7.1.5. BYE響應

內容：OPTIONAL響應碼，可讀文本

BYE響應永遠是非標籤化的，且指明該服務器準備關閉連接。可讀文本可能被客戶端用一個狀態報告呈現給用戶。BYE響應在以下４種情形下的一種發送：

１）作爲一個正常註銷隊列的一部分。服務器將在發送標籤化的OK響應至LOGOUT命令後，關閉連接。

２）作爲一個突然關機的公告。服務器突然關掉連接。

３）作爲一個靜止狀態的自動註銷的一個公告。服務器突然關掉連接。

４）作爲連接開始時的三種可能歡迎的一個，表明服務器不願接收來自該客戶端的連接。服務器突然關掉連接。

作爲一個正常的註銷序列（第一種情況）的一部分發生的一個BYE，及因爲一個失敗（其它的情況）發生的一個BYE，兩者的區別是，在失敗的情況下連接突然關掉。在所有情況下，客戶端都應當繼續讀取來自服務器的響應數據，直到連接關閉；這將確保任何未決的、非標籤化的，或者完成了的響應被讀取及處理。

例子：

S: * BYE Autologout; idle for too long

7.2. 服務器響應－服務器和郵箱狀態

這些響應永遠是非標籤化的。這是服務器和郵箱的狀態數據如何被從服務器傳送至客戶端（的所在）。這些響應的一個特點是，很多因爲來自一個命令而有相同的名字。

7.2.1. CAPABILITY響應

內容：capability列表

CAPABILITY響應作爲一個CAPABILITY命令的一個結果發生。capability列表包含一個用空格分隔的、服務器支持的功能列表。功能列表必須包含原語“IMAP4rev1”。

另外，客戶端和服務器實現體必須實現STARTTLS，LOGINDISABLED，及AUTH=PLAIN（描述於[IMAP-TLS]）功能。重要信息參看安全考慮一節。

以“AUTH=”開頭的一個功能名錶明服務器支持這種特別的認證機制。

LOGINDISABLED功能表明LOGIN命令是不可用的，並且，即使用戶名和密碼是正確的，服務器也將會以一個標籤化的NO響應作爲使用 LOGIN命令的任何嘗試的響應。如果服務器宣告LOGINDISABLED功能，那麼一個IMAP客戶端就不能發送LOGIN命令。

其它的功能名錶明服務器支持IMAP4rev1協議的一個擴展，修訂版，或者改善版。服務器響應必須遵守本文檔，直至客戶端發送一個使用關聯功能的命令。

功能名必須以“X”開頭，或者是標準的，或者是標準的IMAP4rev1擴展，修訂版，或者在IANA註冊的改善版。一個服務器不能提供未註冊的，或者非標準的功能名，除非這些名稱以“X”爲前綴。

客戶端不應當請求“IMAP4rev１”以外的任何功能名，而且必須忽略任何未知的功能名。

通過在初始PREAUTH時使用一個CAPABILITY響應碼，或者使用OK響應，通過發送標籤化的OK響應中的一個更新的 CAPABILITY響應作爲一個成功認證的一部分，服務器就可以自動地發送功能。如果客戶端識別出了這些自動的功能，它就沒必要發送一個單獨的 CAPABILITY命令。

例子：

S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI XPIG-LATIN

7.2.2. LIST響應

內容：名稱屬性，層級分隔符，名稱

LIST響應作爲一個LIST命令的一個結果發生。它返回符合LIST描述的一個單獨的名稱。一個單獨的LIST命令可能會有多個LIST響應。

有四個名稱屬性被定義：

/Noinferiors

該名稱下不可能存在任何子層；現在沒有子層，以後也不能創建。

/Marked

郵箱已經被服務器標記爲“受關注的”；上次被選中後，這個郵箱大概有新的郵件加進來。

/Unmarked

自從被選中後，這個郵箱就沒有加進新的郵件。

如果對服務器來說判斷郵箱是否是“受關注的”、或者其名稱是否是一個/Noselect名稱並不切實可行，則服務器不應當發送/Marked或者/Unmarked。

層級分隔符是用來分隔一個郵箱名稱的層級的一個字符。一個客戶端可以用它來創建子郵箱，及檢索名稱層級的更高級或者更低級。一個頂層節點的所有孩子必須使用相同的分隔符。一個NIL層級分隔符意味着不存在層級；即名稱都在一層。

名稱展現爲明確的從左至右的層級，並且，用作LIST和LSUB命令的一個參考時必須是正確的。除非/Noselect被指明，否則，用作命令（如SELECT，接受郵箱名）的參數時，名稱必須是正確的。

例子：

S: * LIST (/Noselect) “/” ~/Mail/foo

7.2.3. LSUB響應

內容：名稱屬性，層級分隔符，名稱

LSUB響應作爲一個LSUB命令的一個結果發生。它返回符合LSUB描述的一個單獨的名稱。一個單獨的LSUB命令可以有多個LSUB響應。LIST響應的數據形式是一樣的。

例子：

S: * LSUB () “.” #news.comp.mail.misc

7.2.4. STATUS響應

內容：名稱，狀態組合列表

STATUS響應作爲一個STATUS命令的一個結果發生。它返回符合STATUS描述和請求的郵箱狀態信息的郵箱名。

例子：

S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)

7.2.5. SEARCH響應

內容：０個或者更多個數字

SEARCH響應作爲一個SEARCH或者UID SEARCH命令的一個結果發生。這些數字指向那些符合檢索標準的郵件。對SEARCH，這些是郵件序列號；對UID SEARCH，這些是唯一標識符。每個數字被一個空格分開。

例子：

S: * SEARCH 2 3 6

7.2.6. FLAGS響應

內容：標記組合列表

FLAGS響應作爲一個SELECT或者EXAMINE命令的一個結果發生。標記組合列表確定適用於該郵箱的標記（至少，系統定義的標記）。系統標記以外的標記也可以存在，這取決於服務器實現體。

來自FLAGS響應的更新必須被客戶端記錄。

例子：

S: * FLAGS (/Answered /Flagged /Deleted /Seen /Draft)

7.3. 服務器響應－郵箱大小

這些響應永遠是非標籤化的。這是郵箱大小的改變怎樣被從服務器傳送至客戶端的（的所在）。後面直接跟着“*”符號的是表示一個郵件數量的數字。

7.3.1. EXISTS響應

內容：無

EXISTS響應報告郵箱中的郵箱數量。這個響應作爲一個SELECT或者EXAMINE命令，及郵箱大小是否改變的一個結果發生（例如，新郵件）。

來自EXISTS響應的更新必須被客戶端記錄。

例子：

S: * 23 EXISTS

7.3.2. RECENT響應

內容：無

RECENT響應報告帶有/Recent標記位的郵件的數量。這個響應作爲一個SELECT或者EXAMINE命令，及郵箱大小是否改變的一個結果發生（例如，新郵件）。

注意：新近郵件的郵件序列號不一定是郵箱中的最高n個郵件的一個連續隊列（該郵箱中，n是被RECENT響應報告的數值）。　例子：多個客戶端打開了同一個郵箱（第一個被通報的會話將視其爲新近的，其它的會話將視其爲非新近的，及當郵箱被一個非IMAP代理重新排序時）。

辨別新近郵件的唯一可靠方法是察看郵件標記，看哪個帶有/Recent標記位，或者做一個SEARCH RECENT。

來自RECENT響應的更新必須被客戶端記錄。

例子：

S: * 5 RECENT

7.4. 服務器響應－郵件狀態

這些響應永遠是非標籤化的。這是郵件數據如何被從服務器傳送至客戶端（的所在）。它經常被作爲帶有相同名稱（參數）的一個命令的一個結果。後面直接跟着“*”符號的，是表示一個郵件序列號的一個數字。

7.4.1. EXPUNGE響應

內容：無

EXPUNGE響應報告指定郵件序號已經被從郵件中永久刪除了。郵箱中每一個後續的郵件的郵件序列號都馬上減1，且這個減小反映在後來的響應中的郵件序列號（包括其它非標籤化的EXPUNGE響應）。

EXPUNGE響應也減小郵箱中的郵件數量；沒必要發送一個帶有新值的EXISTS響應。

作爲即時減少規則的一個結果，出現在成功的EXPUNGE響應的一個集合中的郵件序列號，取決於郵件是按由小到大的順序刪除，還是按由大到小的順序刪除。例如，假如一個有９個郵件的郵箱中的最後５個郵件被刪除，一個“由小到大”的服務器將會發送５個非標籤化EXPUNGE響應至郵件序列號５，而一個“由大到小”的服務器將會發送成功的非標籤化EXPUNGE響應至郵件序列號９，８，７，６，及５。

當沒有命令在行進中時，或者正在響應一個FETCH,STORE,或者SEARCH命令時，不能發送一個EXPUNGE。爲避免客戶端和服務器之間的郵件序列號的同步造成丟失，這是有必要的。一個命令不是“在行進中”的，直到已經接收到完成命令；特別的，在命令連續的競爭中，一個命令不是“在行進中”的。

注意：UID FETCH,UID STORE,及UID SEARCH是不同於FETCH,STORE,及SEARCH的命令。一個EXPUNGE響應可以在一個UID命令期間發送。

來自EXPUNGE響應的更新必須被客戶端記錄。

例子：

S: * 44 EXPUNGE

7.4.2. FETCH響應

內容：郵件數據

FETCH響應返回客戶端的一個郵件的相關數據。這些數據是名稱項及其值的數據對，這些對分別被放在一個圓括號中。這個響應作爲一個FETCH或者STORE命令的結果發生，也可以因爲單方面的服務器決定發生（例如，標記更新）。

目前的數據項有：

BODY

BODYSTRUCTURE的一種形式，不帶額外數據。

BODY[<section>]<<origin octect>>

表示指定塊的主體內容的一個字符串。它應當被客戶端通過內容轉換編碼，主體類型，及子類型來解釋。

如果原始字節被指定，則該字符串是整個主體內容的一個子字符串，它從那個原始字節開始。這意味着，BODY[]<0>可能是被切斷的，而BODY[]是不切斷的。

注意：這個原始字節的方法不能被一個服務器在一個FETCH響應中使用，除非客戶端通過一個BODY[<section>]<<partial>>數據項的一個FETCH特意地請求它。

如果一個[CHARSET]標識符是這個塊的主體參數組合列表的一部分，則８位文本數據是允許的。注意，頭部（部分指HEADER或者 MIME，或者一個MESSAGE/RFC822部分的頭部），必須是７位的；８位字符在頭部中是不允許的。還要注意，頭部和主體間的[RFC- 2822]分隔用空行並不見效於頭部行的子集；該空行永遠被作爲頭部數據的一部分被包含進來，除非郵件沒有主體和空行。

非文本數據，如二進制數據，在傳至客戶端之前，必須轉換編碼爲文本形式，如BASE64。客戶端必須對轉換編碼的字符串解碼，以得到原始的二進制數據。

BODYSTRUCTURE

描述一個郵件的[MIME-IMB]主體結構的一個組合列表。它是由服務器通過解析[MIME-IMB]頭部域，必要情況下還包括各種默認域，計算出的。

例如，一個４８行，２２７９字節的一個簡單文本郵件有一個主體結構：(“TEXT” “PLAIN” (“CHARSET” “US- ASCII”) NIL NIL “7BIT” 2279 48)。多個部分被表示爲組合巢。一個或者多個巢狀主體結構的一個序列，代替了作爲組合列表的第一元素的一個主體類型。組合列表的第二個元素是多個子表（混合的，相減的，平行的，二擇一的，等等）。

例如，由一個文本和一個BASE64編碼的文本附件組成的一個兩部分郵件，可以有一個主體結構： ((“TEXT” “PLAIN” (“CHARSET” “US-ASCII”) NIL NIL “7BIT” 1152 23)(“TEXT” “PLAIN” (“CHARSET” “US-ASCII” “NAME” “cc.diff”)”[email protected]” “Compiler diff” “BASE64” 4554 73) “MIXED”)

擴展數據遵從多個子表。擴展數據不會與BODY獲取返回，但是可以與一個BODYSTRUCTURE獲取返回。擴展數據，如果出現，必須是按被定義的順序。一個多域主體擴展數據有以下順序：

主體參數組合列表

屬性/值對的一個組合列表　[例如，”（foo” “bar” “baz” “rag”）其中“bar”是“foo”的值，“rag”是“baz”的值]　，如[MIME-IMB]所定義的。

主體部署

一個組合列表，由一個部署類型的字符串組成，其後跟着部署屬性/值對的一個組合列表，如[DISPOSITION]所定義的。

主體語言

給出了主體語言值的一個字符串或者組合列表，如[LANGUAGE-TAGS]所定義的。

主體定位

給出了主體內容的URI的一個字符串列表，如[LOCATION]所定義的。

在該協議的這個版本中，還沒有定義後來的擴展數據的任何一個。這些擴展數據可以包括０或者更多的NIL，字符串，數字，或者這些數據的潛在巢狀組合列表。執行一個BODYSTRUCTURE獲取的客戶端實現體必須有所準備地接收這些擴展數據。服務器實現體不能發送這些擴展數據，直到它已經被該協議的一個修訂版所定義。

一個非多域主體部分的基本域有以下順序：

主體類型

給出了內容媒體類型的一個字符串，如[MIME-IMB]所定義的。

主體子類型

給出了內容的子類型的一個字符串，如[MIME-IMB]所定義的。

主體參數組合列表

屬性/值對的一個組合列表[例如，(“foo” “bar” “baz” “rag”)其中，”bar”是”foo”的值，”rag’是”baz”的值]，如[MIME-IMB]所定義的。

主體號

給出了內容號的一個字符串，如[MIME-IMB]所定義的。

主體描述

給出了內容描述的一個字符串，如[MIME-IMB]所定義的。

主體編碼

給出了內容轉換編碼的一個字符串，如[MIME-IMB]所定義的。

主體大小

給出了主體的字節大小的一個數字。注意，這個大小是其轉換編碼中的大小，而不是任何解碼結果後的大小。

MESSAGE類型和子類型的一個主體類型包括，基本域後緊跟的信封結構，主體結構，及壓縮郵件的文本行大小。

TEXT類型的一個主體類型包括，基本域後緊跟的、文本行中的主體大小。注意，這個大小是其內容轉換編碼中的大小，而不是任何解碼結果後的大小。

擴展數據跟着基本域和以上指定類型的域列表。擴展數據不會與BODY獲取返回，但是可以與BODYSTRUCTURE獲取返回。擴展數據，如果出現，必須按定義的順序。

一個非多域主體部分的擴展數據有以下的順序：

主體MD5

給出了主體MD5值的一個字符串，如[MD5]所定義的。

主體部署

一個組合列表，它與針對一個多域主體部分的主體部署有同樣的內容和功能。

主體語言

給出了主體語言值的一個字符串或者組合列表，如[LANUAGE-TAGS]所定義的。

主體定位

給出了主體內容URI的一個字符串列表，如[LOCATION]所定義的。

該協議的這個版本還沒有定義任何下列擴展數據，它們可能如上面所描述的，屬於多域擴展數據。

ENVELOPE

描述了一個郵件的信封結構的一個組合列表。這是由服務器通過解析[RFC-2822]頭部爲組件部分來算出的，默認爲所需要的多種域。

信封結構的域有以下順序：日期，主題，寄信方，收信方，回覆至，送至，抄送，祕密抄送，轉送至，及郵件號。日期，主題，轉送至，及郵件號是字符串。寄信方，收信方，回覆至，送至，抄送，及祕密抄送域是地址結構的組合列表。

一個地址結構是描述一個電子郵件地址的一個組合列表。一個地址結構的域有以下的順序：個人名稱，[SMTP]域列表（路由），郵件名，及主機名。

[RFC-2822]聚合語法由主機名爲NIL的一種特殊的地址結構形式指明。如果郵箱名域也是NIL，那麼這是聚合的一個末尾（RFC822語法中的分號）。如果郵箱名域是非NIL的，那麼這是聚合的一個開始，且郵箱名域中有聚合名稱。

如果日期，主題，轉送至，及郵件號頭部行不出現在[RFC-2822]頭部中，那麼信封的相關成員爲NIL；如果這些頭部行出現了但是爲空，那麼信封的相關成員是空字符串。

注意：在“出現了但是爲空“的情況下，一些服務器可能返回一個NIL信封成員。客戶端應當將NIL和空字符串看成是一樣的。

注意：[RFC-2822]要求所有郵件有一個正確的日期頭部。因此，信封中的日期成員不能爲NIL或者空字符串。

注意：[RFC-2822]要求，轉送至和郵件號頭部，如果出現了，就要有非空的內容。因此，信封中的轉送至和郵件號成員不能是空字符串。

如果寄信方，收信方，抄送，及祕密抄送頭部行出現在[RFC-2822]頭部中，或者出現了但爲空，則信封的相關成員爲NIL。

如果發送方或者轉送至的行出現在[RFC-2822]頭部，或者出現了但爲空，則服務器將信封的相關成員設置爲與寄信方一樣的值（不要求客戶端獲知這一點）。

注意：[RFC-2822]要求，所有的郵件都有一個正確的寄信方頭部。因此，信封中的寄信方，發送方，及回覆至等成員不能爲NIL。

FLAGS

爲該郵件設置的標記的一個組合列表。

INTERNALDATE

表示郵件的實際日期的一個字符串。

RFC822

等效於BODY[]。

RFC822.HEADER

等效於BODY[HEADER]。注意，它不會引起/Seen被設置，因爲RFC822.HEADER響應數據是作爲 RFC822.HEADER的一個FETCH的一個結果發生的。BODY[HEADER]響應數據是作爲BODY[HEADER] （引起/Seen的設置）或者BODY.PEEK[HEADER]（不會引起/Seen的設置）的一個FETCH的一個結果發生的。

RFC822.SIZE

表示郵件的[RFC-2822]大小的一個數字。

RFC822.TEXT

等效於BODY[TEXT]。

UID

表示郵件的唯一標識符的一個數字。

例子：

S: * 23 FETCH (FLAGS (/Seen) RFC822.SIZE 44827)

7.5. 服務器響應－命令連續請求

命令連續請求響應由一個“+”符號而不是一個標籤指明。這種響應形式指明服務器準備好接收來自客戶端的一個連續命令。該響應的剩餘部分是一行文本。

該響應被用於AUTHENTICATE命令以傳送服務器數據至客戶端，及請求其它客戶端數據。該響應也使用於任意命令的一個參數是一個文本的情況。

不允許客戶端發送文本字節，除非服務器指明希望這樣。這允許服務器在一個逐行（處理）的規則下處理命令及拒絕錯誤。命令的剩餘部分，包括終止一個命令的CRLF，跟在文本字節後。如果有任何其它命令參數，則一個空格和那些參數跟在文本字節後。

例子：C: A001 LOGIN {11}

S: + Ready for additional command text

C: FRED FOOBAR {7}

S: + Ready for additional command text

C: fat man

S: A001 OK LOGIN completed

C: A044 BLURDYBLOOP {102856}

S: A044 BAD No such command as “BLURDYBLOOP”

8. IMAP4rev1連接例子

以下是一個IMAP4rev1連接的一個抄本。在該例中，爲了編輯上的清楚，就折斷了長行。

S: * OK IMAP4rev1 Service Ready
C: a001 login mrc secret
S: a001 OK LOGIN completed
C: a002 select inbox
S: * 18 EXISTS
S: * FLAGS (/Answered /Flagged /Deleted /Seen /Draft)
S: * 2 RECENT
S: * OK [UNSEEN 17] Message 17 is the first unseen message
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: a002 OK [READ-WRITE] SELECT completed
C: a003 fetch 12 full
S: * 12 FETCH (FLAGS (/Seen) INTERNALDATE ”17-Jul-1996 02:44:25 -0700″
RFC822 .SIZE 4286 ENVELOPE (“Wed, 17 Jul 1996 02:23:25 -0700 (PDT)”
“IMAP4rev1 WG mtg summary and minutes”
((“Terry Gray” NIL ”gray” ”cac.washington.edu”))
((“Terry Gray” NIL ”gray” ”cac.washington.edu”))
((“Terry Gray” NIL ”gray” ”cac.washington.edu”))
((NIL NIL ”imap” ”cac.washington.edu”))
((NIL NIL ”minutes” ”CNRI.Reston.VA.US”)
(“John Klensin” NIL ”KLENSIN” ”MIT.EDU”)) NIL NIL
“<[email protected] >”)
BODY (“TEXT” ”PLAIN” (“CHARSET” ”US-ASCII”) NIL NIL ”7BIT” 3028
92))
S: a003 OK FETCH completed
C: a004 fetch 12 body[header]
S: * 12 FETCH (BODY[HEADER] {342}
S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
S: From: Terry Gray <[email protected] >
S: Subject: IMAP4rev1 WG mtg summary and minutes
S: To: [email protected]
S: cc: [email protected] , John Klensin <[email protected] >
S: Message-Id: <[email protected]>
S: MIME-Version: 1.0
S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
S:
S: )
S: a004 OK FETCH completed
C: a005 store 12 +flags /deleted
S: * 12 FETCH (FLAGS (/Seen /Deleted))
S: a005 OK +FLAGS completed
C: a006 logout
S: * BYE IMAP4rev1 server terminating connection
S: a006 OK LOGOUT completed

9. 正式語法

以下語法規範中使用[ABNF]中指定的Augmented Backus-Naur Form(ABNF)符號。

當現出二擇一的、或者可選的規則，其中一個晚期規則與一個早期規則交迭時，早期規則必須優先。例如，解析爲一個標記的“/Seen”是/Seen標記名，而不是一個標記擴展，雖然“/Seen”可以被解析爲一個標記擴展。以下是這個規則的實例的一些，但不是全部：

注意：[ABNF]規則必須嚴格遵守；特別的：

（１）除非另外指明，否則所有字母都是不區分大小寫的。使用大寫或者小寫字母定義符號字符只是爲了編輯上的清楚而已。實現體必須以一種不區分大小寫的方式接收這些字符串。

（２）任何情況下，SP正確地指向一個空間。不允許替代TAB，插入其它空格，或者將SP看作等效的LWSP。

（３）ASCII字符NUL，%x00，任何時候都不能使用。

（爲避免引起不必要的曲解，也是因爲譯者認爲這一部分對所有的協議實現者來說都是非常極爲重要的部分，所以下面列出的語法及其註釋部分全部原文貼出，不對註釋進行翻譯，不便之處，見諒）

address = ”(“ addr-name SP addr-adl SP addr-mailbox SP
addr-host ”)”

addr-adl = nstring
; Holds route from [RFC-2822 ] route-addr if
; non-NIL

addr-host = nstring
; NIL indicates [RFC-2822 ] group syntax.
; Otherwise, holds [RFC-2822 ] domain name

addr-mailbox = nstring
; NIL indicates end of [RFC-2822 ] group; if
; non-NIL and addr-host is NIL, holds
; [RFC-2822 ] group name.
; Otherwise, holds [RFC-2822 ] local-part
; after removing [RFC-2822 ] quoting

addr-name = nstring
; If non-NIL, holds phrase from [RFC-2822 ]
; mailbox after removing [RFC-2822 ] quoting

append = ”APPEND” SP mailbox [SP flag-list] [SP date-time] SP
literal

astring = 1*ASTRING-CHAR / string

ASTRING-CHAR = ATOM-CHAR / resp-specials

atom = 1*ATOM-CHAR

ATOM-CHAR = <any CHAR except atom-specials>

atom-specials = ”(“ / ”)” / ”{“ / SP / CTL / list-wildcards /
quoted-specials / resp-specials

authenticate = ”AUTHENTICATE” SP auth-type *(CRLF base64)

auth-type = atom
; Defined by [SASL]

base64 = *(4base64-char) [base64-terminal]

base64-char = ALPHA / DIGIT / ”+” / ”/”
; Case-sensitive

base64-terminal = (2base64-char ”==”) / (3base64-char ”=”)

body = ”(“ (body-type-1part / body-type-mpart) ”)”

body-extension = nstring / number /
“(“ body-extension *(SP body-extension) ”)”
; Future expansion. Client implementations
; MUST accept body-extension fields. Server
; implementations MUST NOT generate
; body-extension fields except as defined by
; future standard or standards-track
; revisions of this specification.

body-ext-1part = body-fld-md5 [SP body-fld-dsp [SP body-fld-lang
[SP body-fld-loc *(SP body-extension)]]]
; MUST NOT be returned on non-extensible
; ”BODY” fetch

body-ext-mpart = body-fld-param [SP body-fld-dsp [SP body-fld-lang
[SP body-fld-loc *(SP body-extension)]]]
; MUST NOT be returned on non-extensible
; ”BODY” fetch

body-fields = body-fld-param SP body-fld-id SP body-fld-desc SP
body-fld-enc SP body-fld-octets

body-fld-desc = nstring

body-fld-dsp = ”(“ string SP body-fld-param ”)” / nil

body-fld-enc = (DQUOTE (“7BIT” / ”8BIT” / ”BINARY” / ”BASE64″/
“QUOTED-PRINTABLE”) DQUOTE) / string

body-fld-id = nstring

body-fld-lang = nstring / ”(“ string *(SP string) ”)”

body-fld-loc = nstring

body-fld-lines = number

body-fld-md5 = nstring

body-fld-octets = number

body-fld-param = ”(“ string SP string *(SP string SP string) ”)” / nil

body-type-1part = (body-type-basic / body-type-msg / body-type-text)
[SP body-ext-1part]

body-type-basic = media-basic SP body-fields
; MESSAGE subtype MUST NOT be ”RFC822 ”

body-type-mpart = 1*body SP media-subtype
[SP body-ext-mpart]

body-type-msg = media-message SP body-fields SP envelope
SP body SP body-fld-lines

body-type-text = media-text SP body-fields SP body-fld-lines

capability = (“AUTH=” auth-type) / atom
; New capabilities MUST begin with ”X” or be
; registered with IANA as standard or
; standards-track

capability-data = ”CAPABILITY” *(SP capability) SP ”IMAP4rev1″
*(SP capability)
; Servers MUST implement the STARTTLS, AUTH=PLAIN,
; and LOGINDISABLED capabilities
; Servers which offer RFC1730 compatibility MUST
; list ”IMAP4″ as the first capability.

CHAR8 = %x01-ff
; any OCTET except NUL, %x00

command = tag SP (command-any / command-auth / command-nonauth /
command-select) CRLF
; Modal based on state

command-any = ”CAPABILITY” / ”LOGOUT” / ”NOOP” / x-command
; Valid in all states

command-auth = append / create / delete / examine / list / lsub /
rename / select / status / subscribe / unsubscribe
; Valid only in Authenticated or Selected state

command-nonauth = login / authenticate / ”STARTTLS”
; Valid only when in Not Authenticated state

command-select = ”CHECK” / ”CLOSE” / ”EXPUNGE” / copy / fetch / store /
uid / search
; Valid only when in Selected state

continue-req = ”+” SP (resp-text / base64) CRLF

copy = ”COPY” SP sequence-set SP mailbox

create = ”CREATE” SP mailbox
; Use of INBOX gives a NO error

date = date-text / DQUOTE date-text DQUOTE

date-day = 1*2DIGIT
; Day of month

date-day-fixed = (SP DIGIT) / 2DIGIT
; Fixed-format version of date-day

date-month = ”Jan” / ”Feb” / ”Mar” / ”Apr” / ”May” / ”Jun” /
“Jul” / ”Aug” / ”Sep” / ”Oct” / ”Nov” / ”Dec”

date-text = date-day ”-” date-month ”-” date-year

date-year = 4DIGIT

date-time = DQUOTE date-day-fixed ”-” date-month ”-” date-year
SP time SP zone DQUOTE

delete = ”DELETE” SP mailbox
; Use of INBOX gives a NO error

digit-nz = %x31-39
; 1-9

envelope = ”(“ env-date SP env-subject SP env-from SP
env-sender SP env-reply-to SP env-to SP env-cc SP
env-bcc SP env-in-reply-to SP env-message-id ”)”

env-bcc = ”(“ 1*address ”)” / nil

env-cc = ”(“ 1*address ”)” / nil

env-date = nstring

env-from = ”(“ 1*address ”)” / nil

env-in-reply-to = nstring

env-message-id = nstring

env-reply-to = ”(“ 1*address ”)” / nil

env-sender = ”(“ 1*address ”)” / nil

env-subject = nstring

env-to = ”(“ 1*address ”)” / nil

examine = ”EXAMINE” SP mailbox

fetch = ”FETCH” SP sequence-set SP (“ALL” / ”FULL” / ”FAST” /
fetch-att / ”(“ fetch-att *(SP fetch-att) ”)”)

fetch-att = ”ENVELOPE” / ”FLAGS” / ”INTERNALDATE” /
“RFC822 “ [".HEADER" / ".SIZE" / ".TEXT"] /
“BODY” ["STRUCTURE"] / ”UID” /
“BODY” section ["<" number "." nz-number ">"] /
“BODY.PEEK” section ["<" number "." nz-number ">"]

flag = ”/Answered” / ”/Flagged” / ”/Deleted” /
“/Seen” / ”/Draft” / flag-keyword / flag-extension
; Does not include ”/Recent”

flag-extension = ”/” atom
; Future expansion. Client implementations
; MUST accept flag-extension flags. Server
; implementations MUST NOT generate
; flag-extension flags except as defined by
; future standard or standards-track
; revisions of this specification.

flag-fetch = flag / ”/Recent”

flag-keyword = atom

flag-list = ”(“ [flag *(SP flag)] ”)”

flag-perm = flag / ”/*”

greeting = ”*” SP (resp-cond-auth / resp-cond-bye) CRLF

header-fld-name = astring

header-list = ”(“ header-fld-name *(SP header-fld-name) ”)”

list = ”LIST” SP mailbox SP list-mailbox

list-mailbox = 1*list-char / string

list-char = ATOM-CHAR / list-wildcards / resp-specials

list-wildcards = ”%” / ”*”

literal = ”{“ number ”}” CRLF *CHAR8
; Number represents the number of CHAR8s

lsub = ”LSUB” SP mailbox SP list-mailbox

mailbox = ”INBOX” / astring
; INBOX is case-insensitive. All case variants of
; INBOX (e.g., ”iNbOx”) MUST be interpreted as INBOX
; not as an astring. An astring which consists of
; the case-insensitive sequence ”I” ”N” ”B” ”O” ”X”
; is considered to be INBOX and not an astring.
; Refer to section 5.1 for further
; semantic details of mailbox names.

mailbox-data = ”FLAGS” SP flag-list / ”LIST” SP mailbox-list /
“LSUB” SP mailbox-list / ”SEARCH” *(SP nz-number) /
“STATUS” SP mailbox SP ”(“ [status-att-list] ”)” /
number SP ”EXISTS” / number SP ”RECENT”

mailbox-list = ”(“ [mbx-list-flags] ”)” SP
(DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox

mbx-list-flags = *(mbx-list-oflag SP) mbx-list-sflag
*(SP mbx-list-oflag) /
mbx-list-oflag *(SP mbx-list-oflag)

mbx-list-oflag = ”/Noinferiors” / flag-extension
; Other flags; multiple possible per LIST response

mbx-list-sflag = ”/Noselect” / ”/Marked” / ”/Unmarked”
; Selectability flags; only one per LIST response

media-basic = ((DQUOTE (“APPLICATION” / ”AUDIO” / ”IMAGE” /
“MESSAGE” / ”VIDEO”) DQUOTE) / string) SP
media-subtype
; Defined in [MIME-IMT]

media-message = DQUOTE ”MESSAGE” DQUOTE SP DQUOTE ”RFC822 “ DQUOTE
; Defined in [MIME-IMT]

media-subtype = string
; Defined in [MIME-IMT]

media-text = DQUOTE ”TEXT” DQUOTE SP media-subtype
; Defined in [MIME-IMT]

message-data = nz-number SP (“EXPUNGE” / (“FETCH” SP msg-att))

msg-att = ”(“ (msg-att-dynamic / msg-att-static)
*(SP (msg-att-dynamic / msg-att-static)) ”)”

msg-att-dynamic = ”FLAGS” SP ”(“ [flag-fetch *(SP flag-fetch)] ”)”
; MAY change for a message

msg-att-static = ”ENVELOPE” SP envelope / ”INTERNALDATE” SP date-time /
“RFC822 “ [".HEADER" / ".TEXT"] SP nstring /
“RFC822 .SIZE” SP number /
“BODY” ["STRUCTURE"] SP body /
“BODY” section ["<" number ">"] SP nstring /
“UID” SP uniqueid
; MUST NOT change for a message

nil = ”NIL”

nstring = string / nil

number = 1*DIGIT
; Unsigned 32-bit integer
; (0 <= n < 4,294,967,296)

nz-number = digit-nz *DIGIT
; Non-zero unsigned 32-bit integer
; (0 < n < 4,294,967,296)

password = astring

quoted = DQUOTE *QUOTED-CHAR DQUOTE

QUOTED-CHAR = <any TEXT-CHAR except quoted-specials> /
“/” quoted-specials

quoted-specials = DQUOTE / ”/”

rename = ”RENAME” SP mailbox SP mailbox
; Use of INBOX as a destination gives a NO error

response = *(continue-req / response-data) response-done

response-data = ”*” SP (resp-cond-state / resp-cond-bye /
mailbox-data / message-data / capability-data) CRLF

response-done = response-tagged / response-fatal

response-fatal = ”*” SP resp-cond-bye CRLF
; Server closes connection immediately

response-tagged = tag SP resp-cond-state CRLF

resp-cond-auth = (“OK” / ”PREAUTH”) SP resp-text
; Authentication condition

resp-cond-bye = ”BYE” SP resp-text

resp-cond-state = (“OK” / ”NO” / ”BAD”) SP resp-text
; Status condition

resp-specials = ”]”

resp-text = ["[" resp-text-code "]“ SP] text

resp-text-code = ”ALERT” /
“BADCHARSET” [SP "(" astring *(SP astring) ")" ] /
capability-data / ”PARSE” /
“PERMANENTFLAGS” SP ”(”
[flag-perm *(SP flag-perm)] ”)” /
“READ-ONLY” / ”READ-WRITE” / ”TRYCREATE” /
“UIDNEXT” SP nz-number / ”UIDVALIDITY” SP nz-number /
“UNSEEN” SP nz-number /
atom [SP 1*<any TEXT-CHAR except "]“>]

search = ”SEARCH” [SP "CHARSET" SP astring] 1*(SP search-key)
; CHARSET argument to MUST be registered with IANA

search-key = ”ALL” / ”ANSWERED” / ”BCC” SP astring /
“BEFORE” SP date / ”BODY” SP astring /
“CC” SP astring / ”DELETED” / ”FLAGGED” /
“FROM” SP astring / ”KEYWORD” SP flag-keyword /
“NEW” / ”OLD” / ”ON” SP date / ”RECENT” / ”SEEN” /
“SINCE” SP date / ”SUBJECT” SP astring /
“TEXT” SP astring / ”TO” SP astring /
“UNANSWERED” / ”UNDELETED” / ”UNFLAGGED” /
“UNKEYWORD” SP flag-keyword / ”UNSEEN” /
; Above this line were in [IMAP2]
“DRAFT” / ”HEADER” SP header-fld-name SP astring /
“LARGER” SP number / ”NOT” SP search-key /
“OR” SP search-key SP search-key /
“SENTBEFORE” SP date / ”SENTON” SP date /
“SENTSINCE” SP date / ”SMALLER” SP number /
“UID” SP sequence-set / ”UNDRAFT” / sequence-set /
“(“ search-key *(SP search-key) ”)”

section = ”[" [section-spec] ”]”

section-msgtext = ”HEADER” / ”HEADER.FIELDS” [".NOT"] SP header-list /
“TEXT”
; top-level or MESSAGE/RFC822 part

section-part = nz-number *(“.” nz-number)
; body part nesting

section-spec = section-msgtext / (section-part ["." section-text])

section-text = section-msgtext / ”MIME”
; text other than actual body part (headers, etc.)

select = ”SELECT” SP mailbox

seq-number = nz-number / ”*”
; message sequence number (COPY, FETCH, STORE
; commands) or unique identifier (UID COPY,
; UID FETCH, UID STORE commands).
; * represents the largest number in use. In
; the case of message sequence numbers, it is
; the number of messages in a non-empty mailbox.
; In the case of unique identifiers, it is the
; unique identifier of the last message in the
; mailbox or, if the mailbox is empty, the
; mailbox’s current UIDNEXT value.
; The server should respond with a tagged BAD
; response to a command that uses a message
; sequence number greater than the number of
; messages in the selected mailbox. This
; includes ”*” if the selected mailbox is empty.

seq-range = seq-number ”:” seq-number
; two seq-number values and all values between
; these two regardless of order.
; Example: 2:4 and 4:2 are equivalent and indicate
; values 2, 3, and 4.
; Example: a unique identifier sequence range of
; 3291:* includes the UID of the last message in
; the mailbox, even if that value is less than 3291.

sequence-set = (seq-number / seq-range) *(“,” sequence-set)
; set of seq-number values, regardless of order.
; Servers MAY coalesce overlaps and/or execute the
; sequence in any order.
; Example: a message sequence number set of
; 2,4:7,9,12:* for a mailbox with 15 messages is
; equivalent to 2,4,5,6,7,9,12,13,14,15
; Example: a message sequence number set of *:4,5:7
; for a mailbox with 10 messages is equivalent to
; 10,9,8,7,6,5,4,5,6,7 and MAY be reordered and
; overlap coalesced to be 4,5,6,7,8,9,10.

status = ”STATUS” SP mailbox SP
“(“ status-att *(SP status-att) ”)”

status-att = ”MESSAGES” / ”RECENT” / ”UIDNEXT” / ”UIDVALIDITY” /
“UNSEEN”

status-att-list = status-att SP number *(SP status-att SP number)

store = ”STORE” SP sequence-set SP store-att-flags

store-att-flags = (["+" / "-"] ”FLAGS” [".SILENT"]) SP
(flag-list / (flag *(SP flag)))

string = quoted / literal

subscribe = ”SUBSCRIBE” SP mailbox

tag = 1*<any ASTRING-CHAR except ”+”>

text = 1*TEXT-CHAR

TEXT-CHAR = <any CHAR except CR and LF>

time = 2DIGIT ”:” 2DIGIT ”:” 2DIGIT
; Hours minutes seconds

uid = ”UID” SP (copy / fetch / search / store)
; Unique identifiers used instead of message
; sequence numbers

uniqueid = nz-number
; Strictly ascending

unsubscribe = ”UNSUBSCRIBE” SP mailbox

userid = astring

x-command = ”X” atom <experimental command arguments>

zone = (“+” / ”-”) 4DIGIT
; Signed four-digit value of hhmm representing
; hours and minutes east of Greenwich (that is,
; the amount that the given time differs from
; Universal Time). Subtracting the timezone
; from the given time will give the UT form.
; The Universal Time zone is ”+0000″.

10. 作者的說明

該文檔是早期文檔的一個修訂版或者改寫版，且接替了下列文檔的協議規範：RFC2060,RFC1730,未發佈的IMAP2bis.TXT文檔，RFC1176,及RFC1064。

11. 安全考慮

IMAP4rev1協議事務，包括電子郵件數據，直接在網絡上發送，除非有防竊聽的保護。這是通過使用STARTTLS，AUTHENTICATE命令中通過了的祕密保護，或者一些其它的保護機制來完成的。

11.1. STARTTLS安全考慮

該文檔中的STARTTLS命令和LOGINDISABLED功能的規範替代[IMAP-TLS]中的。[IMAP-TLS]保持PLAIN [SASL]認證的標準。

IMAP客戶端和服務器實現體必須實現TLS_RSA_WITH_RC4_128_MD5 [TLS]密碼體，並且應當實現 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS]密碼體。這是重要的，因爲這樣才能保證任意兩個兼容的實現體能夠註冊到一塊。所有其它密碼體都是OPTIONAL。注意，這個變更源於[IMAP-TLS]的2.1一節。

在[TLS]對話期間，客戶端必須確認服務器主機名和出現在服務器證書郵件中的服務器標識，以免受中間人攻擊。如果匹配失敗，客戶端應當請求用戶的明確確認，或者終止連接，並指明該服務器標識是可疑的。匹配按照以下規則進行：

客戶端必須把用來打開連接的服務器主機名和服務器證書中表示的服務器名相比較。客戶端不能使用來源於一個不安全的遠程資源的服務器主機名的任意形式（例如，不安全的DNS查找）。不執行CNAME規範。

匹配是不區分大小寫的。

一個“*”通配符可以被用來表示證書中的左邊任意多個字符。例如，*.example.com可以匹配a.example.com, foo.example.com, 等等，但是不能匹配example.com。

如果證書包含多個名（例如，多於一個的DNS名稱域），那麼這些域的任意一個的（成功）匹配就被認爲是可接收的。

客戶端和服務器必須確認STARTTLS命令和後續的[TLS]對話的結果，以瞭解是否完成了可接收的認證或者祕密。

11.2. 其它安全考慮

由無效信任書引起的，一個AUTHENTICATE命令的一個服務器錯誤郵件不應當詳述爲什麼信任書無效。

使用LOGIN直接發送密碼。這可以通過使用一個[SASL]機制的、不支持簡單文本密碼的AUTHENTICATE命令，通過經STARTTLS早期對話加密，或者其它保護機制避免。

一個服務器實現體必須實現一個配置，認證時，要求：

（１）STARTTLS命令已經通過。

或者

（２）其它保護會話防密碼竊聽的機制已經提供。

或者

（３）以下措施已採用：

（a）LOGINDISABLED功能被通報，且使用簡單文本密碼的[SASL]機制（如，PLAIN）沒在功能列表中通報。

且

（b）AUTHENTICATE命令返回一個錯誤，即使密碼是正確的。

（c）AUTHENTICATE命令返回使用簡單文本密碼的所有[SASL]機制的一個錯誤，即使密碼是正確的。

針對一個失敗的LOGIN命令的一個服務器錯誤郵件不應當指明該用戶名，對於該密碼，是無效的。

一個服務器應當有適當的機制限制或者延期失敗的AUTHENTICATE/LOGIN嘗試。

其它安全考慮在AUTHENTICATE及LOGIN命令的那一節中有討論。

12. IANA考慮

IMAP４功能通過出版一個標準本或者IESG覈准的試驗RFC註冊。該註冊本現在位於：

http://www.iana.org/assignments/imap4-capabilities

該規範修訂了之前[IMAP-TLS]定義了的STARTTLS及LOGINDISABLED擴展，因此該註冊將更新。

附錄

A. 標準參考

下列文檔包含了有助於適當理解本文檔的定義或者規範：

[ABNF] Crocker, D. and P. Overell, ”Augmented BNF for
Syntax Specifications: ABNF”, RFC2234 ,
November 1997.

[ANONYMOUS] Newman, C., ”Anonymous SASL Mechanism”, RFC
2245, November 1997.

[CHARSET] Freed, N. and J. Postel, ”IANA Character Set
Registration Procedures”, RFC2978 , October
2000.

[DIGEST-MD5] Leach, P. and C. Newman, ”Using Digest
Authentication as a SASL Mechanism”, RFC2831 ,
May 2000.

[DISPOSITION] Troost, R., Dorner, S. and K. Moore,
“Communicating Presentation Information in
Internet Messages: The Content-Disposition
Header”, RFC2183 , August 1997.

[IMAP-TLS] Newman, C., ”Using TLS with IMAP, POP3 and
ACAP”, RFC2595 , June 1999.

[KEYWORDS] Bradner, S., ”Key words for use in RFCs to
Indicate Requirement Levels”, BCP 14, RFC2119 ,
March 1997.

[LANGUAGE-TAGS] Alvestrand, H., ”Tags for the Identification of
Languages”, BCP 47, RFC3066 , January 2001.

[LOCATION] Palme, J., Hopmann, A. and N. Shelness, ”MIME
Encapsulation of Aggregate Documents, such as
HTML (MHTML)”, RFC2557 , March 1999.

[MD5] Myers, J. and M. Rose, ”The Content-MD5 Header
Field”, RFC1864 , October 1995.

[MIME-HDRS] Moore, K., ”MIME (Multipurpose Internet Mail
Extensions) Part Three: Message Header
Extensions for Non-ASCII Text”, RFC2047 ,
November 1996.

[MIME-IMB] Freed, N. and N. Borenstein, ”MIME
(Multipurpose Internet Mail Extensions) Part
One: Format of Internet Message Bodies”, RFC
2045, November 1996.

[MIME-IMT] Freed, N. and N. Borenstein, ”MIME
(Multipurpose Internet Mail Extensions) Part
Two: Media Types”, RFC2046 , November 1996.

[RFC-2822 ] Resnick, P., ”Internet Message Format”, RFC
2822, April 2001.

[SASL] Myers, J., ”Simple Authentication and Security
Layer (SASL)”, RFC2222 , October 1997.

[TLS] Dierks, T. and C. Allen, ”The TLS Protocol
Version 1.0″, RFC2246 , January 1999.

[UTF-7] Goldsmith, D. and M. Davis, ”UTF-7: A Mail-Safe
Transformation Format of Unicode”, RFC2152 ,
May 1997.

The following documents describe quality-of-implementation issues
that should be carefully considered when implementing this protocol:

[IMAP-IMPLEMENTATION] Leiba, B., ”IMAP Implementation
Recommendations”, RFC2683 , September 1999.

[IMAP-MULTIACCESS] Gahrns, M., ”IMAP4 Multi-Accessed Mailbox
Practice”, RFC2180 , July 1997.

A.1 Informative References

The following documents describe related protocols:

[IMAP-DISC] Austein, R., ”Synchronization Operations for
Disconnected IMAP4 Clients”, Work in Progress.

[IMAP-MODEL] Crispin, M., ”Distributed Electronic Mail
Models in IMAP4″, RFC1733 , December 1994.

[ACAP] Newman, C. and J. Myers, ”ACAP – Application
Configuration Access Protocol”, RFC2244 ,
November 1997.

[SMTP] Klensin, J., ”Simple Mail Transfer Protocol”,
STD 10, RFC2821 , April 2001.

The following documents are historical or describe historical aspects
of this protocol:

[IMAP-COMPAT] Crispin, M., ”IMAP4 Compatibility with
IMAP2bis”, RFC2061 , December 1996.

[IMAP-HISTORICAL] Crispin, M., ”IMAP4 Compatibility with IMAP2
and IMAP2bis”, RFC1732 , December 1994.

[IMAP-OBSOLETE] Crispin, M., ”Internet Message Access Protocol
- Obsolete Syntax”, RFC2062 , December 1996.

[IMAP2] Crispin, M., ”Interactive Mail Access Protocol
- Version 2″, RFC1176 , August 1990.

[RFC-822 ] Crocker, D., ”Standard for the Format of ARPA
Internet Text Messages”, STD 11, RFC822 ,
August 1982.

[RFC-821 ] Postel, J., ”Simple Mail Transfer Protocol”,
STD 10, RFC821 , August 1982.
B. 修改於 RFC2060

1) Clarify description of unique identifiers and their semantics.

2) Fix the SELECT description to clarify that UIDVALIDITY is required
in the SELECT and EXAMINE responses.

3) Added an example of a failing search.

4) Correct store-att-flags: ”#flag” should be ”1#flag”.

5) Made search and section rules clearer.

6) Correct the STORE example.

7) Correct ”BASE645″ misspelling.

8) Remove extraneous close parenthesis in example of two-part message
with text and BASE64 attachment.

9) Remove obsolete ”MAILBOX” response from mailbox-data.

10) A spurious ”<” in the rule for mailbox-data was removed.

11) Add CRLF to continue-req.

12) Specifically exclude ”]” from the atom in resp-text-code.

13) Clarify that clients and servers should adhere strictly to the
protocol syntax.

14) Emphasize in 5.2 that EXISTS can not be used to shrink a mailbox.

15) Add NEWNAME to resp-text-code.

16) Clarify that the empty string, not NIL, is used as arguments to
LIST.

17) Clarify that NIL can be returned as a hierarchy delimiter for the
empty string mailbox name argument if the mailbox namespace is flat.

18) Clarify that addr-mailbox and addr-name have RFC-2822 quoting
removed.

19) Update UTF-7 reference.

20) Fix example in 6.3.11.

21) Clarify that non-existent UIDs are ignored.

22) Update DISPOSITION reference.

23) Expand state diagram.

24) Clarify that partial fetch responses are only returned in
response to a partial fetch command.

25) Add UIDNEXT response code. Correct UIDVALIDITY definition
reference.

26) Further clarification of ”can” vs. ”MAY”.

27) Reference RFC-2119 .

28) Clarify that superfluous shifts are not permitted in modified
UTF-7.

29) Clarify that there are no implicit shifts in modified UTF-7.

30) Clarify that ”INBOX” in a mailbox name is always INBOX, even if
it is given as a string.

31) Add missing open parenthesis in media-basic grammar rule.

32) Correct attribute syntax in mailbox-data.

33) Add UIDNEXT to EXAMINE responses.

34) Clarify UNSEEN, PERMANENTFLAGS, UIDVALIDITY, and UIDNEXT
responses in SELECT and EXAMINE. They are required now, but weren’t
in older versions.

35) Update references with RFCnumbers.

36) Flush text-mime2.

37) Clarify that modified UTF-7 names must be case-sensitive and that
violating the convention should be avoided.

38) Correct UID FETCH example.

39) Clarify UID FETCH, UID STORE, and UID SEARCH vs. untagged EXPUNGE
responses.

40) Clarify the use of the word ”convention”.

41) Clarify that a command is not ”in progress” until it has been
fully received (specifically, that a command is not ”in progress”
during command continuation negotiation).

42) Clarify envelope defaulting.

43) Clarify that SP means one and only one space character.

44) Forbid silly states in LIST response.

45) Clarify that the ENVELOPE, INTERNALDATE, RFC822 *, BODY*, and UID
for a message is static.

46) Add BADCHARSET response code.

47) Update formal syntax to [ABNF] conventions.

48) Clarify trailing hierarchy delimiter in CREATE semantics.

49) Clarify that the ”blank line” is the [RFC-2822 ] delimiting blank
line.

50) Clarify that RENAME should also create hierarchy as needed for
the command to complete.

51) Fix body-ext-mpart to not require language if disposition
present.

52) Clarify the RFC822 .HEADER response.

53) Correct missing space after charset astring in search.

54) Correct missing quote for BADCHARSET in resp-text-code.

55) Clarify that ALL, FAST, and FULL preclude any other data items
appearing.

56) Clarify semantics of reference argument in LIST.

57) Clarify that a null string for SEARCH HEADER X-FOO means any
message with a header line with a field-name of X-FOO regardless of
the text of the header.

58) Specifically reserve 8-bit mailbox names for future use as UTF-8.

59) It is not an error for the client to store a flag that is not in
the PERMANENTFLAGS list; however, the server will either ignore the
change or make the change in the 會話 only.

60) Correct/clarify the text regarding superfluous shifts.

61) Correct typographic errors in the ”Changes” section.

62) Clarify that STATUS must not be used to check for new messages in
the selected mailbox

63) Clarify LSUB behavior with ”%” wildcard.

64) Change AUTHORIZATION to AUTHENTICATE in section 7.5.

65) Clarify description of multipart body type.

66) Clarify that STORE FLAGS does not affect /Recent.

67) Change ”west” to ”east” in description of timezone.

68) Clarify that commands which break command pipelining must wait
for a completion result response.

69) Clarify that EXAMINE does not affect /Recent.

70) Make description of MIME structure consistent.

71) Clarify that date searches disregard the time and timezone of the
INTERNALDATE or Date: header. In other words, ”ON 13-APR-2000″ means
messages with an INTERNALDATE text which starts with ”13-APR-2000″,
even if timezone differential from the local timezone is sufficient
to move that INTERNALDATE into the previous or next day.

72) Clarify that the header fetches don’t add a blank line if one
isn’t in the [RFC-2822 ] message.

73) Clarify (in discussion of UIDs) that messages are immutable.

74) Add an example of CHARSET searching.

75) Clarify in SEARCH that keywords are a type of flag.

76) Clarify the mandatory nature of the SELECT data responses.

77) Add optional CAPABILITY response code in the initial OK or
PREAUTH.

78) Add note that server can send an untagged CAPABILITY command as
part of the responses to AUTHENTICATE and LOGIN.

79) Remove statement about it being unnecessary to issue a CAPABILITY
command more than once in a connection. That statement is no longer
true.

80) Clarify that untagged EXPUNGE decrements the number of messages
in the mailbox.

81) Fix definition of ”body” (concatenation has tighter binding than
alternation).

82) Add a new ”Special Notes to Implementors” section with reference
to [IMAP-IMPLEMENTATION].

83) Clarify that an untagged CAPABILITY response to an AUTHENTICATE
command should only be done if a security layer was not negotiated.

84) Change the definition of atom to exclude ”]”. Update astring to
include ”]” for compatibility with the past. Remove resp-text-atom.

85) Remove NEWNAME. It can’t work because mailbox names can be
literals and can include ”]”. Functionality can be addressed via
referrals.

86) Move modified UTF-7 rationale in order to have more logical
paragraph flow.

87) Clarify UID uniqueness guarantees with the use of MUST.

88) Note that clients should read response data until the connection
is closed instead of immediately closing on a BYE.

89) Change RFC-822 references to RFC-2822 .

90) Clarify that RFC-2822 should be followed instead of RFC-822 .

91) Change recommendation of optional automatic capabilities in LOGIN
and AUTHENTICATE to use the CAPABILITY response code in the tagged
OK. This is more interoperable than an unsolicited untagged
CAPABILITY response.

92) STARTTLS and AUTH=PLAIN are mandatory to implement; add
recommendations for other [SASL] mechanisms.

93) Clarify that a ”connection” (as opposed to ”server” or ”command”)
is in one of the four states.

94) Clarify that a failed or rejected command does not change state.

95) Split references between normative and informative.

96) Discuss authentication failure issues in security section.

97) Clarify that a data item is not necessarily of only one data
type.

98) Clarify that sequence ranges are independent of order.

99) Change an example to clarify that superfluous shifts in
Modified-UTF7 can not be fixed just by omitting the shift. The
entire string must be recalculated.

100) Change Envelope Structure definition since [RFC-2822 ] uses
“envelope” to refer to the [SMTP] envelope and not the envelope data
that appears in the [RFC-2822 ] header.

101) Expand on RFC822 .HEADER response data vs. BODY[HEADER].

102) Clarify Logout state semantics, change ASCII art.

103) Security changes to comply with IESG requirements.

104) Add definition for body URI.

105) Break sequence range definition into three rules, with rewritten
descriptions for each.

106) Move STARTTLS and LOGINDISABLED here from [IMAP-TLS].

107) Add IANA Considerations section.

108) Clarify valid client assumptions for new message UIDs vs.
UIDNEXT.

109) Clarify that changes to permanentflags affect concurrent
會話s as well as subsequent 會話s.

110) Clarify that authenticated state can be entered by the CLOSE
command.

111) Emphasize that SELECT and EXAMINE are the exceptions to the rule
that a failing command does not change state.

112) Clarify that newly-appended messages have the Recent flag set.

113) Clarify that newly-copied messages SHOULD have the Recent flag
set.

114) Clarify that UID commands always return the UID in FETCH
responses.

C.關鍵詞索引

+FLAGS <flag list> (store command data item)
+FLAGS.SILENT <flag list> (store command data item)
-FLAGS <flag list> (store command data item)
-FLAGS.SILENT <flag list> (store command data item)
ALERT (response code)
ALL (fetch item)
ALL (search key)
ANSWERED (search key)
APPEND (command)
AUTHENTICATE (command)
BAD (response)
BADCHARSET (response code)
BCC <string> (search key)
BEFORE <date> (search key)
BODY (fetch item)
BODY (fetch result)
BODY <string> (search key)
BODY.PEEK[<section>]<<partial>> (fetch item)
BODYSTRUCTURE (fetch item)
BODYSTRUCTURE (fetch result)
BODY[<section>]<<origin octet>> (fetch result)
BODY[<section>]<<partial>> (fetch item)
BYE (response)
Body Structure (message attribute)
CAPABILITY (command)
CAPABILITY (response code)
CAPABILITY (response)
CC <string> (search key)
CHECK (command)
CLOSE (command)
COPY (command)
CREATE (command)
DELETE (command)
DELETED (search key)
DRAFT (search key)
ENVELOPE (fetch item)
ENVELOPE (fetch result)
EXAMINE (command)
EXISTS (response)
EXPUNGE (command)
EXPUNGE (response)
Envelope Structure (message attribute)
FAST (fetch item)
FETCH (command)
FETCH (response)
FLAGGED (search key)
FLAGS (fetch item)
FLAGS (fetch result)
FLAGS (response)
FLAGS <flag list> (store command data item)
FLAGS.SILENT <flag list> (store command data item)
FROM <string> (search key)
FULL (fetch item)
Flags (message attribute)
HEADER (part specifier)
HEADER <field-name> <string> (search key)
HEADER.FIELDS <header-list> (part specifier)
HEADER.FIELDS.NOT <header-list> (part specifier)
INTERNALDATE (fetch item)
INTERNALDATE (fetch result)
Internal Date (message attribute)
KEYWORD <flag> (search key)
Keyword (type of flag)
LARGER <n> (search key)
LIST (command)
LIST (response)
LOGIN (command)
LOGOUT (command)
LSUB (command)
LSUB (response)
MAY (specification requirement term)
MESSAGES (status item)
MIME (part specifier)
MUST (specification requirement term)
MUST NOT (specification requirement term)
Message Sequence Number (message attribute)
NEW (search key)
NO (response)
NOOP (command)
NOT <search-key> (search key)
OK (response)
OLD (search key)
ON <date> (search key)
OPTIONAL (specification requirement term)
OR <search-key1> <search-key2> (search key)
PARSE (response code)
PERMANENTFLAGS (response code)
PREAUTH (response)
Permanent Flag (class of flag)
READ-ONLY (response code)
READ-WRITE (response code)
RECENT (response)
RECENT (search key)
RECENT (status item)
RENAME (command)
REQUIRED (specification requirement term)
RFC822 (fetch item)
RFC822 (fetch result)
RFC822 .HEADER (fetch item)
RFC822 .HEADER (fetch result)
RFC822 .SIZE (fetch item)
RFC822 .SIZE (fetch result)
RFC822 .TEXT (fetch item)
RFC822 .TEXT (fetch result)
SEARCH (command)
SEARCH (response)
SEEN (search key)
SELECT (command)
SENTBEFORE <date> (search key)
SENTON <date> (search key)
SENTSINCE <date> (search key)
SHOULD (specification requirement term)
SHOULD NOT (specification requirement term)
SINCE <date> (search key)
SMALLER <n> (search key)
STARTTLS (command)
STATUS (command)
STATUS (response)
STORE (command)
SUBJECT <string> (search key)
SUBSCRIBE (command)
會話 Flag (class of flag)
System Flag (type of flag)
TEXT (part specifier)
TEXT <string> (search key)
TO <string> (search key)
TRYCREATE (response code)
UID (command)
UID (fetch item)
UID (fetch result)
UID <sequence set> (search key)
UIDNEXT (response code)
UIDNEXT (status item)
UIDVALIDITY (response code)
UIDVALIDITY (status item)
UNANSWERED (search key)
UNDELETED (search key)
UNDRAFT (search key)
UNFLAGGED (search key)
UNKEYWORD <flag> (search key)
UNSEEN (response code)
UNSEEN (search key)
UNSEEN (status item)
UNSUBSCRIBE (command)
Unique Identifier (UID) (message attribute)
X<atom> (command)
[RFC-2822 ] Size (message attribute)
/Answered (system flag)
/Deleted (system flag)
/Draft (system flag)
/Flagged (system flag)
/Marked (mailbox name attribute)
/Noinferiors (mailbox name attribute)
/Noselect (mailbox name attribute)
/Recent (system flag)
/Seen (system flag)
/Unmarked (mailbox name attribute)

IMAP協議RFC3501中文文檔

１. 如何閱讀本文

１.1. 本文的結構

1.2 本文用到的約定語

1.3. 實現者需要特別注意的地方

2. 協議概述

2.1. 鏈路層

2.2. 命令及響應

2.2.1. 客戶端的協議發送和服務器端的協議接收

2.2.2. 服務器端的協議發送和客戶端的協議接收

2.3. 郵件屬性

2.3.1. 郵件號

2.3.1.1. 唯一標識符（UID）的郵件屬性

2.3.1.2. 郵件序列號的郵件屬性

2.3.2. 標記的郵件屬性

2.3.3. 實際日期的郵件屬性

2.3.4. [RFC-2822]大小的郵件屬性

2.3.5. 信封結構的郵件屬性

2.3.6. 主體結構的郵件屬性

2.4. 郵件文本

3. 狀態和流程圖

3.1. 未認證狀態

3.2. 認證狀態

3.3. 選中狀態

3.4. 註銷狀態

4. 數據格式

4.1. 原語

4.2. 數字

4.3. 字符串

4.3.1. 字節及二進制字符串

4.4. 圓括符列表

4.5. NIL

5. 操作的考慮

5.1. 郵箱命名

5.1.1. 郵箱層級命名

5.1.2. 郵箱命名空間的約定

5.1.3. 郵箱的國際命名約定

5.2. 郵箱大小和郵件狀態更新

5.3. 沒有命令在行進中的響應

5.4. 自動註銷計時器

5.5. 多個命令在行進中

6. 客戶端命令

6.1. 客戶端命令－任意狀態

6.1.1. CAPABILITY命令

6.1.2. NOOP命令

6.1.3. LOGOUT命令

6.2. 客戶端命令－未認證狀態

6.2.1. STARTTLS命令

6.2.2. AUTHENTICATE命令

6.2.3. LOGIN 命令

6.3. 客戶端命令－認證狀態

6.3.1. SEELCT命令

6.3.2. EXAMINE命令

6.3.3. CREATE命令

6.3.4. DELETE命令

6.3.5. RENAME命令

6.3.6. SUBSCRIBE命令

6.3.7. UNSUBSCRIBE命令

6.3.8. LIST命令

6.3.9. LSUB命令

6.3.10. STATUS命令

6.3.11. APPEND命令

6.4. 客戶端命令－被選中狀態

6.4.1. CHECK命令

6.4.2. CLOSE命令

6.4.3. EXPUNGE命令

6.4.4. SEARCH命令

6.4.5. FETCH命令

6.4.6. STORE命令

6.4.7. COPY命令

6.4.8. UID命令

6.5. 客戶端命令－試驗/擴展

6.5.1. X<atom>命令

7.服務器響應

7.1. 服務器響應－狀態響應

7.1.1. OK 響應

7.1.2. NO響應

7.1.3. BAD響應

7.1.4. PREAUTH響應

7.1.5. BYE響應

１.　如何閱讀本文

１.1.　本文的結構