SMTP協(xié)議分析

1、SMTP協(xié)議分析第1章. SMTP概述1.1. SMTP在郵件通信中的位置SMTP，即簡單郵件傳送協(xié)議，所對(duì)應(yīng)RFC文檔為RFC821。同http等多數(shù)應(yīng)用層協(xié)議一樣，它工作在C/S模式下，用來實(shí)現(xiàn)因特網(wǎng)上的郵件傳送。SMTP在整個(gè)電子郵件通信中所處的位置如圖 1所示。圖 1電子郵件的通信過程可以看出，SMTP是用來將客戶機(jī)上的郵件傳送到服務(wù)器上。這里的客戶機(jī)是指某次連接中的發(fā)送方，服務(wù)器是指相應(yīng)的接收方。在講解發(fā)送郵件的整個(gè)通信過程前，先解釋一下面幾個(gè)術(shù)語。1.2. 幾個(gè)術(shù)語1.2.1. 郵件郵件是一種消息的格式，由信封、首部和正文組成。信封上最重要的是收信人的地址。郵件服務(wù)器用這個(gè)地址將郵

2、件發(fā)送到收信人所在的郵件服務(wù)器上。首部是由用戶代理或郵件服務(wù)器添加的一些信息。包括Received、Message-ID、From、Data、Reply-To、X-Phone、X-Mailer、To和Subject等字段。正文是是發(fā)送用戶發(fā)給接收用戶報(bào)文的內(nèi)容。RFC 822 規(guī)定正文為NVT ASCII文字行。更為詳細(xì)的說明，請(qǐng)參考RFC821和RFC822等協(xié)議。1.2.2. 用戶代理用戶代理UA（User Agent）是用戶與電子郵件系統(tǒng)的交互接口，一般來說它就是我們PC機(jī)上的一個(gè)程序。Windows上常見的用戶代理是Foxmail和Outlook Express。用戶代理提供一個(gè)好的用

3、戶界面，它提取用戶在其界面填寫的各項(xiàng)信息，生成一封符合SMTP等郵件標(biāo)準(zhǔn)的郵件，然后采用SMTP協(xié)議將郵件發(fā)送到發(fā)送端郵件服務(wù)器。1.2.3. 郵件服務(wù)器郵件服務(wù)器是電子郵件系統(tǒng)的核心，它用來發(fā)送和接收郵件。郵件服務(wù)器不同于普通PC的是它幾乎是全天工作的，所以它可以在任何時(shí)候?yàn)橛脩籼峁┓?wù)，后面將提到這正是為什么需要郵件服務(wù)器的一個(gè)重要原因。很多ISP都提供免費(fèi)的郵件服務(wù)器，如126提供郵件服務(wù)器。郵件服務(wù)器向其它郵件服務(wù)器轉(zhuǎn)發(fā)郵件也是采用SMTP協(xié)議。1.3. 郵件的收發(fā)過程一般情況下，一封郵件的發(fā)送和接收過程如下。1) 發(fā)信人在用戶代理里編輯郵件，包括填寫發(fā)信人郵箱、收信人郵箱和郵件標(biāo)題等

4、等。2) 用戶代理提取發(fā)信人編輯的信息，生成一封符合郵件格式標(biāo)準(zhǔn)（RFC822）的郵件。3) 用戶代理用SMTP將郵件發(fā)送到發(fā)送端郵件服務(wù)器（即發(fā)信人郵箱所對(duì)應(yīng)的郵件服務(wù)器）。4) 發(fā)送端郵件服務(wù)器用SMTP將郵件發(fā)送到接收端郵件服務(wù)器（即收信人郵箱所對(duì)應(yīng)的郵件服務(wù)器）。5) 收信人調(diào)用用戶代理。用戶代理用POP3協(xié)議從接收端郵件服務(wù)器取回郵件。6) 用戶代理解析收到的郵件，以適當(dāng)?shù)男问匠尸F(xiàn)在收信人面前。第2章. SMTP詳解2.1. 通信過程一個(gè)具體的SMTP通信（如發(fā)送端郵件服務(wù)器與接收端服務(wù)器的通信）的過程如下。1) 發(fā)送端郵件服務(wù)器（以下簡稱客戶端）與接收端郵件服務(wù)器（以下簡稱服務(wù)器）

5、的25號(hào)端口建立TCP連接。2) 客戶端向服務(wù)器發(fā)送各種命令，來請(qǐng)求各種服務(wù)（如認(rèn)證、指定發(fā)送人和接收人）。3) 服務(wù)器解析用戶的命令，做出相應(yīng)動(dòng)作并返回給客戶端一個(gè)響應(yīng)。4) 2)和3)交替進(jìn)行，直到所有郵件都發(fā)送完或兩者的連接被意外中斷。從這個(gè)過程看出，命令和響應(yīng)是SMTP協(xié)議的重點(diǎn)，下面將予以重點(diǎn)講述。2.2. 命令和響應(yīng)2.2.1. 格式SMTP的命令不多（14個(gè)），它的一般形式是：COMMAND Parameter 。其中COMMAND是ASCII形式的命令名，Parameter是相應(yīng)的命令參數(shù)，是回車換行符(0DH, 0AH)。SMTP的響應(yīng)也不復(fù)雜，它的一般形式是：XXX Rea

6、dable Illustration。XXX是三位十進(jìn)制數(shù)；Readable Illustration是可讀的解釋說明，用來表明命令是否成功等。XXX具有如下的規(guī)律：以2開頭的表示成功，以4和5開頭的表示失敗，以3開頭的表示未完成（進(jìn)行中）。2.2.2. 一個(gè)例子命令和響應(yīng)的格式是語法，各命令和響應(yīng)的意思則是語義，各命令和各響應(yīng)在時(shí)間上的關(guān)系則是同步。下面將通過一個(gè)簡單的SMTP通信過程來說明協(xié)議的這三個(gè)要素。C：telnet 25 /*以telnet方式連接126郵件服務(wù)器*/S：220 Anti-spam GT for Coremail System (126com071018)/* 22

7、0為響應(yīng)數(shù)字，其后的為歡迎信息，會(huì)應(yīng)服務(wù)器不同而不同*/C：HELO /* HELO 后用來填寫返回域名（具體含義請(qǐng)參閱RFC821），但該命令并不檢查后面的參數(shù) */：250 OKC: MAIL FROM: bripengandre /* 發(fā)送者郵箱 */S：250 ./* “”代表省略了一些可讀信息 */C：RCPT TO: bripengandre/* 接收者郵箱 */S：250 ./* “”代表省略了一些可讀信息 */C：DATA /* 請(qǐng)求發(fā)送數(shù)據(jù) */S：354 Enter mail, end with . on a line by itselfC：Enjoy Protocol S

8、tudingC：.S：250 Message sentC：QUIT /* 退出連接 */S：221 Bye分析上面的過程可參考注釋進(jìn)行，這里要補(bǔ)充如下幾點(diǎn)。1) “C：”開頭的行(不包括C：)是客戶端的輸入，而以“S：”開頭的行(不包括S：)則是服務(wù)器的輸出。2) 上述的命令并不一定會(huì)一次性成功，服務(wù)器會(huì)返回錯(cuò)誤響應(yīng)，客戶端應(yīng)該按照協(xié)議規(guī)定的時(shí)序，來輸入后續(xù)的命令（或重復(fù)執(zhí)行失敗的命令，或重置會(huì)話，或退出會(huì)話等等）。2.2.3. 常用命令SMTP命令不區(qū)分大小寫，但參數(shù)區(qū)分大小寫，有關(guān)這方面的詳細(xì)說明請(qǐng)參考RFC821。常用的命令如下。HELO 。向服務(wù)器標(biāo)識(shí)用戶身份發(fā)送者能欺騙，說謊，但一般

9、情況下服務(wù)器都能檢測到。MAIL FROM: 。為發(fā)送者地址，此命令用來初始化郵件傳輸，即用來對(duì)所有的狀態(tài)和緩沖區(qū)進(jìn)行初始化。RCPT TO： 。用來標(biāo)志郵件接收者的地址，常用在MAIL FROM后，可以有多個(gè)RCPT TO。DATA 。將之后的數(shù)據(jù)作為數(shù)據(jù)發(fā)送，以.標(biāo)志數(shù)據(jù)的結(jié)尾。REST 。重置會(huì)話，當(dāng)前傳輸被取消。NOOP 。要求服務(wù)器返回OK應(yīng)答，一般用作測試。QUIT 。結(jié)束會(huì)話。VRFY 。驗(yàn)證指定的郵箱是否存在，由于安全方面的原因，服務(wù)器大多禁止此命令。EXPN 。驗(yàn)證給定的郵箱列表是否存在，由于安全方面的原因，服務(wù)器大多禁止此命令。HELP 。查詢服務(wù)器支持什么命令。2.2.4

10、. 常用響應(yīng)常用的響應(yīng)如下所示，數(shù)字后的說明是從英文譯過來的。更詳細(xì)的說明請(qǐng)參考RFC821。501參數(shù)格式錯(cuò)誤502命令不可實(shí)現(xiàn)503錯(cuò)誤的命令序列504命令參數(shù)不可實(shí)現(xiàn)211系統(tǒng)狀態(tài)或系統(tǒng)幫助響應(yīng)214幫助信息220domain服務(wù)就緒221domain服務(wù)關(guān)閉421domain服務(wù)未就緒，關(guān)閉傳輸信道250要求的郵件操作完成251用戶非本地，將轉(zhuǎn)發(fā)向forward-path450要求的郵件操作未完成，郵箱不可用550要求的郵件操作未完成，郵箱不可用451放棄要求的操作；處理過程中出錯(cuò)551用戶非本地，請(qǐng)嘗試forward-path452系統(tǒng)存儲(chǔ)不足，要求的操作未執(zhí)行552過量的存儲(chǔ)分配，

11、要求的操作未執(zhí)行553郵箱名不可用，要求的操作未執(zhí)行354開始郵件輸入，以.結(jié)束554操作失敗第3章. SMTP的擴(kuò)充3.1. SMTP的缺點(diǎn)從2.2.2的例子可以看出，SMTP至少還有如下缺點(diǎn)。1) 命令過于簡單，沒提供認(rèn)證等功能。2) 只傳送7位的ASCII碼，不能傳送二進(jìn)制文件。針對(duì)缺點(diǎn)1)，標(biāo)準(zhǔn)化組織制定了擴(kuò)充的SMTP（即ESMTP），對(duì)應(yīng)的RFC文檔為RFC1425。針對(duì)缺點(diǎn)2)，標(biāo)準(zhǔn)化組織在兼容SMTP的前提下，提出了傳送非7位ASCII碼的方法，對(duì)應(yīng)的RFC文檔有兩個(gè)：郵件首部的擴(kuò)充對(duì)應(yīng)于RFC1522，郵件正文的擴(kuò)充對(duì)應(yīng)與RFC1521（即MIME）。3.2. ESMTPES

12、MTP最顯著的地方是添加了用戶認(rèn)證功能。如果用戶想使用ESMTP提供的新命令，則在初次與服務(wù)器交互時(shí)，發(fā)送的命令應(yīng)該是EHLO而不是HELO。先來看一個(gè)例子。C：telnet 25 /*以telnet方式連接126郵件服務(wù)器*/S：220 Anti-spam GT for Coremail System (126com071018)/* 220為響應(yīng)數(shù)字，其后的為歡迎信息，會(huì)應(yīng)服務(wù)器不同而不同*/C：EHLO /* 除了HELO所具有的功能外，EHLO主要用來查詢服務(wù)器支持的擴(kuò)充功能 */S：250-mailS：250-AUTH LOGIN PLAINS：250-AUTH=LOGIN PLAI

13、NS：250 8BITMIME /* 最后一個(gè)響應(yīng)數(shù)字應(yīng)答碼之后跟的是一個(gè)空格，而不是- */C：AUTH LOGIN /* 請(qǐng)求認(rèn)證 */S：334 dxNlcm5hbWU6 /* 服務(wù)器的響應(yīng)經(jīng)過base64編碼了的“Username” */C：Y29zdGFAYW1heGl0Lm5ldA= /* 發(fā)送經(jīng)過BASE64編碼了的用戶名 */S：334 UGFzc3dvcmQ6 /* 經(jīng)過BASE64編碼了的Password: */C：MTk4MjIxNA= /* 客戶端發(fā)送的經(jīng)過BASE64編碼了的密碼 */S：235 auth successfully/* 認(rèn)證成功 */C: MAIL F

14、ROM: bripengandre /* 發(fā)送者郵箱 */S：250 ./* “”代表省略了一些可讀信息 */C：RCPT TO: bripengandre/* 接收者郵箱 */S：250 ./* “”代表省略了一些可讀信息 */C：DATA /* 請(qǐng)求發(fā)送數(shù)據(jù) */S：354 Enter mail, end with . on a line by itselfC：Enjoy Protocol StudingC：.S：250 Message sentC：QUIT /* 退出連接 */S：221 Bye對(duì)于這個(gè)例子有如下幾點(diǎn)說明。1) 只是一個(gè)示意性的過程，再輸入用戶名、密碼時(shí)需采用base64

15、編碼，這需要專門的計(jì)算，所以在telnet終端上模擬比較麻煩。2) 認(rèn)證過程有很多種，有基于明文的認(rèn)證，也有基于MD5加密的認(rèn)證，這里給出的只是一個(gè)示意性的過程。3) EHLO對(duì)于具體服務(wù)器，響應(yīng)會(huì)不同，關(guān)鍵字“8BITMIME”用來說明服務(wù)器是否支持正文中傳送位ASCII碼，而以“X”開頭的關(guān)鍵字都是指服務(wù)器自定義的擴(kuò)充（還沒納入RFC標(biāo)準(zhǔn)）更詳細(xì)的說明，請(qǐng)參看RFC1425。3.3. 郵件首部的擴(kuò)充首部通過兩種編碼方式來支持傳送非7位ASCII碼。它首先通過一個(gè)如下格式的編碼字來表明所用的編碼方式。=?charset?encoding?encoded-text?textcharset是字符

16、集規(guī)范。有效值是兩個(gè)字符串us-ascii和iso-8859-x，其中x 是一個(gè)單個(gè)數(shù)字，例如iso-8859-1中的數(shù)字為“ 1”。encoding是一個(gè)單個(gè)字符用來指定編碼方法，支持兩個(gè)值。Q代表quoted-printable（可打?。┚幋a。任何要發(fā)送的字符若其第8比特置1則被作為3個(gè)字符發(fā)送：第1個(gè)是字符是“=”，后面的兩個(gè)字符對(duì)應(yīng)于字符的十六進(jìn)制表示。例如對(duì)于二進(jìn)制碼11111111，其對(duì)應(yīng)的十六進(jìn)制表示為“FF”，所以對(duì)應(yīng)的編碼位“=FF”。為了能夠傳輸“=”，“=”的編碼方式與第比特置的字符相同，因?yàn)槠涠M(jìn)制代碼為00111101，所以對(duì)應(yīng)的編碼為“=3D”?？梢钥闯鲞@種編碼方式

17、的開銷達(dá)200%，所以只適合傳送只含有少量非7位ASCII碼的文本。B代表base64編碼。它的編碼方法是先將二進(jìn)制代碼劃分為一個(gè)24bit長的單元，然后將這24 bit單元?jiǎng)澐譃?個(gè)6 bit組。每個(gè)組按圖 2所示的方法轉(zhuǎn)換成ASCII碼。圖 2base64映射表可以看出這種映射方法是這樣的：0-25依次映射成A-Z，26-51依次映射成a-z,52-61依次映射成數(shù)字0-9，然后62映射成+，63映射成/。對(duì)于二進(jìn)制代碼01001001 00110001 01111001，先將其劃分成4個(gè)6 bit組，即010010 0100011 000101 111001。接著按圖 2所示的映射表，可

18、得到base64編碼為：STF5?？梢钥闯?，這種編碼方式的開銷是25%，相對(duì)quoted-printable編碼來說，它更適合用來傳送含大量非7位ASCII碼的二進(jìn)制文件。3.4. 正文的擴(kuò)充正文的擴(kuò)充主要是使正文不僅可以傳輸NVT ASCII字符，而且可以傳輸任意字符，對(duì)應(yīng)的文檔為RFC1511（即MIME）。MIME全稱為“Multiple Internet Mail Extensions”, 比較確切的中文名稱為“多用途互聯(lián)網(wǎng)郵件擴(kuò)展”。它通過新增一些郵件首部字段、郵件內(nèi)容格式和傳送編碼，使得其成為一種應(yīng)用很廣泛的可以傳輸多媒體的電子郵件規(guī)范。更詳細(xì)的說明請(qǐng)參看另一篇文章MIME協(xié)議分析

19、和RFC1511。第4章. 常見的疑問4.1. 為什么需要SMTP服務(wù)器一般的PC資源不夠，處理能力不夠，不可能全天候地連接在因特網(wǎng)上來收發(fā)郵件。所以使用SMTP服務(wù)器，可以讓多個(gè)用戶共用服務(wù)器，有效地降低了成本。4.2. SMTP和郵件格式的關(guān)系如前所述，SMTP是客戶機(jī)向服務(wù)器發(fā)送郵件時(shí)所使用的協(xié)議，其核心是2.2中所述的命令和響應(yīng)，至于它命令和響應(yīng)中所帶的參數(shù)采用什么格式，則是依賴于其他標(biāo)準(zhǔn)的。例如DATA后所帶的參數(shù)，則應(yīng)遵循郵件格式標(biāo)準(zhǔn)RFC822SMTP和郵件格式的關(guān)系可用這么一個(gè)例子來說明。甲與乙書信往來，甲通過郵局向乙發(fā)信，郵局間轉(zhuǎn)交郵件可看成使用了SMTP協(xié)議，至于書信的格式

20、則會(huì)因?yàn)榈貐^(qū)習(xí)慣等的不同而不同（中國人的書信格式和美國人的書信格式不同），這個(gè)書信格式則可看成是郵件格式標(biāo)準(zhǔn)。應(yīng)當(dāng)認(rèn)識(shí)到不能孤立地看待協(xié)議，各個(gè)協(xié)議之間往往存在著耦合關(guān)系，但為了分析方便，我們?cè)诰唧w敘述某個(gè)協(xié)議時(shí)，只能抓住主要矛盾主要闡述單個(gè)協(xié)議。4.3. 瀏覽器發(fā)送郵件用的什么協(xié)議瀏覽器如IE、Maxthon可通過登陸用戶郵箱，來收發(fā)郵件，這是怎樣實(shí)現(xiàn)的？例如bripengandre可通過登陸來收發(fā)郵件。這個(gè)過程是這樣的：bripengandre在提供的郵件頁面上填寫的相應(yīng)信息（如發(fā)信人郵箱、收信人郵箱等），通過http協(xié)議被提交給126服務(wù)器；126服務(wù)器根據(jù)這些信息組裝一封符合郵件規(guī)范的

21、郵件（就像用戶代理一樣）；然后通過SMTP協(xié)議將這封郵件發(fā)送到接收端郵件服務(wù)器?？梢钥闯?，瀏覽器發(fā)送郵件只是用戶代理的功能直接放到郵件服務(wù)器上去做了，至于郵件服務(wù)器間發(fā)送郵件還是采用的SMTP協(xié)議。我們看問題，如果有必要還是要適當(dāng)?shù)赝高^現(xiàn)象看本質(zhì)。4.4. 如何用實(shí)驗(yàn)驗(yàn)證SMTP的通信過程1) 可以通過ethereal等協(xié)議分析軟件來抓包分析協(xié)議。2) 可以利用socket編程實(shí)現(xiàn)SMTP的通信過程。3) 可以利用用戶代理來查看一封郵件的原始編碼。例如在Foxmail中，可以選擇郵件列表右鍵菜單的“原始信息”進(jìn)行查看。第5章. 分析方案IDProtocolCaptured contentsus

22、er namepasswordsenderreceiversubjectcontentsattachments4smtp表 1 協(xié)議分析要求表 1給出了協(xié)議分析要求。容易看出，獲取各個(gè)字段是比較容易的。我們可以抓取客戶端與服務(wù)器端的交互信息，然后根據(jù)各命令字或響應(yīng)字來提取出我們想要的字段。例如，要獲取user name，我們只需檢測到服務(wù)器端要求客戶端發(fā)送用戶名這個(gè)時(shí)候，然后提取這之后客戶端的發(fā)送信息即可。需要說明的是，雖然客戶端與服務(wù)端交互的信息可能經(jīng)過了編碼或加密，但我們?nèi)阅軌蛲ㄟ^解碼或解密來獲得所需要的信息。第6章. 參考資料1 RFC文檔：RFC821對(duì)應(yīng)SMTP協(xié)議，RFC822對(duì)應(yīng)

23、郵件標(biāo)準(zhǔn)，RFC1425對(duì)應(yīng)ESMTP，RFC1522對(duì)應(yīng)郵件首部的擴(kuò)充，RFC1521對(duì)應(yīng)郵件正文的擴(kuò)充，RFC1939對(duì)應(yīng)POP3協(xié)議。2 /rfcs/，上面有全面的英文RFC文檔3 4 Stevens, W.R., TCP/IP Illustrated, Vol1. Addision-Wesley, 機(jī)械工業(yè)出版社，2002MIME郵件面面觀(轉(zhuǎn)載) 分類： Network Security 2008-03-11 20:08 714人閱讀 評(píng)論(0) 收藏 舉報(bào) 轉(zhuǎn)載自Q 什么是MIME？什么是MIME郵件？ A MIME, 全稱為“Multipurp

24、ose Internet Mail Extensions”, 比較確切的中文名稱為“多用途互聯(lián)網(wǎng)郵件擴(kuò)展”。它是當(dāng)前廣泛應(yīng)用的一種電子郵件技術(shù)規(guī)范，基本內(nèi)容定義于RFC 2045-2049。 自然，MIME郵件就是符合MIME規(guī)范的電子郵件，或者說根據(jù)MIME規(guī)范編碼而成的電子郵件。 在MIME出臺(tái)之前，使用RFC 822只能發(fā)送基本的ASCII碼文本信息，郵件內(nèi)容如果要包括二進(jìn)制文件、聲音和動(dòng)畫等，實(shí)現(xiàn)起來非常困難。MIME提供了一種可以在郵件中附加多種不同編碼文件的方法，彌補(bǔ)了原來的信息格式的不足。實(shí)際上不僅僅是郵件編碼，現(xiàn)在MIME經(jīng)成為HTTP協(xié)議標(biāo)準(zhǔn)的一個(gè)部分。 下面舉幾個(gè)MIME郵

25、件的例子，讓我們先對(duì)MIME編碼的格式有個(gè)直觀的印象。例1是最簡單的，只帶純文本正文，基本上就是RFC 822格式；例2復(fù)雜一些，包含純文本和超文本正文；例3是最復(fù)雜的，包含純文本正文、超文本正文、內(nèi)嵌資源和文件附件。其中，行號(hào)和行號(hào)后的空格是為了分析方便而另外加的，“. . . .”表示此處省略了大段編碼。 例1 1 Date: Thu, 18 Apr 2002 09:32:45 +0800 2 From: 3 To: 4 Subject: Test 5 Mime-Version: 1.0 6 Content-Type: text/plain; charset=iso-8859-1 7 8

26、This is a simple mail. 9例2 1 From: bhw98 2 Reply-To: bhw98 3 To: 4 Subject: Re: help 5 X-Mailer: Foxmail 4.2 cn 6 Mime-Version: 1.0 7 Content-Type: multipart/alternative; 8 boundary=002_Dragon307572345230_= 9 10 11 This is a multi-part message in MIME format. 12 13 -=002_Dragon307572345230_= 14 Cont

27、ent-Type: text/plain; charset=GB2312 15 Content-Transfer-Encoding: quoted-printable 16 17 bluesky7810=A3=AC=C4=FA=BA=C3=A3=A1 18 19 =A1=A1=A1=A1=D4=DA=CF=C2=C6=AA=D7=EE=BA=F3=BF=C9=D2=D4=CF=C2=D4=D8=B0=A1=A3=AC=C4=E3 . . . . 30 =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1

28、=A12003-04-07 31 32 -=002_Dragon307572345230_= 33 Content-Type: text/html; charset=GB2312 34 Content-Transfer-Encoding: quoted-printable 35 36 37 38 40 . . . . 79 80 81 -=002_Dragon307572345230_=- 82例3 1 Return-Path: 2 Delivered-To: bhw98 3 Received: (qmail 75513 invoked by alias); 20 May 2002 02:19

29、:53 -0000 4 Received: from unknown (HELO bluesky) (35) 5 by 43 with SMTP; 20 May 2002 02:19:53 -0000 6 Message-ID: 7 From: =?gb2312?B?wLbAtrXEzOwNCg=?= 8 To: bhw98 9 Cc: 10 Subject: =?gb2312?B?ztK1xLbgtK6/2rPM0PI=?= 11 Date: Sat, 20 May 2002 10:03:36 +0800 12 MIME-Version: 1

30、.0 13 Content-Type: multipart/mixed; 14 boundary=-=_NextPart_000_007A_01C3115F.80DFC5E0 15 X-Priority: 3 16 X-MSMail-Priority: Normal 17 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 18 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 19 20 This is a multi-part message in MIME format. 2

31、1 22 -=_NextPart_000_007A_01C3115F.80DFC5E0 23 Content-Type: multipart/related; type=multipart/alternative; 24 boundary=-=_NextPart_001_007B_01C3115F.80DFC5E0 25 26 27 -=_NextPart_001_007B_01C3115F.80DFC5E0 28 Content-Type: multipart/alternative; 29 boundary=-=_NextPart_002_007C_01C3115F.80DFC5E0 30

32、 31 -=_NextPart_002_007C_01C3115F.80DFC5E0 32 Content-Type: text/plain; charset=gb2312 33 Content-Transfer-Encoding: quoted-printable 34 35 bhw98, =C4=E3=BA=C3! 36 =D5=E2=CA=C7=CE=D2=D0=B4=B5=C4=B6=E0=B4=AE=BF=DA=CD=A8=D0=C5=B5=C4=B3=CC=D0= 37 =F2, =C7=EB=D6=B8=BD=CC! 38 39 40 -=_NextPart_002_007C_0

33、1C3115F.80DFC5E0 41 Content-Type: text/html; charset=gb2312 42 Content-Transfer-Encoding: quoted-printable 43 44 45 =C7=E7=C0=CA 46 47 BODY 48 COLOR: #0033cc; FONT-FAMILY: =CB=CE=CC=E5, Arial, Helvetica; FONT-SIZE: = 49 9pt; MARGIN-LEFT: 10px; MARGIN-TOP: 25px 50 51 52 53 55 56 bhw98, =C4=E3=BA=C3!

34、57 =D5=E2=CA=C7=CE=D2=D0=B4=B5=C4=B6=E0=B4=AE=BF=DA=CD=A8=D0=C5=B5=C4=B3=CC= 58 =D0=F2, =C7=EB=D6=B8=BD=CC! 59 60 61 -=_NextPart_002_007C_01C3115F.80DFC5E0- 62 63 -=_NextPart_001_007B_01C3115F.80DFC5E0 64 Content-Type: image/jpeg; name=?gb2312?B?x+fAyrGzvrAuSlBH?= 65 Content-Transfer-Encoding: base6

35、4 66 Content-ID: 67 68 /9j/4AAQSkZJRgABAgEASABIAAD/7QVoUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAASAAAAAEA 69 AQBIAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgAB 70 AAAAAAAAAAI4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEA . . . . 169 RxVw98Vawq12xQ44q0cKtHFDWKGs

36、Kt4EtiuKt4q/9k= 170 171 -=_NextPart_001_007B_01C3115F.80DFC5E0- 172 173 -=_NextPart_000_007A_01C3115F.80DFC5E0 174 Content-Type: application/msword; name=readme.doc 175 Content-Transfer-Encoding: base64 176 Content-Disposition: attachment; filename=readme.doc 177 178 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAA

37、PgADAP7/CQAGAAAAAAAAAAAAAAABAAAAJgAAAAAAAAAA 179 EAAAKAAAAAEAAAD+/AAAAACUAAAD/ 180 / . . . .1688 AAAAAAAAAAAAAAAAAAA=16891690 -=_NextPart_000_007A_01C3115F.80DFC5E01691 Content-Type: application/x-zip-compressed;1692 name=?gb2312?B?tuC0rr/azajQxbXE1LTC6y56aXA=?=1693 Content-Transfer-Encoding: base64

38、1694 Content-Disposition: attachment;1695 filename=?gb2312?B?tuC0rr/azajQxbXE1LTC6y56aXA=?=16961697 UEsDBBQAAAAIAFKAoi7qOMOvLw0AAABWAAAUAAAAtuC0rr/azajQxbXE1LTC6y5kb2PtXHtwVNUZ1698 /+4+kk3IQoAkBkRYQkSgbrKb7IYNEMwmm6ckG0jCI0boZneTbJJ9sNlAEsdOtFqd8Z846tQ6PhB11699 hrZTJoK0Vhgf1aGt4rMy6D8tdugfTjuOpcBIR9

39、j+vvsIy4YkRNTRen87v/ud53cee+6557vn7L73 . . . .3125 zajQxbXE1LTC6y5kb2NQSwUGAAAAAAEAAQBCAAAAYQ0AAA=31263127 -=_NextPart_000_007A_01C3115F.80DFC5E0-3128Q 在開始研究MIME郵件的時(shí)候，如何得到這樣的源碼？ A 一些功能比較完善的郵件客戶端軟件，如微軟的Outlook Express，國產(chǎn)的Foxmail等，都提供了查看和保存郵件源碼(原始信息)的功能。在Foxmail中，選擇郵件列表右鍵菜單的“原始信息”進(jìn)行查看，主菜單的“文件-導(dǎo)出”進(jìn)行保存。

40、在Outlook Express中，對(duì)應(yīng)的操作分別是“屬性”和“另存為”。所保存的.eml文件，可以調(diào)用這些程序打開。 Q 請(qǐng)介紹一下MIME郵件的組成？ A 總體來說，MIME消息由消息頭和消息體兩大部分組成?，F(xiàn)在我們關(guān)注的是MIME郵件，因此在以下的討論中姑且稱“消息”為“郵件”。在上面的例子中，例1的1-6行，例2的18行，例3的1-18行，是郵件頭；例1的89行，例2的1082行，例3的203128行，是郵件體。郵件頭與郵件體之間以空行進(jìn)行分隔，如例1的第7行，例2的第9行，例3的第19行。郵件頭中不允許出現(xiàn)空行。有一些郵件不能被郵件客戶端軟件識(shí)別，顯示的是原始碼，就是因?yàn)槭仔惺强招小?/p>

41、 郵件頭包含了發(fā)件人、收件人、主題、時(shí)間、MIME版本、郵件內(nèi)容的類型等重要信息。每條信息稱為一個(gè)域，由域名后加“: ”和信息內(nèi)容構(gòu)成，可以是一行，較長的也可以占用多行。域的首行必須“頂頭”寫，即左邊不能有空白字符（空格和制表符）；續(xù)行則必須以空白字符打頭，且第一個(gè)空白字符不是信息本身固有的，解碼時(shí)要過濾掉。如例2的7-8行，例3的4-5行，13-14行，分別屬于一個(gè)域。 郵件體包含郵件的內(nèi)容，它的類型由郵件頭的“Content-Type”域指出。常見的簡單類型有text/plain(純文本)和text/html(超文本)。 例2和例3中出現(xiàn)的multipart類型，是MIME郵件的精髓。郵件

42、體被分為多個(gè)段，每個(gè)段又包含段頭和段體兩部分，這兩部分之間也以空行分隔。常見的multipart類型有三種：multipart/mixed, multipart/related和multipart/alternative。從它們的名稱，不難推知這些類型各自的含義和用處。它們之間的層次關(guān)系可歸納為下圖所示： +- multipart/mixed -+| | +- multipart/related -+ | | | | | +- multipart/alternative -+ +-+ | +-+ | | | | | 內(nèi)嵌資源 | | | 附件 | | | | +-+ +-+ | +-+ | +

43、-+ | | | | 純文本正文 | | 超文本正文 | | | | | | +-+ +-+ | +-+ | +-+ | | | | | 內(nèi)嵌資源 | | | 附件 | | | +-+ +-+ | +-+ | | | | +-+ | |+-+可以看出，如果在郵件中要添加附件，必須定義multipart/mixed段；如果存在內(nèi)嵌資源，至少要定義multipart/related段；如果純文本與超文本共存，至少要定義multipart/alternative段。什么是“至少”？舉個(gè)例子說，如果只有純文本與超文本正文，那么在郵件頭中將類型擴(kuò)大化，定義為multipart/related，甚至mul

44、tipart/mixed，都是允許的。 multipart諸類型的共同特征是，在段頭指定“boundary”參數(shù)字符串，段體內(nèi)的每個(gè)子段以此串定界。所有的子段都以“-”+boundary行開始，父段則以“-”+boundary+“-”行結(jié)束。段與段之間也以空行分隔。在郵件體是multipart類型的情況下，郵件體的開始部分(第一個(gè)“-”+boundary行之前)可以有一些附加的文本行，相當(dāng)于注釋，解碼時(shí)應(yīng)忽略。段間也可以有一些附加的文本行，不會(huì)顯示出來，如果有興趣，不妨驗(yàn)證一下。 結(jié)合boundary定界和multipart層次關(guān)系圖，我們分析一下例2和例3的郵件體層次與段嵌套關(guān)系。 在例2中

45、，10-12行是附加文本行，13-82行是multipart/alternative型的段，包含兩個(gè)子段：13-30行是純文本正文，32-79行是超文本正文。 在例3中，20-21行是附加文本行，22-3127行是multipart/mixed型的段，包含3個(gè)子段：22-171行是multipart/related段，173-1688行與1690-3125行是兩個(gè)附件。multipart/related段又包含兩個(gè)子段：27-61行是multipart/alternative段，63-169行是一個(gè)內(nèi)嵌資源(圖片)。multipart/alternative段又包含兩個(gè)子段：31-48行是純文

46、本正文，40-59行是超文本正文。 例1只有純文本正文，實(shí)際上屬于multipart層次關(guān)系圖中的一個(gè)特殊情況。如果非要避簡就繁，寫成下面的形式，也是完全符合MIME精神的。 Date: Thu, 18 Apr 2002 09:32:45 +0800From: To: Subject: TestMime-Version: 1.0Content-Type: multipart/alternative; boundary=(_) -(_)Content-Type: text/plain; charset=iso-8859-1Content-Transfer-Encoding: 7bit This

47、is a simple mail. -(_)-Q 在郵件頭和段頭中，有哪一些常見的域？ A 在郵件頭中，有很多從RFC 822沿用的域名，MIME也增加了一些。常見的標(biāo)準(zhǔn)域名和含義如下 域名 含義 添加者 Received 傳輸路徑 各級(jí)郵件服務(wù)器 Return-Path 回復(fù)地址 目標(biāo)郵件服務(wù)器 Delivered-To 發(fā)送地址 目標(biāo)郵件服務(wù)器 Reply-To 回復(fù)地址 郵件的創(chuàng)建者 From 發(fā)件人地址 郵件的創(chuàng)建者 To 收件人地址 郵件的創(chuàng)建者 Cc 抄送地址 郵件的創(chuàng)建者 Bcc 暗送地址 郵件的創(chuàng)建者 Date 日期和時(shí)間 郵件的創(chuàng)建者 Subject 主題 郵件的創(chuàng)建者 Me

48、ssage-ID 消息ID 郵件的創(chuàng)建者 MIME-Version MIME版本 郵件的創(chuàng)建者 Content-Type 內(nèi)容的類型 郵件的創(chuàng)建者 Content-Transfer-Encoding 內(nèi)容的傳輸編碼方式 郵件的創(chuàng)建者 非標(biāo)準(zhǔn)的、自定義域名都以X-開頭，例如X-Mailer, X-MSMail-Priority等，通常在接收和發(fā)送郵件的是同一程序時(shí)才能理解它們的意義。 在段頭中，大致有如下一些域 域名 含義 Content-Type 段體的類型 Content-Transfer-Encoding 段體的傳輸編碼方式 Content-Disposition 段體的安排方式 Content-ID 段體的ID Content-Location 段體的位置(路徑) Co