IMAP協議之BODYSTRUCTURE詳解

相信大家在處理IMAP協議是多多少少都會對BODYSTRUCTURE有接觸，剛開始時根本無法瞭解這是什麼玩意，後來在看一些開源的webmail時都會涉及到解析這個資料結構，後來無奈只能去查詢RFC3501來看看這到底是什麼東西。

大概說一下吧，BODYSTRUCTURE其實就是記錄了一封郵件的所有結構資訊，例如，正文大小，主題內容，郵件體的段結構順序，附件名等等。通常PC郵件客戶端都會將所有郵件都先下載到本地儲存為檔案形式，這樣你每次開啟客戶端隨便檢視郵件，只會在第一次下載時等待很長時間，即使有新的郵件也只用下載一封，使用者體驗效果好。但是瀏覽器上的頁面是實時互動的，檔案也不能儲存到本地主機上，如果將所有郵件都載入到瀏覽器頁面上，頁面就會出現卡頓或者崩潰，而且頁面也需要實時的和郵件伺服器互動，所以一般都是頁面先將一部分郵件的的BODYSTRUCTURE載入出來然後解析，這樣使用者就可以看到一封郵件的大概資訊了，如果使用者像讀取郵件就點選這封郵件，然後頁面會將該郵件的正文內容重新下載到頁面上，如果這個時候使用者又想下載附件，那麼頁面就重新從伺服器上拉取附件，可以說就是使用者像要什麼都會重新從伺服器上拉去，這樣頁面端的負擔就會很小，對使用者來說也不用長時間的等待了。

BODYSTRUCTURE分析   

3.1 RFC3501協議分析  

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

 

具體格式：

       Bodystructure返回的內容被包括在一對兒括號內“( )”,括號內的內容就是一個郵件的body結構，其和郵件的MIME塊格式是相對應的，其格式所示：

 

　　1.第一個元素：一個或者多個括號巢狀的body結構序列

　　2.第二個元素：多部分子型別(multipart subtype MIME-rfc2046)，(mixed, digest, parallel, alternative, etc.).

　　3.擴充套件資料

其中第2個元素和擴充套件資料不一定會出現，前提是body結構沒有巢狀（一封郵件足夠簡單的話）。

1.第一個元素  

一個body結構的組成是上文中的1+2+3項資料的組合，其中2，3還不一定出現。

 

而第一元素又可以是一個或者多個巢狀的body結構。如下所示

      

Bodystructure

(

 (body結構1)

（body結構2）

 (…)

（body結構n）

 “多部分子型別”

擴充套件資料

 )

 

每個body結構中可能會巢狀一個或者多個body結構，但最終多巢狀的body結構都會由一個或者多個“非多部分body結構”+第二元素(可選)+擴充套件資料（可選）組成，要不然就會無限的迴圈下去。

 

 

一個分多部分body結構的是由基本資料+擴充套件資料組成的,完全按照下面順序的基本資料：

 

主體型別

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

主體子型別

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

主體引數組合列表

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

主體號

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

主體描述

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

主體編碼

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

主體大小

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

      

完全按照下面順序的擴充套件資料（可選項）

 

主體MD5

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

主體部署

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

主體語言

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

主體定位

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

 

注意：該協議的這個版本還沒有定義任何下列擴充套件資料，它們可能如上面所描述的，屬於多欄位擴充套件資料

2．第二個元素  

這個元素只存在多巢狀的body結構中，其值是由一對雙引號包括的多部分子型別(multipart subtype 參照MIME-rfc2046)(mixed, digest, parallel, alternative, etc.).

       該值是從MIME中解析出來的，是關於MIME郵件塊的媒體型別中的，該值對我們意義不大，一般只有MIME存在巢狀是才會有。

3.擴充套件資料  

擴充套件資料按照下面順序存在

 

主體引數組合列表

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

主體部署

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

主體語言

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

主體定位

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

 

注意：在該協議的這個版本中，還沒有定義後來的擴充套件資料的任何一個。這些擴充套件資料可以包括0個或者多個的NIL，字串，數字，或者這些資料的潛在嵌   套組合列表。執行一個BODYSTRUCTURE fetch的客戶端實現體必須有所準備地接收這些擴充套件資料。伺服器實現體不能傳送這些擴充套件資料，直到它已經被該協議的一個修訂版所定義。

 

以上是對IMAP的BODYSTRUCTURE指令的講解.最近在關注" 郵件安全 "，在找一些公開的" 郵件加密 "軟體，PGP用起來太麻煩了，不過找到了另外一個 ，一個免費公開的"郵件內容加密"平臺，無論是個人還是企業規模化都可以試用，目前還沒有local版本的，不過從官網上檢視資料其是以郵件加密閘道器形式存在的，無需像PGP那樣自己管理金鑰，所以還是挺方便安全的。大家如果有更好的可以推薦給我，對郵件內容安全有見解的同學可以一起交流。