IMAP協議RFC3501中文文檔

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]大小、郵戳、主體結構及郵件文本（RFC82二、RFC822.HEADER、RFC822.TEXT、及全部BODY[…]獲取數據項）必須永不改變。這並不包括郵件號、及能夠經過一個STORE命令設置的屬性（例如，FLAGS）。

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

郵箱中，從1到郵件總數的一個相對位置。這個位置必須是按升序排序了的惟一標識符。每當新的郵件被加進來，它就被分配一個比它加進來以前該郵箱中的郵件總數大1的郵件序列號。

在會話存活期，郵件序列號能夠從新分配。例如，當一個郵件被從郵箱中永久刪除，其後的全部郵件的郵件序列號就減少。郵箱的郵件總數也減少。相似的，一個新加進來的郵件將被分配一個郵件序列號――以前被刪除了的其它郵件所持有的郵件序列號。

郵件序列號，不只能夠用於經過郵箱的相對位置訪問郵件，還能夠用於數學運算。例如，若是接收到一個非標籤化的「11 EXISTS」，且以前接收了一個非標籤化的「8 EXISTS」，那麼，已經有郵件序列號爲九、十、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 foobar@Blurdybloop.COM

C: Subject: afternoon meeting

C: To: mooch@owatagu.siam.edu

C: Message-Id: B27397-0100000@Blurdybloop.COM

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」)」 96072316347.20117.h@cac.washington.edu」「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
「< B27397-0100000@cac.washington.edu >」)
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 < gray@cac.washington.edu >
S: Subject: IMAP4rev1 WG mtg summary and minutes
S: To: imap@cac.washington.edu
S: cc: minutes@CNRI.Reston.VA.US , John Klensin < KLENSIN@MIT.EDU >
S: Message-Id: <B27397-0100000@cac.washington.edu>
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)