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那样自己管理密钥，所以还是挺方便安全的。大家如果有更好的可以推荐给我，对邮件内容安全有见解的同学可以一起交流。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/69910739/viewspace-2640319/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/69910739/viewspace-2640319/