轉(zhuǎn)載鏈接：http://wenku.baidu.com/view/7246de671ed9ad51f01df277.html

電子郵件也許是一個Internet上的流行最廣泛的應用。也是我們現(xiàn)在的大多數(shù)網(wǎng)絡辦公流程的基礎(chǔ)。各種郵件服務器很多,但都大都遵循以1982年出版的RFC822--《ARPA網(wǎng)絡文本信息格式標準(STANDARD?FOR?THE?FORMAT?OF?ARPA?INTERNET?TEXT?MESSAGES)》為基礎(chǔ)的一系列郵件格式的規(guī)定。?
?
RFC（The?Requests?for?Comments）是用來規(guī)定互聯(lián)網(wǎng)工作標準的文檔。我們使用的時候并沒有注意到這些協(xié)議在我們的郵件通信過程中默默的發(fā)揮著的作用，這絲毫也不能減低這些作用的重要性。郵件內(nèi)部還有很多不為人知的秘密。
?
在RFC822中規(guī)定一封信包括一個必須的多個頭部域（header?fields）和一個可選的體部（body）組成。從一封信頭開始至第一個空行都是頭部。頭部定義了一個郵件的各項基本要素，路由信息等內(nèi)容。
?
在Outlook?Express中選定一封信看它的屬性。在詳細資料選項卡中顯示的就是這封郵件的頭部內(nèi)容。也可以選定一封信，另存為一個.eml文件。由于文件是一個純文本文件，用一般的編輯器打開就可以看到郵件的內(nèi)容。?
頭部有各個頭部域組成，每一個頭部域都包括域名（field-name）和域體（field-body），它們之間以"："分隔。每一個頭部域都可以看作由ASCII碼字符組成的獨立的文本。常見的頭部域包括："Return-Path",?"Received",?"Date",?"From",?"Subject",?"Sender","To",?"cc","MIME-Version"等。各頭部域之間沒有規(guī)定順序。??就像各個域的名字一樣。他們表示的具體意義也不同。?Return-Path域表示退信的地址。?Received域表示路由信息。
?
Internet上的信件可能是由多個服務器依靠協(xié)議傳遞到達最終的目的郵箱的。每一個服務器都會把自己的一段
Received域信息添加近信件。所以可能有多段Received域，依傳遞次序排列。這個域的內(nèi)容很有意思，我們可以根據(jù)每一段的內(nèi)容來跟蹤一封信在internet上的傳遞過程。網(wǎng)管人員也可以根據(jù)這些信息做出很有價值的判斷。
??例如一段代碼中???Received:?from?unknown?(unknown?[202.108.44.208])?by?mx7.163.com?(Postfix)?with?SMTP?id?74E0E8?for;?Fri,?28?Feb?2003?18:10:25?+0800?(CST)中，from?表示發(fā)送主機，by表示接受主機，via物理路徑（本例沒有），with表示使用的協(xié)議，id表示接受消息號，for表示目的郵件地址，分號后面表示時間。
??Date域表示建立信件的時間。???From域表示郵件作者。
??Subject域就是郵件的主題。
??Sender域表示郵件的實際發(fā)送者。???To,cc域都表示接受的郵件地址。
??MIME-Version域表示MIME的版本（以后擴充的域）
??還有一個域—Content-Type。標識了一個重要的概念：郵件內(nèi)容的格式。這個域的內(nèi)容根據(jù)互聯(lián)網(wǎng)的發(fā)展產(chǎn)生，使郵件可以用來傳輸非文本內(nèi)容，在RFC822中并沒有定義，而是在后續(xù)的RFC2045,RFC2046等文檔中有定義。
??還有一些不太常見的頭部域，如"References","Message-ID"域。以及一些由不同廠家定義的自己的域（域名以"X-"開頭）。
??知道了這些知識，就可以看懂郵件頭部。了解到那些郵件的秘密。???比如這是一封郵件的頭部。
Return-Path:?"sea"?
Received:?from?unknown?(unknown?[202.108.44.208])?by?mx7.163.com?(Postfix)?with?SMTP?id?74E0E8?for??Fri,?28?Feb?2003?18:10:25?+0800?(CST)
Received:?from?smtp.netcs.com?(unknown?[211.150.100.6])
by?192.168.1.208?(Coremail:www.163.com)?with?SMTP?id?cAsAAJY1Xz7kAmQG.1?for??Fri,?28?Feb?2003?18:10:30?+0800?(CST)?Received:?from?sea?(unknown?[192.168.18.160])
by?smtp.netcs.com?(Postfix)?with?ESMTP?id?E55D02675F
for??Fri,?28?Feb?2003?18:09:58?+0800?(CST)
Message-ID:?<000901c2df11$2fcac090$a012a8c0@sea>?From:?"sea"?
To:?"=?gb2312?B?usK6vQ==?="?
Message-ID:?<000901c2df11$2fcac090$a012a8c0@sea>?References:?<000c01c2decb$9c7b7860$a012a8c0@sea>??<004601c2dee2$28a348c0$2400a8c0@haostation>??<001501c2deeb$352b34a0$a012a8c0@sea>?Subject:?Re:?hello
Date:?Fri,?28?Feb?2003?18:07:22?+0800?MIME-Version:?1.0
Content-Type:?multipart/alternative;
boundary="----=_NextPart_000_0006_01C2DF54.3DDEBE50"?X-Priority:?3
X-MSMail-Priority:?Normal
X-Mailer:?Microsoft?Outlook?Express?6.00.2600.0000
X-MimeOLE:?Produced?By?Microsoft?MimeOLE?V6.00.2600.0000??
??通過辨認就可以知道這是一封從（From域）"sea"?寫給（To域）"=?gb2312?B?usK6vQ==?="?的Id（Message-ID域）為<000901c2df11$2fcac090$a012a8c0@sea>的回信。退信的地址（Return-Path域）是haibo.yang@netcscom可以看出（References域）這封信已經(jīng)經(jīng)過了連續(xù)三次回復。主題（Subject域）是Re:?hello。時間（Date域）是2003年的3月28日。郵件優(yōu)先級（X-Priority域）是普通。郵件的傳遞依次經(jīng)過了三個服務器（Received域）：smtp.netcs.com；unknown；和mx7.163.com。還可以看到各服務器的協(xié)議和到達各服務器的時間。其中Postfix和Coremail都是常見的郵件系統(tǒng)。其中郵件接收地址中的內(nèi)容由于包含漢字進行了編碼。?
??一封郵件首先建立的是核心的幾個域:From,To,Message-Id,Subject,Date等，在傳輸過程中每通過一個服務器再由此服務器在郵件頭部添加一行Received信息，最后一個服務器添加退信地址(Return-Path)。
??郵件頭的格式制定的細節(jié)是根據(jù)信息交流和網(wǎng)絡傳輸?shù)奶攸c制定的。閱讀它們不僅可以知道郵件傳輸?shù)拿孛?#xff0c;還可以讓我們體會到協(xié)議制定與實現(xiàn)間的互相關(guān)聯(lián)的緊密關(guān)系?？梢酝ㄟ^http://www.rfc.net/?查詢到RFC822，同時可以查詢到其它重要的RFC文檔。?
?
MX記錄的應用
在DNS服務器上除了可以建立主機名與IP地址的映射外，還可以建立其他多種映射，例如，建立某個主機名與其別名的映射；建立某個域名與其SMTP服務器的映射。在DNS服務器上創(chuàng)建的各項映射關(guān)系稱為記錄，一項映射關(guān)系就是一條記錄，在DNS服務器上創(chuàng)建的主機名與IP地址的映射關(guān)系稱為A記錄，主機名與別名的映射關(guān)系稱為CNAME記錄，域名與其SMTP服務器的映射關(guān)系稱為MX記錄。
在DNS服務器上為什么要建立MX記錄呢？即為什么要建立域名與其SMTP服務器的映射關(guān)系呢？這與電子郵件地址的表示形式和工作原理有關(guān)。郵件地址后綴部分表示的通常都是一個域名，而不是接收郵件的服務器的主機名，例如，郵件地址“zxx@it315.org”中的“it315.org”對應的就是一個域名。域只是一個邏輯組合概念，它并不代表真正的計算機，對于使用某個域名作為后綴的郵件地址，外界發(fā)送給它的電子郵件必須由一臺專門的SMTP服務器來進行接收和處理，接收和處理某個域的電子郵件的SMTP服務器即為該域的SMTP服務器，外界發(fā)送給某個域的電子郵件實際上都是發(fā)送給該域的SMTP服務器。外界如何知道一個域的SMTP服務器的地址呢？這就是通過管理該域的DNS服務器上的MX記錄來獲得的，這也就是在DNS服務器上為什么要建立域名與其SMTP服務器的映射關(guān)系的原因。
當某臺SMTP服務器要給“zxx@it315.org”發(fā)送一封電子郵件時，該SMTP服務器將根據(jù)郵件地址的后綴部分而去查詢“it315.org”這個域的MX記錄，得到這個域的SMTP服務器的主機名為“mail.it315.org”，然后將郵件發(fā)送給“mail.it315.org”這個SMTP服務器。
動手實踐??根據(jù)域名查詢SMTP服務器?

Windows操作系統(tǒng)自帶的nslookup命令可以查詢一個域的MX記錄。要想知道負責接收某個電子郵箱的郵件的SMTP服務器，可以先根據(jù)該郵件地址的后綴部分推斷出其域名，然后使用nslookup命令進行查詢即可。下面以查找負責接收“zxx@sina.com”這個郵件地址的SMTP服務器的信息為例進行講解。
?
啟動Windows下的DOS命令行窗口，執(zhí)行nslookup命令，結(jié)果如圖1.16所示。
?
圖1.16中“ns2.bjgwbn.net.cn”表示執(zhí)行nslookup命令的這臺計算機當前所使用的DNS查詢服務器的主機名，“211.161.46.84”則表示該DNS服務器的IP地址。
?
在圖1.16中的“>”提示符后面先輸入“set?type=mx”命令，設置所要查詢的記錄類型為MX，然后輸入域名
“sina.com”，結(jié)果如圖1.17所示。
?
圖1.16??????????????????????????????????圖1.17
圖1.17中顯示了“sina.com”這個域的SMTP服務器的主機名和IP地址，其中“sinamx.sina.com.cn”為SMTP服務器的主機名，并且該主機名對應了3個IP地址。這說明“sina.com”為了擴充其郵件處理能力，使用了3臺SMTP服務器來接收外界發(fā)送給該域的郵件，這3臺服務器的主機名都為“sinamx.sina.com.cn”，外界的SMTP服務器可以選擇其中任何一臺進行連接，然后將郵件發(fā)送給該服務器。
?
在圖1.17中的“>”提示符后面再次輸入“sina.com”，nslookup命令將再次查詢該域的MX記錄，結(jié)果如圖
1.18所示。
比較圖1.18中的用方框標識的部分，可以看到這兩次查詢出的“sinamx.sina.com.cn”所對應的3個IP地址的排列順序并不相同，第一次查詢時“202.108.3.187”排列在最前面，而第二次查詢時卻變成了“202.108.3.188”排列在最前面。如果繼續(xù)查詢“sina.com”域的MX記錄，可以看到“sinamx.sina.com.cn”所對應的3個IP地址的排列順序總是在改變。這是由于sina在管理“sina.com.cn”域的DNS服務器上進行了專門的設置，當外界每次查詢“sinamx.sina.com.cn”這個主機名的IP地址時，管理“sina.com.cn”域的DNS服務器都將對該主機名所對應的3個IP地址進行輪循排列后再返回。
?
圖1.18
對于查詢到一個主機名對應多個IP地址的情況，外界的計算機通常都是選擇其中的第一個IP地址來進行通信，只要管理“sina.com.cn”域的DNS服務器每次都將“sinamx.sina.com.cn”所對應的3個IP地址進行輪循排列后再返回給外界，外界的SMTP服務器將會分別選擇到不同的IP地址來進行通信，sina通過這種簡單的方式就在“sinamx.sina.com.cn”所對應的3臺SMTP服務器之間實現(xiàn)了負載均衡。
提示：使用nslookup查詢“sina.com”域的MX記錄時，讀者可能會遇到DNS服務器只返回SMTP服務器的主機名，而不返回該主機名所對應的IP地址的情況，這時候可以在原來的nslookup命令窗口中輸入“set?type=a”命令，即

將要查詢的記錄類型設置為A，然后輸入前面查詢到的SMTP服務器的主機名就可以得到其IP地址

電子郵件的工作原理
下面以sina和sohu這兩個電子郵局為例來講解電子郵件的傳輸過程和工作原理。假設sina郵箱的賬戶為lisi@sina.com，sohu郵箱的賬戶為wangwu@sohu.com，它們之間的郵件收發(fā)過程如圖1.20所示。
?
圖1.20
圖1.20中實線部分表示lisi@sina.com賬戶向wangwu@sohu.com賬戶發(fā)送郵件的過程，虛線部分表示wangwu@sohu.com賬戶向lisi@sina.com賬戶發(fā)送郵件的過程。下面通過分析lisi@sina.com賬戶向wangwu@sohu.com賬戶發(fā)送郵件的過程，來具體講解一封郵件從發(fā)送到接收所涉及的環(huán)節(jié)。
?
lisi@sina.com的郵件客戶端程序（這里假設為Outlook?Express）與sina的SMTP服務器建立網(wǎng)絡連接，并
以lisi的用戶名和密碼進行登錄后，使用SMTP協(xié)議把郵件發(fā)送給sina的SMTP服務器。
?
sina的SMTP服務器收到lisi@sina.com提交的電子郵件后，首先根據(jù)收件人的地址后綴判斷接收者的郵件地
址是否屬于該SMTP服務器的管轄范圍，如果是的話就直接把郵件存儲到收件人的郵箱中，否則，sina的SMTP服務器向DNS服務器查詢收件人的郵件地址后綴（sohu.com）所表示的域名的MX記錄，從而得到sohu的SMTP服務器信息，然后與sohu的SMTP服務器建立連接并采用SMTP協(xié)議把郵件發(fā)送給sohu的SMTP服務器。
?
sohu的SMTP服務器收到sina的SMTP服務器發(fā)來的電子郵件后，也將根據(jù)收件人的地址判斷該郵件是否屬于
該SMTP服務器的管轄范圍，如果是的話就直接把郵件存儲到收件人的郵箱中，否則（一般不會出現(xiàn)這種情況），sohu的SMTP服務器可能繼續(xù)轉(zhuǎn)發(fā)這封電子郵件，也可能丟棄這封電子郵件。
?
擁有wangwu@sohu.com賬戶的用戶通過郵件客戶端程序（這里假設也為Outlook?Express）與sohu的POP3/IMAP
服務器建立網(wǎng)絡連接，并以wangwu的用戶名和密碼進行登錄后，就可以通過POP3或IMAP協(xié)議查看wangwu@sohu.com郵箱中是否有新郵件，如果有的話，則使用POP3或IMAP協(xié)議讀取郵箱中的郵件。
圖1.20中的虛線部分表示wangwu@sohu.com賬戶向lisi@sina.?com賬戶發(fā)送郵件的過程，此過程與lisi@sina.com賬戶向wangwu@?sohu.com賬戶發(fā)送郵件的過程類似，這里不再復述。
多想一想??郵件客戶端程序和SMTP服務器
分別如何發(fā)送郵件
郵件客戶端軟件與SMTP服務器之間，以及兩臺SMTP服務器之間都采用SMTP協(xié)議進行通信。郵件客戶端軟件只采用SMTP協(xié)議發(fā)送郵件，即郵件客戶端軟件只作為SMTP協(xié)議的發(fā)送方。SMTP服務器既要采用SMTP協(xié)議向其他SMTP服務器發(fā)送郵件，又要采用SMTP協(xié)議接收其他SMTP服務器或郵件客戶端軟件發(fā)送來的郵件，即SMTP服務器既作為SMTP協(xié)議的發(fā)送方，又作為SMTP協(xié)議的接收方。郵件客戶端軟件與SMTP服務器都可以使用SMTP協(xié)議發(fā)送郵件，僅發(fā)送郵件這一功能而言，它們在技術(shù)實現(xiàn)上有何差異呢？它們的差異主要體現(xiàn)在以下兩個方面：
（1）SMTP服務器接收到郵件客戶端軟件發(fā)送來的郵件后，需要根據(jù)收件人地址的域名將郵件轉(zhuǎn)發(fā)給目標域的SMTP服務器，而大量的收件人地址中肯定會出現(xiàn)各種可能的域名，因此，SMTP服務器涉及到要與其他多臺不能事先確定的SMTP服務器進行通信，它需要具有根據(jù)收件人地址的域名查詢出該域的SMTP服務器的功能，即需要具有查詢域名的MX記錄的功能。郵件客戶端軟件被設置為與固定的SMTP服務器通信，它可以直接與指定的SMTP服務器建立網(wǎng)絡連接，因此它不需要具有根據(jù)收件人地址的域名來查詢該域的SMTP服務器的功能。??

（2）對于來自某個郵件客戶端軟件的郵件傳輸請求，SMTP服務器可能需要對發(fā)件人的用戶賬號信息進行驗證，因此，郵件客戶端軟件需要具有向SMTP服務器傳送用戶賬號信息的功能。SMTP服務器能夠直接接受來自其他SMTP服務器的郵件傳輸請求，因此，SMTP服務器在發(fā)送郵件時根本不需要傳送用戶賬號信息的功能。
?
RFC822郵件格式
郵件內(nèi)容的格式在RFC822文檔中定義，它包括兩個主要的組成部分：郵件頭和郵件體。在第2章的SMTP協(xié)議的實驗中，it315_test?@sohu.com郵箱中接收到的it315_test@sina.com發(fā)送來的郵件的最終內(nèi)容如例程3-1所示，其中的行號不屬于郵件內(nèi)容，是作者為了便于講解而加上的。
例程3-1??test.eml
1．Return-Path:?<it315_test@sina.com>
2．Delivered-To:?it315_test@mx72.mail.sohu.com
3．Received:?from?smtp.sina.com.cn?(unknown?[202.108.3.177])?4．?by?sohumx139.sohu.com?(Postfix)?with?SMTP?id?E4F9802C1249
5．?for?<it315_test@sohu.com>;?Thu,?10?Nov?2005?16:39:50?+0800?(CST)
6．Received:?(qmail?49221?invoked?from?network);?10?Nov?2005?08:39:?33?-0000?7．Received:?from?unknown?(HELO?it315?test)?(218.246.5.151)?8．???by?smtp.sina.com.cn?with?SMTP;?10?Nov?2005?08:39:33?-0000?9．?From:?it315_test@sina.com?10．To:?it315_test@sohu.com?11．subject:test
12．Message-Id:?<20051110083950.E4F9802C1249@sohumx139.sohu.com>?13．Date:?Thu,?10?Nov?2005?16:39:50?+0800?(CST)?14．Status:?RO
15．X-UIDL:?1131611863.21509_77.mx72?16．
17．test!!!
例程3-1中的第1～15行是郵件的郵件頭，第17行是郵件的郵件體，郵件頭和郵件體之間以一個空行進行分隔。這封郵件的郵件體內(nèi)容非常少，只有一行“test!!!”文本。郵件頭部分由多個頭字段和字段內(nèi)容組成，各種頭字段分別用于表示郵件的發(fā)件人、收件人、發(fā)件時間和主題等信息。細心的讀者可能已經(jīng)看到，例程3-1中的郵件頭部分比在第2章的SMTP協(xié)議的實驗中實際發(fā)送的郵件頭多出了一些頭字段，這些頭字段是各個SMTP服務器在傳遞郵件的過程加上的。SMTP服務器在傳遞郵件時，會把一些相關(guān)信息增加到郵件的郵件頭中，這種情況有點類似于現(xiàn)實生活中的郵局在處理郵件時，通常都會在信封上加蓋郵戳一樣，表示這封郵件在什么時候經(jīng)過了哪個郵局和由哪個工作人員經(jīng)手處理。SMTP服務器按從下往上的方式添加各個字段，即先添加的字段位于后添加的字段的下面，例如，例程3-1中的郵件是由sina發(fā)送給sohu的，它首先經(jīng)過sina的SMTP服務器，然后經(jīng)過sohu的SMTP服務器，所以，sohu的SMTP服務器添加的頭字段（1～5行）位于sina的SMTP服務器添加的頭字段（6～8行）的上面。另外，POP3服務器也會在郵件頭中增加一些頭字段，例如，例程3-1中的12～15行。
每一個郵件頭以“字段名：字段值”的格式出現(xiàn)，即每一行郵件頭的內(nèi)容依次由字段名、冒號、空格、字段值、回車換行符組成。RFC822文檔中定義了多個標準的郵件頭字段，每一個郵件頭字段表示一種特定的信息。郵件頭中也可以包含自定義的頭字段，這種自定義的頭字段通常是某個組織或機構(gòu)內(nèi)部專用的。下面是對例程3-1中出現(xiàn)的一些主要的郵件頭字段的解釋：
—??Return-Path??該字段代表郵件的回復地址，該字段內(nèi)容由接收郵件的SMTP服務器填寫，接收郵件的SMTP服務器從郵件發(fā)送程序發(fā)出的mail?form命令中獲得該字段內(nèi)容。
—??Received??該字段的基本格式為Received?from?A?by?B?for?C，其中A為發(fā)送方，B為接收方，C為收件人的郵箱地址。該字段的內(nèi)容由接收郵件的SMTP服務器填寫，常常被用來追蹤?quán)]件傳輸?shù)穆肪€和分析郵件的來源，例如，從例程3-1中的各個Received字段中，可以知道這封郵件的傳輸路徑：從IP地址為【218.246.5.151】的機器上發(fā)出→【smtp.sina.com.cn】→【sohumx139.sohu.com】→【it315_test@sohu.com】。例程3-1中的第6行的“Received:?(qmail?49221?invoked?from?network)”是sina的SMTP服務器內(nèi)部調(diào)用的一個郵件發(fā)送模塊添加的，它說明sina的SMTP服務器接收到郵件后再通過這個郵件發(fā)送模塊將郵件轉(zhuǎn)發(fā)出去。顯然，通過分析一封郵件的源內(nèi)容，是可以知道發(fā)件人的IP地址的。?

圖3.6
從圖3.6中可以看出，如果要在郵件中要添加附件，就必須將整封郵件的MIME類型定義為multipart/mixed；如果要在HTML格式的正文中引用內(nèi)嵌資源，那就要定義multipart/related類型的MIME消息；如果普通文本內(nèi)容與HTML文本內(nèi)容共存，那就要定義multipart/alternative類型的MIME消息。
注意：如果整封郵件中只有普通文本內(nèi)容與HTML文本內(nèi)容，那么整封郵件的MIME類型則應定義為multipart/?alternative；如果整封郵件中包含有HTML文本內(nèi)容和內(nèi)嵌資源，但不包含附件，那么整封郵件的MIME類型則應定義為multipart/related。
在Content-type頭字段中除了可以定義消息體的MIME類型外，還可以在MIME類型后面包含相應的屬性，屬性以“屬性名=屬性值”的形式出現(xiàn)，屬性與MIME類型之間采用分號（;）分隔，如下所示：
Content-Type:multipart/mixed;boundary="----=_NextPart_000_0050_01C"?常用的屬性如表3.1所示。?表3.1
主?類?型??????? 屬?性?名??????? 說????明
?text ? ? ? ? ? ??? charset ? ? ? ? 用于說明文本內(nèi)容的字符集編碼
image ? ? ? ??? name?????????? 用于說明圖片文件的文件名

application?? name ? ? ? ? ? 用于說明應用程序的文件名
multipart????? boundary????? 用于定義MIME消息之間的分隔符
?
2:??其他頭字段
除了Content-Type頭字段之外，MIME協(xié)議中還定義Content-?Transfer-Encoding、Content-Disposition、Content-ID、Content-Location、Content-Base等幾個重要的頭字段，這幾個頭字段需要與Content-type頭字段配合使用，它們的作用如下：
—??Content-Transfer-Encoding頭字段
Content-Transfer-Encoding頭字段用于指定MIME消息體中的內(nèi)容所采用的郵件編碼方式，詳細細節(jié)請參看3.4節(jié)的講解。
—??Content-Disposition頭字段
Content-Disposition頭字段用于指定郵件閱讀程序處理數(shù)據(jù)內(nèi)容的方式，有inline和attachment兩種標準方式，inline表示直接處理，而attachment表示當做附件處理。如果將Content-Disposition設置為attachment，在其后還可以指定filename屬性，如下所示：
Content-Disposition:?attachment;?filename="1.bmp"
上面的MIME頭字段表示MIME消息體的內(nèi)容為郵件附件，附件名"1.bmp"。?—??Content-ID頭字段
Content-ID頭字段用于為“multipart/related”組合消息中的內(nèi)嵌資源指定一個唯一標識號，在HTML格式的正文中可以使用這個唯一標識號來引用該內(nèi)嵌資源。例如，假設將一個表示內(nèi)嵌圖片的MIME消息的Content-ID頭字段設置為如下形式：
Content-ID:?it315logo_gif
那么，在HTML正文中就需要使用如下HTML語句來引用該圖片資源：
<img?src="cid:it315logo_gif">?
注意，在引用Content-ID頭字段標識的內(nèi)嵌資源時，要在資源的唯一標識號前面加上“cid:”，以說明要采用唯一標識號對資源進行引用。
—??Content-Location頭字段
Content-Location頭字段用于為內(nèi)嵌資源設置一個URI地址，這個URI地址可以是絕對或相對的。當使用Content-?Location頭字段為一個內(nèi)嵌資源指定一個URI地址后，在HTML格式的正文中也可以使用這個URI來引用該內(nèi)嵌資源。例如，假設將一個表示內(nèi)嵌圖片的MIME消息的Content-?Location頭字段設置為如下形式：

Content-Location:http://www.it315.org/images/it315logo.gif?
那么，在HTML正文中就可以使用如下HTML語句來引用該圖片資源：
<img?src="http://www.it315.org/images/it315logo.gif">??—??Content-Base頭字段
Content-Base頭字段用于為內(nèi)嵌資源設置一個基準路徑，只有這樣，Content-Location頭字段中設置的URI才可以采用相對地址。例如，假設將一個表示內(nèi)嵌圖片的MIME消息的Content-Base和Content-Location頭字段設置為如下形式：
Content-Base:?http://www.it315.org/images/??Content-Location:?it315logo.gif??
那么，內(nèi)嵌資源的完整路徑就是Content-Base頭字段設置的基準路徑與Content-Location頭字段設置的相對路徑相加的結(jié)果，在HTML正文中就可以使用如下HTML語句來引用該圖片資源：
<img?src="http://www.it315.org/images/it315logo.gif">??
MIME郵件的編碼方式
由于每個ASCII碼字符只占用一個字節(jié)（8個bit位），且最高bit位總為0，即ASCII碼字符中的有真正意義的信息只是后面的7個低bit位，而傳統(tǒng)的SMTP協(xié)議又是基于ASCII碼字符設計的，因此，一些基于傳統(tǒng)SMTP協(xié)議設計的SMTP服務器在處理郵件內(nèi)容時只取出每個字節(jié)中的7個低bit位進行處理，而將最高bit位忽略不計。顯然，這樣的SMTP服務器在處理包含有非ASCII碼字符的郵件內(nèi)容時，會出現(xiàn)嚴重的問題，這就限制了郵件中只能出現(xiàn)英文的ASCII碼字符，而不能出現(xiàn)中文字符或二進制數(shù)據(jù)。
為了能夠在郵件內(nèi)容中包含中文、圖像或聲音等非ASCII字符的數(shù)據(jù)，人們想到了采用某種編碼方式將非ASCII字符的數(shù)據(jù)轉(zhuǎn)換成可打印的ASCII字符后再發(fā)送，郵件閱讀程序則按照相應的解碼方式從郵件中還原出原始數(shù)據(jù)即可，比較常用的兩種郵件編碼方式為BASE64和Quoted-printable。后來的擴展SMTP協(xié)議允許直接在郵件中傳遞二進制數(shù)據(jù)，而不用對它們進行郵件編碼，人們將這種沒有進行郵件編碼的二進制數(shù)據(jù)的郵件內(nèi)容稱為8bit編碼，為了與此相區(qū)別，人們將沒有進行郵件編碼的純ASCII碼字符的郵件稱為7bit編碼。MIME消息體的郵件編碼方式通過MIME消息頭中的Content-?Transfer-?Encoding頭字段指定，每種郵件編碼方式的介紹如下：
—??7Bit
指消息體內(nèi)容全部是沒有經(jīng)過編碼的ASCII字符。?—??8Bit
指消息體內(nèi)容是沒有經(jīng)過編碼的原始數(shù)據(jù)，且其中包含有非ASCII字符的數(shù)據(jù)?，F(xiàn)在的郵件服務器基本上都支持8Bit編碼，使用支持8Bit編碼的郵件服務器可以簡化郵件的處理過程。
—??BASE64
Base64是將二進制數(shù)據(jù)轉(zhuǎn)換成可打印的ASCII字符的一種最常見的編碼方式，它的基本原理是將一組連續(xù)的字節(jié)
數(shù)據(jù)按6個bit位進行分組，然后對每組數(shù)據(jù)用一個ASCII字符來表示。6個bit位最多能表示26
＝64個數(shù)值，因此可以使用64個ASCII字符來對應這64個數(shù)值，這64個ASCII字符為：
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"
其中每個字符表示的數(shù)值就是該字符在上面的排列中的索引號，索引號從0開始編號。假設在內(nèi)存中有如下三個連續(xù)的字節(jié)數(shù)據(jù)：
[0110,0001]?[0110,0010]?[0110,0011]
將它們按6個bit位進行分組后的形式如下：
[0110,00]?[01,0110,]?[0010,01]?[10,0011]
分組后得到了四組數(shù)據(jù)，每組數(shù)據(jù)對應的十進制數(shù)值分別為24、22、9、35，它們分別對應Y、W、J、j這四個字符，所以，對[0110,0001]?[0110,0010]?[0110,0011]這三個字節(jié)的數(shù)據(jù)進行BASE64編碼后的結(jié)果是“YWJj”。
BASE64編碼要求把3個8位字節(jié)（即24個bit）的數(shù)據(jù)轉(zhuǎn)化為4個6位字節(jié)（也是24個bit）的數(shù)據(jù)，如果原來的8位字節(jié)數(shù)據(jù)的字節(jié)個數(shù)不能被3整除，其余數(shù)只能是1或2，那么如何對余下的1個或2個8位字節(jié)數(shù)據(jù)進行處理呢？對于這種情況，仍然按6個bit位對剩余的字節(jié)進行分組，在最后不夠6個bit位的內(nèi)容后面添加幾個為0的bit位來湊成6個bit位，例如，如果最后剩下的一個8位字節(jié)的內(nèi)容如下：
[0110,0001]
對它進行分組后的結(jié)果如下：?[0110,00]?[01,0000]

其中用黑斜體標識的0為填充的bit位，所以，最后剩下的這個字節(jié)的BASE64編碼結(jié)果為“YQ”。BASE64編碼還有規(guī)定，如果編碼后的整個結(jié)果文本的字符個數(shù)不是4的整數(shù)倍，那么需要在最后填充“=”字符來湊成4的倍數(shù)，所以，在最后這個字節(jié)編碼的結(jié)果后面還要添加兩個“=”字符，即“YQ==”。顯然，如果最后剩下兩個8位字節(jié)的內(nèi)容，它可以被編碼成三個字符，最后還需要添加一個“=”字符。對一大段數(shù)據(jù)進行BASE64編碼時，可以在編碼結(jié)果中的適當位置加入回車換行，MIME規(guī)范建議BASE64編碼結(jié)果中的每行最多76個字符。
—??Quoted-printable
Quoted-printable也是一種將二進制數(shù)據(jù)轉(zhuǎn)換成可打印的ASCII字符的編碼方式，它對ASCII字符不進行轉(zhuǎn)換，只對非ASCII字符的數(shù)據(jù)進行編碼轉(zhuǎn)化。每個非ASCII字符的字節(jié)數(shù)據(jù)，都被轉(zhuǎn)換成一個"="號后跟這個字節(jié)的十六進制數(shù)據(jù)，例如，“ab中國”的Quoted-printable編碼結(jié)果為“ab=d6=d0=b9=?fa”。顯然，由于"="號在Quoted-printable編碼中具有的特殊意義，所以，原始數(shù)據(jù)中的"="號字符也需要進行編碼轉(zhuǎn)換，用“=3d”表示。
對一大段數(shù)據(jù)進行Quoted-printable編碼時，可以在編碼結(jié)果中的適當位置加入回車換行，在回車換行前需要額外再加入一個“=”字符，以表示后面的換行是因編碼而造成的軟回車，而非原始數(shù)據(jù)中原有的回車換行。例如，對于下面一段Quoted-printable編碼后的數(shù)據(jù)：
=D5=E2=CA=C7=CD=A8=D0=C5=B5=C4=B3=CC=D0=?=F2,?=C7=EB=D6=B8=BD=CC!
在第一行末尾的“=”字符和換行，都是由于編碼后生成的。?MIME實例分析
了解MIME協(xié)議的基本組織結(jié)構(gòu)后，下面用Outlook?Express撰寫出一封顯示效果如圖3.4所示的電子郵件，然后分析該郵件的源文件，以便讀者更加深入地了解MIME協(xié)議。
?
啟動Outlook?Express，單擊工具欄中的“創(chuàng)建郵件”按鈕，在打開的“新郵件”對話框中輸入收件人地址、
主題和郵件正文，然后選中郵件正文，單擊編輯窗口的工具欄上的“》”按鈕，在彈出的菜單欄中單擊表示超鏈接的圖標，如圖3.7所示。
?
圖3.7
?
在打開的“超級鏈接”對話框中輸入如圖3.8所示的內(nèi)容，然后單擊“OK”按紐。
?
圖3.8
?再次單擊編輯窗口的工具欄上的“》”按鈕，在打開的如圖3.7所示的菜單欄中單擊表示圖片的圖標，在打開
的“圖片”對話框中單擊“瀏覽”按鈕，然后通過打開的對話框選擇一個圖片文件，結(jié)果如圖3.9所示。
?
單擊圖3.9中的“OK”按鈕，結(jié)果如圖3.10所示。
?
單擊圖3.10所示窗口中的“插入”à“文件附件”菜單項，在打開的“插入附件”對話框窗口中選擇需要發(fā)送的附件
單擊“附件”按鈕，插入所選中的附件。
?
單擊圖3.10所示窗口中的“文件”à“保存”菜單項，在Outlook?Express主窗口的“草稿”目錄中就可以看到這封郵件
?
將這封郵件從“草稿”目錄中移動到“發(fā)件箱”目錄中，接著按照3.1節(jié)中講解的查看郵件源文件步驟，打開
剛才撰寫的這封郵件的源文件?；蛘咴凇安莞濉蹦夸浿羞x中這封郵件，將它另存為一個eml文件，再用任意一種文本編輯程序打開這個eml文件，這樣也可以查看到剛才撰寫的這封郵件的源文件。為了便于讀者看清郵件內(nèi)容的組織結(jié)構(gòu)關(guān)系，筆者專門為此畫了一個描述郵件中的各個MIME消息分隔符的層次關(guān)系的示意圖，如圖3.13所示。
從圖3.13中可以看出，在MIME組合消息的消息體中的每個消息單元都要以一個分割符開始，在組合消息的消息體結(jié)束時還需要用一個結(jié)束分割符。MIME消息中的分隔符的層次關(guān)系與一篇文章中的標題之間的層次關(guān)系非常相似，只是在每個組合消息結(jié)束時還要增加一個結(jié)束“標題”。為了便于講解，筆者對剛才撰寫的郵件源文件內(nèi)容進行了適當修改，并添加了相應的注釋，如下所示：
?
圖3.13
1：From:?"it315"?<it315_test@sohu.com>?
2：To:?<it315_test@sohu.com>

3：Subject:?=?gb2312?B?TUlNRdCt0unLtcP308q8/g==?=

4：Date:?Thu,?1?Dec?2005?20:46:53?+0800

5：MIME-Version:?1.0

6：Content-Type:?multipart/mixed;//定義郵件體類型為mixed

7：?boundary="----=_NextPart_000_0050_01C"//定義整個郵件內(nèi)容的分隔符

8：X-Priority:?3

9：X-MSMail-Priority:?Normal
10：X-Mailer:?Microsoft?Outlook?Express?6.00.2900.2670

11：X-MimeOLE:?Produced?By?Microsoft?MimeOLE?V6.00.2900.2670

12：

13：This?is?a?multi-part?message?in?MIME?format.//郵件注釋

14：

//整個郵件內(nèi)容的第一部分（即郵件正文）的開始標記

15：------=_NextPart_000_0050_01C?

16：Content-Type:?multipart/related;

17：?type="multipart/alternative";

18：?boundary="----=_NextPart_001_0051_01C"//定義郵件正文內(nèi)部的分隔符

19：

????//郵件正文內(nèi)部的第一部分的開始標記

20：------=_NextPart_001_0051_01C

?21：Content-Type:?multipart/alternative;

????????//定義郵件正文內(nèi)部的第一部分的內(nèi)部分隔符

22：?boundary="----=_NextPart_002_0052_01C"

23：

????????//郵件正文內(nèi)部的第一部分的第一部分的開始標記

24：------=_NextPart_002_0052_01C?

25：Content-Type:?text/plain;

26：?charset="gb2312"

27：Content-Transfer-Encoding:?base64

28：

29：u7bTrbTzvNK3w87KztLDx7XEzfjVvg0KDQog

????????????????????//經(jīng)BASE64編碼后的文本格式的郵件正文

30：

????????//郵件正文內(nèi)部的第一部分的第二部分的開始標記

31：------=_NextPart_002_0052_01C?

32：Content-Type:?text/html;

33：?charset="gb2312"

34：Content-Transfer-Encoding:?base64

35：

36：PCFET0NUWVBFIEhUTUwgUFVC......//經(jīng)BASE64編碼后的HTML格式的郵件正文?

37：

????????//郵件正文內(nèi)部的第一部分的的結(jié)束標記

38：------=_NextPart_002_0052_01C--?

39：

????//郵件正文內(nèi)部的第二部分（HTML中的內(nèi)嵌資源）的開始標記

40：------=_NextPart_001_0051_01C?

41：Content-Type:?image/gif;

42：?name="logo.gif"

43：Content-Transfer-Encoding:?base64

44：Content-ID:?<004f01c5f675$4e210300$b501a8c0@zxx>

45：

46：R0lGODlh/ABGAOYAADdhmaekZjxsq0N4vHik

47：xK27z9CtCJWpxCZEa3aczejr7......

????????????????????//?HTML中內(nèi)嵌的經(jīng)BASE64編碼后的圖片數(shù)據(jù)

48：

????//郵件正文的結(jié)束標記

49：------=_NextPart_001_0051_01C—

50：

//整個郵件內(nèi)容的第二部分（第一個附件）的開始標記

51：------=_NextPart_000_0050_01C?

52：Content-Type:?application/x-msdownload;

53：?name="daemon.exe"

54：Content-Transfer-Encoding:?base64

55：Content-Disposition:?attachment;//聲明內(nèi)容類型為附件

56：?filename="daemon.exe"

57：

58：TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAA

?59：AAAA0AAAAA4fug4AtAnNAAAAAA......//?第一個郵件附件內(nèi)容

60：

//整個郵件內(nèi)容的第三部分（第二個附件）的開始標記

61：------=_NextPart_000_0050_01C?

62：Content-Type:?audio/wav;

63：?name="sndrec.wav"

64：Content-Transfer-Encoding:?base64

65：Content-Disposition:?attachment;//聲明內(nèi)容類型為附件

66：?filename="sndrec.wav"

67：

68：UklGRjIAAABXQVZFZm10IBIAAAABAAEAIlYAACJWAAABAAgAKABmYWN0

69：AA==AAAAAAAAAAAAAAAAAACCC......//第二個郵件附件內(nèi)容

70：

//整個郵件內(nèi)容的結(jié)束標記

71：------=_NextPart_000_0050_01C5F6B8.5C492500--

源文件中第1～11行為郵件的郵件頭，第15～71行為郵件體。郵件體中的15～49行為郵件正文，第51-59行為郵件的第一個附件，第61～71行為第二個附件。讀者只要對照圖3.13來閱讀，就很容易看出這個郵件源文件內(nèi)容的組織結(jié)構(gòu)。關(guān)于上述的郵件源文件內(nèi)容，還需要做出如下三點補充解釋：
（1）每個MIME組合消息的Content-type頭字段中的boundary屬性用于定義其中嵌套的各個MIME消息之間的分隔符，如源文件中的第7行、第18行和第22行等。在各個MIME組合消息內(nèi)部的起始分隔符是在該MIME組合消息的Content-type頭字段中的boundary屬性值前面增加了兩個減號（-）字符而形成的，如源文件中的第15行、第20行和第24行等；而每個MIME組合消息的結(jié)束分隔符則是在其起始分隔符的后面又添加兩個減號（-）字符而形成的，如源文件中的第38行、第49行和第71行。
（2）在每個MIME組合消息的消息體之前（即第一個開始分隔符之前），可以有一些附加的文本行，這些文本行相當于MIME消息的注釋，在解碼時將被忽略，如源文件的13行。
（3）源文件中的第44行使用Content-ID頭字段為內(nèi)嵌的圖片資源指定了一個唯一標識號，在HTML格式的正文中需要使用這個唯一標識號來引用相應的內(nèi)嵌資源，其引用語句為<img?src=?"cid:
004f01c5f675$4e210300$b501a8c0@zxx">，但是由于整個HTML正文部分采用了Base64編碼，所以在源文件的HTML正文部分無法看到原始的引用語句。
多學兩招??郵件傳播病毒的原理

MIME協(xié)議其實就是一種郵件內(nèi)容的組織協(xié)議，支持MIME協(xié)議的郵件閱讀程序?qū)⒏鶕?jù)MIME消息頭中定義的MIME類型，調(diào)用相應的解析程序來處理消息體中的數(shù)據(jù)。例如MIME消息頭中定義為郵件附件時，郵件閱讀程序會提示用戶保存消息體中的數(shù)據(jù)，如果定義為圖像文件時，郵件閱讀程序則把消息體中的數(shù)據(jù)作為一個圖像文件自動打開。
由于郵件數(shù)據(jù)通常是經(jīng)過BASE64編碼后的ASCII碼數(shù)據(jù)，郵件閱讀程序只能通過分析數(shù)據(jù)的MIME消息頭來獲知數(shù)據(jù)類型，無法通過分析數(shù)據(jù)本身來獲知數(shù)據(jù)的類型，因此，一些病毒制造者就可以把病毒程序進行BASE64編碼后，再附加在郵件的MIME消息體中，然后在MIME消息頭中將其MIME類型定義為圖片或聲音等類型，而文件名的擴展名卻為.exe。這樣，當郵件閱讀程序解碼帶有病毒程序的MIME消息體后，將執(zhí)行解碼后得到的病毒程序。前些年曾經(jīng)在全球范圍內(nèi)流行的Nimda病毒，就是通過這種方式進行傳播的，其示意源代碼如下：
MIME-Version:?1.0
Content-Type:?multipart/related;//聲明所包含內(nèi)容為內(nèi)嵌資源??type="multipart/alternative";
?boundary="====_ABC1234567890DEF_===="?--====_ABC1234567890DEF_====?Content-Type:?multipart/alternative;
?boundary="====_ABC0987654321DEF_===="?--====_ABC0987654321DEF_====?Content-Type:?text/html;???charset="iso-8859-1"
Content-Transfer-Encoding:?7bit
<HTML><HEAD></HEAD><BODY?bgColor=#ffffff>?<iframe?src=cid:EA4DMGBP9p?height=0?width=0>?</iframe></BODY></HTML>
--====_ABC0987654321DEF_====--?--====_ABC1234567890DEF_====
Content-Type:?audio/x-wav;?name="readme.exe"?????????????????????//把exe文件定義成一個wav文件
Content-Transfer-Encoding:?base64?Content-ID:?<EA4DMGBP9p>
TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAA……//經(jīng)BASE64編碼后的病毒源代碼
--====_ABC1234567890DEF_====
這封郵件傳播病毒的運行原理非常簡單，如上面的源文件中的黑體字部分及相應注釋所示，它就是將一個可執(zhí)行文件（readme.exe）作為一個audio/x-wav類型的聲音文件嵌入到HTML頁面中。由于最初的Outlook?Express程序沒有檢查MIME消息的Content-Type頭字段定義的MIME類型與其中的name屬性指定的文件擴展名是否匹配，于是導致用戶打開郵件時將執(zhí)行解碼后的readme.exe程序，從而感染上了病毒。這個病毒程序又利用Outlook?Express中的地址簿向別人發(fā)送帶毒的郵件，這樣一傳十，十傳百，Nimda蠕蟲就大行其道了。

總結(jié)

以上是生活随笔為你收集整理的MIME协议及源邮件格式分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。