mime郵件

MIME郵件就是符合MIME規範的電子郵件，或者說根據MIME規範編碼而成的電子郵件。

基本介紹

• 中文名：mime郵件
• 外文名：MultipurposeInternetMailExtensions
• 關鍵字：電子郵件,MIME,multipart
• 出處：Q什麼是MIME？什麼是MIME郵
• 定義於：RFC2045-2049
• 簡寫：AMIME

出處

Q什麼是MIME？什麼是MIME郵件？AMIME,全稱為“MultipurposeInternetMailExtensions”,比較確切的中文名稱為“多用途網際網路郵件擴展”。它是當前廣泛套用的一種電子郵件技術規範，基本內容定義於RFC2045-2049。
在MIME出台之前，使用RFC822隻能傳送基本的ASCII碼文本信息，郵件內容如果要包括二進制檔案、聲音和動畫等，實現起來非常困難。MIME提供了一種可以在郵件中附加多種不同編碼檔案的方法，彌補了原來的信息格式的不足。實際上不僅僅是郵件編碼，現在MIME經成為HTTP協定標準的一個部分。
下面舉幾個MIME郵件的例子，讓我們先對MIME編碼的格式有個直觀的印象。例1是最簡單的，只帶純文本正文，基本上就是RFC822格式；例2複雜一些，包含純文本和超文本正文；例3是最複雜的，包含純文本正文、超文本正文、內嵌資源和檔案附屬檔案。其中，行號和行號後的空格是為了分析方便而另外加的，“............”表示此處省略了大段編碼。

例1

1Date:Thu,18Apr200209:32:45+0800
2From:
3To:
4Subject:Test
5Mime-Version:1.0
6Content-Type:text/plain;charset="iso-8859-1"
7
8Thisisasimplemail.
9
例2
1From:"bhw98"
2Reply-To:[email protected]
3To:
4Subject:Re:help
5X-Mailer:Foxmail4.2[cn]
6Mime-Version:1.0
7Content-Type:multipart/alternative;
8boundary="=====002_Dragon307572345230_====="
9
10
11Thisisamulti-partmessageinMIMEformat.
12
13--=====002_Dragon307572345230_=====
14Content-Type:text/plain;charset="GB2312"
15Content-Transfer-Encoding:quoted-printable
16
17bluesky7810=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=A12003-04-07
31
32--=====002_Dragon307572345230_=====
33Content-Type:text/html;charset="GB2312"
34Content-Transfer-Encoding:quoted-printable
35
36
37
38<METAcontent=3D"text/html;charset=3Dgb2312"=
39http-equiv=3DContent-Type>
40
............
79
80
81--=====002_Dragon307572345230_=====--
82
例3
1Return-Path:
2Delivered-To:[email protected]
3Received:(Qmail75513invokedbyalias);20May200202:19:53-0000
4Received:fromunknown(helobluesky)(61.155.118.135)
5by202.106.187.143withSMTP;20May200202:19:53-0000
6Message-ID:
7From:"=?gb2312?B?wLbAtrXEzOwNCg==?="
8To:"bhw98"
9Cc:
10Subject:=?gb2312?B?ztK1xLbgtK6/2rPM0PI=?=
11Date:Sat,20May200210:03:36+0800
12MIME-Version:1.0
13Content-Type:multipart/mixed;
14boundary="----=_NextPart_000_007A_01C3115F.80DFC5E0"
15X-Priority:3
16X-MSMail-Priority:Normal
17X-Mailer:MicrosoftOutlookExpress5.00.2919.6700
18X-MimeOLE:ProducedByMicrosoftMimeOLEV5.00.2919.6700
19
20Thisisamulti-partmessageinMIMEformat.
21
22------=_NextPart_000_007A_01C3115F.80DFC5E0
23Content-Type:multipart/related;type="multipart/alternative";
24boundary="----=_NextPart_001_007B_01C3115F.80DFC5E0"
25
26
27------=_NextPart_001_007B_01C3115F.80DFC5E0
28Content-Type:multipart/alternative;
29boundary="----=_NextPart_002_007C_01C3115F.80DFC5E0"
30
31------=_NextPart_002_007C_01C3115F.80DFC5E0
32Content-Type:text/plain;charset="gb2312"
33Content-Transfer-Encoding:quoted-printable
34
35bhw98,=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_01C3115F.80DFC5E0
41Content-Type:text/html;charset="gb2312"
42Content-Transfer-Encoding:quoted-printable
43
44
45
46html;charset=3Dgb2312"http-equiv=3DContent-Type>
47
52
53<BODYbackground=3Dcid:007901c3111c$72b978a0$0100007f@bluesky=
54BGCOLOR=3D#ffffff>
55
56bhw98,=C4=E3=BA=C3!
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
64Content-Type:image/jpeg;name="=?gb2312?B?x+fAyrGzvrAuSlBH?="
65Content-Transfer-Encoding:base64
66Content-ID:
67
68/9j/4AAQSkZJRgABAgEASABIAAD/7QVoUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAASAAAAAEA
69AQBIAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgAB
70AAAAAAAAAAI4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEA
............
169RxVw98Vawq12xQ44q0cKtHFDWKGsKt4EtiuKt4q//9k=
170
171------=_NextPart_001_007B_01C3115F.80DFC5E0--
172
173------=_NextPart_000_007A_01C3115F.80DFC5E0
174Content-Type:application/msword;name="readme.doc"
175Content-Transfer-Encoding:base64
176Content-Disposition:attachment;filename="readme.doc"
177
1780M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAJgAAAAAAAAAA
179EAAAKAAAAAEAAAD+////AAAAACUAAAD/////////////////////////////////////////////
180////////////////////////////////////////////////////////////////////////////
............
1688AAAAAAAAAAAAAAAAAAA=
1689
1690------=_NextPart_000_007A_01C3115F.80DFC5E0
1691Content-Type:application/x-zip-compressed;
1692name="=?gb2312?B?tuC0rr/azajQxbXE1LTC6y56aXA=?="
1693Content-Transfer-Encoding:base64
1694Content-Disposition:attachment;
1695filename="=?gb2312?B?tuC0rr/azajQxbXE1LTC6y56aXA=?="
1696
1697UEsDBBQAAAAIAFKAoi7qOMOvLw0AAABWAAAUAAAAtuC0rr/azajQxbXE1LTC6y5kb2PtXHtwVNUZ
1698/+4+kk3IQoAkBkRYQkSgbrKb7IYNEMwmm6ckG0jCI0boZneTbJJ9sNlAEsdOtFqd8Z846tQ6PhB1
1699hrZTJoK0Vhgf1aGt4rMy6D8tdugfTjuOpcBIR9j+vvsIy4YkRNTRen87v/ud53cee+6557vn7L73
............
3125zajQxbXE1LTC6y5kb2NQSwUGAAAAAAEAAQBCAAAAYQ0AAA==
3126
3127------=_NextPart_000_007A_01C3115F.80DFC5E0--
3128
Q在開始研究MIME郵件的時候，如何得到這樣的源碼？
A一些功能比較完善的郵件客戶端軟體，如微軟的OutlookExpress，國產的Foxmail等，都提供了查看和保存郵件源碼(原始信息)的功能。在Foxmail中，選擇郵件列表右鍵選單的“原始信息”進行查看，主選單的“檔案-導出”進行保存。在OutlookExpress中，對應的操作分別是“屬性”和“另外儲存為”。所保存的.eml檔案，可以調用這些程式打開。
Q請介紹一下MIME郵件的組成？
A總體來說，MIME訊息由訊息頭和訊息體兩大部分組成。現在我們關注的是MIME郵件，因此在以下的討論中姑且稱“訊息”為“郵件”。在上面的例子中，例1的1-6行，例2的1—8行，例3的1-18行，是郵件頭；例1的8—9行，例2的10—82行，例3的20—3128行，是郵件體。郵件頭與郵件體之間以空行進行分隔，如例1的第7行，例2的第9行，例3的第19行。郵件頭中不允許出現空行。有一些郵件不能被郵件客戶端軟體識別，顯示的是原始碼，就是因為首行是空行。
郵件頭包含了發件人、收件人、主題、時間、MIME版本、郵件內容的類型等重要信息。每條信息稱為一個域，由域名後加“:”和信息內容構成，可以是一行，較長的也可以占用多行。域的首行必須“頂頭”寫，即左邊不能有空白字元（空格和制表符）；續行則必須以空白字元打頭，且第一個空白字元不是信息本身固有的，解碼時要過濾掉。如例2的7-8行，例3的4-5行，13-14行，分別屬於一個域。
郵件體包含郵件的內容，它的類型由郵件頭的“Content-Type”域指出。常見的簡單類型有text/plain(純文本)和text/html(超文本)。
例2和例3中出現的multipart類型，是MIME郵件的精髓。郵件體被分為多個段，每個段又包含段頭和段體兩部分，這兩部分之間也以空行分隔。常見的multipart類型有三種：multipart/mixed,multipart/related和multipart/alternative。從它們的名稱，不難推知這些類型各自的含義和用處。它們之間的層次關係可歸納為下圖所示：
+-------------------------multipart/mixed----------------------------+
||
|+-----------------multipart/related------------------+|
||||
||+-----multipart/alternative------++----------+|+------+|
|||||內嵌資源|||附屬檔案||
|||+------------++------------+|+----------+|+------+|
||||純文本正文||超文本正文||||
|||+------------++------------+|+----------+|+------+|
|||||內嵌資源|||附屬檔案||
||+----------------------------------++----------+|+------+|
||||
|+------------------------------------------------------+|
||
+----------------------------------------------------------------------+
可以看出，如果在郵件中要添加附屬檔案，必須定義multipart/mixed段；如果存在內嵌資源，至少要定義multipart/related段；如果純文本與超文本共存，至少要定義multipart/alternative段。什麼是“至少”？舉個例子說，如果只有純文本與超文本正文，那么在郵件頭中將類型擴大化，定義為multipart/related，甚至multipart/mixed，都是允許的。
multipart諸類型的共同特徵是，在段頭指定“boundary”參數字元串，段體內的每個子段以此串定界。所有的子段都以“--”+boundary行開始，父段則以“--”+boundary+“--”行結束。段與段之間也以空行分隔。在郵件體是multipart類型的情況下，郵件體的開始部分(第一個“--”+boundary行之前)可以有一些附加的文本行，相當於注釋，解碼時應忽略。段間也可以有一些附加的文本行，不會顯示出來，如果有興趣，不妨驗證一下。
結合boundary定界和multipart層次關係圖，我們分析一下例2和例3的郵件體層次與段嵌套關係。
在例2中，10-12行是附加文本行，13-82行是multipart/alternative型的段，包含兩個子段：13-30行是純文本正文，32-79行是超文本正文。
在例3中，20-21行是附加文本行，22-3127行是multipart/mixed型的段，包含3個子段：22-171行是multipart/related段，173-1688行與1690-3125行是兩個附屬檔案。multipart/related段又包含兩個子段：27-61行是multipart/alternative段，63-169行是一個內嵌資源(圖片)。multipart/alternative段又包含兩個子段：31-48行是純文本正文，40-59行是超文本正文。
例1隻有純文本正文，實際上屬於multipart層次關係圖中的一個特殊情況。如果非要避簡就繁，寫成下面的形式，也是完全符合MIME精神的。
Date:Thu,18Apr200209:32:45+0800
From:
To:
Subject:Test
Mime-Version:1.0
Content-Type:multipart/alternative;boundary="{[(^_^)]}"
--{[(^_^)]}
Content-Type:text/plain;charset="iso-8859-1"
Content-Transfer-Encoding:7bit
Thisisasimplemail.
--{[(^_^)]}--
Q在郵件頭和段頭中，有哪一些常見的域？
A在郵件頭中，有很多從RFC822沿用的域名，MIME也增加了一些。常見的標準域名和含義如下
域名 含義 添加者
Received 傳輸路徑 各級郵件伺服器
Return-Path 回復地址 目標郵件伺服器
Delivered-To 傳送地址 目標郵件伺服器
Reply-To 回復地址 郵件的創建者
From 發件人地址 郵件的創建者
To 收件人地址 郵件的創建者
Cc 抄送地址 郵件的創建者
Bcc 暗送地址 郵件的創建者
Date 日期和時間 郵件的創建者
Subject 主題 郵件的創建者
Message-ID 訊息ID 郵件的創建者
MIME-Version MIME版本 郵件的創建者
Content-Type 內容的類型 郵件的創建者
Content-Transfer-Encoding 內容的傳輸編碼方式 郵件的創建者
非標準的、自定義域名都以X-開頭，例如X-Mailer,X-MSMail-Priority等，通常在接收和傳送郵件的是同一程式時才能理解它們的意義。
在段頭中，大致有如下一些域
域名 含義
Content-Type 段體的類型
Content-Transfer-Encoding 段體的傳輸編碼方式
Content-Disposition 段體的安排方式
Content-ID 段體的ID
Content-Location 段體的位置(路徑)
Content-Base 段體的基位置
有的域除了值之外，還帶有參數。值與參數、參數與參數之間以“;”分隔。參數名與參數值之間以“=”分隔。如例3的28-29行，Content-Type域的值為“multipart/alternative”，此外有一個參數boundary，值為"----=_NextPart_002_007C_01C3115F.80DFC5E0"。又如例3的第176行，Content-Disposition域的值為“attachment”，此外有一個參數filename，值為“readme.doc”。
QContent-Type以及它們的參數有哪些形式？
AContent-Type都是“主類型/子類型”的形式。主類型有text,image,audio,video,application,multipart,message等，分別表示文本、圖片、音頻、視頻、套用、分段、訊息等。每個主類型都可能有多個子類型，如text類型就包含plain,html,xml,css等子類型。以X-開頭的主類型和子類型，同樣表示自定義的類型，未向IANA正式註冊，但大多已經約定成俗了。如application/x-zip-compressed是ZIP檔案類型。在Windows中，註冊表的“HKEY_CLASSES_ROOT\MIME\Database\ContentType”內列舉了除multipart之外大部分已知的Content-Type。
關於參數的形式，RFC里有很多補充規定，有的允許帶幾個參數，較為常見的有
主類型 參數名 含義
text charset 字元集
image name 名稱
application name 名稱
multipart boundary 邊界
其中字元集也能在Windows註冊表的“HKEY_CLASSES_ROOT\MIME\Database\Charset”內見到。
QContent-Transfer-Encoding有哪些？有什麼特點？
AContent-Transfer-Encoding共有Base64,Quoted-printable,7bit,8bit,Binary等幾種。其中7bit是預設的編碼方式。電子郵件源碼最初設計為全部是可列印的ASCII碼的形式。非ASCII碼的文本或數據要編碼成要求的格式，如上面的三個例子。Base64,Quoted-Printable是在非英語國家使用最廣使的編碼方式。Binary方式只具有象徵意義，而沒有任何實用價值。
Base64將輸入的字元串或一段數據編碼成只含有{'A'-'Z','a'-'z','0'-'9','+','/'}這64個字元的串，'='用於填充。其編碼的方法是，將輸入數據流每次取6bit，用此6bit的值(0-63)作為索引去查表，輸出相應字元。這樣，每3個位元組將編碼為4個字元(3×8→4×6)；不滿4個字元的以'='填充。有的場合，以“=?charset?B?xxxxxxxx?=”表示xxxxxxxx是Base64編碼，且原文的字元集是charset。如例3第7行"=?gb2312?B?wLbAtrXEzOwNCg==?="是由簡體中文“藍藍的天”編碼而成的。在段體內則直接編碼，適當時機換行，MIME建議每行最多76個字元。如例3的1697-3125行，是一個ZIP檔案的Base64編碼。
Quoted-printable根據輸入的字元串或位元組範圍進行編碼，若是不需編碼的字元，直接輸出；若需要編碼，則先輸出'='，後面跟著以2個字元表示的十六進制位元組值。有的場合，以“=?charset?Q?xxxxxxxx?=”表示xxxxxxxx是Quoted-printable編碼，且原文的字元集是charset。在段體內則直接編碼，適當時機換行，換行前額外輸出一個'='。如例3的44-59行，是HTML文本的Quoted-printable編碼。其中第45行“=C7=E7=C0=CA”原文是“晴朗”，因為“晴”的GB2312碼是C7E7，“朗”的GB2312碼是C0CA。第48、53、57行末尾只有孤零零的'='，表示這是由編碼造成的軟回車，而非原文固有的。
近年來，國內多數郵件伺服器已經支持8bit方式，因此只在國內傳輸的郵件，特別是在郵件頭中，可直接使用8bit編碼，對漢字不做處理。如果郵件要出國，還是老老實實地按Base64或Quoted-printable編碼才行。
Q什麼是內嵌資源？它有哪些形式？
A內嵌資源也是MIME的一個發光點，它能使郵件內容變得生動活潑、豐富多彩。可在郵件的multipart/related框架內定義一些與正文關聯的圖片、動畫、聲音甚至CSS樣式和腳本的段。通常在HTML正文內，使用超級連結與內嵌資源相聯繫。如在例3中，HTML正文53-54行，解碼後為
它指出用一個Content-ID為007901c3111c$72b978a0$0100007f@bluesky的圖片作為背景(cid:xxxxxxxx也是一種超級連結)。而64-169行恰好就是這樣一個內嵌資源。
除了用Content-ID進行聯繫外，還有另外一種常用形式：用普通超級連線和Content-Location。例如：
在HTML正文中，
............
/www.dangdang.com/images/all/anti_joyo_dm_book.gif">
............
/www.dangdang.com/dd2001/getimage_small.asp?id=486341">
............
對應的內嵌資源為
Content-Type:image/gif;name="anti_joyo_dm_book.gif"
Content-Transfer-Encoding:base64
Content-Location:http://www.dangdang.com/images/all/anti_joyo_dm_book.gif
............
Content-Type:application/octet-stream;name="getimage_small.asp?id=486341"
Content-Transfer-Encoding:base64
Content-Location:http://www.dangdang.com/dd2001/getimage_small.asp?id=486341
............
另外，
Content-Location:http://www.dangdang.com/images/all/anti_joyo_dm_book.gif
與
Content-Location:anti_joyo_dm_book.gif
Content-Base:http://www.dangdang.com/images/all/
是等效的。
Q郵件病毒如何利用附屬檔案和內嵌資源傳播？
A有的郵件附屬檔案可能帶有病毒，容易理解。附屬檔案畢竟是檔案，也好預防，不輕易打開就是了。但內嵌資源是在瀏覽郵件內容時就要訪問的，若其中藏有病毒或惡意代碼，你在不知不覺中就中招了。如前兩年曾經在全球範圍內流行的Nimda病毒，功能性源碼如下：
MIME-Version:1.0
Content-Type:multipart/related;
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
--====_ABC0987654321DEF_====--
--====_ABC1234567890DEF_====
Content-Type:audio/x-wav;name="readme.exe"
Content-Transfer-Encoding:base64
Content-ID:
TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v
ZGUuDQ0KJAAAAAAAAAA11CFvcbVPPHG1TzxxtU88E6pcPHW1TzyZqkU8dbVPPJmqSzxytU88cbVO
........................
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
--====_ABC1234567890DEF_====
它將一個執行檔作為資源嵌入了框架型頁面，卻聲明這段可執行代碼是波形聲音類型。由於當時微軟的IE(版本5.0及以下)存在重大安全漏洞，沒有檢查Content-Type與name的擴展名是否匹配，於是就被輕易騙過了，致使點選或打開郵件時自動運行了這個“readme.exe”，機器就感染上病毒。帶毒的機器利用地址簿向別人傳送帶毒的郵件，一傳十，十傳百，Nimda蠕蟲大行其道。
縱觀歷史，病毒剛出來時是厲害，但沒有任何一種能夠持續肆虐下去。Nimda如此，SARS亦當如此。曰：“多難興邦，眾志成城”，又曰：“非典終將倒下，城市精神永存”，相信我們定能很快戰勝“非典”!
病毒庫升級是跟在新病毒屁股後進行的，不要過分依賴防毒軟體。一個良好的習慣是關閉郵件預覽功能，或者設定預覽純文本部分，先查看郵件源碼，確信排除病毒嫌疑後再打開。對陌生人發來的帶超文本正文的郵件，尤其要當心。永遠不要在郵件客戶端軟體內直接打開附屬檔案。
Q一些垃圾郵件採取隱藏發件人的方式，如何追查它們來自哪裡？
A從上面的郵件頭域名表中可以看出，郵件的創建者可以掌握大部分的域的內容，但Received等域由各級伺服器自動添加，發件人是鞭長莫及。垃圾郵件一般採用了群發軟體傳送，郵件頭的From域(發件人地址)可以任意偽造，甚至寫成收件人地址(收到了自己並沒有發過的垃圾郵件，氣憤吧？)。查看Received域(傳輸路徑)鏈可以找到真正的出處。每個伺服器添加的Received語句都在郵件首，故最下面一個Received就包含了發件人所用的SMTP或HTTP伺服器，及最初的網關外部IP位址。
Receive語句的基本格式是：fromAbyB。A為傳送方，B為接收方。例如：
Received:(qmail45304invokedfromnetwork);4May200317:05:47-0000
Received:fromunknown(HELObjapp9.163.net)(202.108.255.197)
by202.106.182.244withSMTP;4May200317:05:47-0000
Received:fromlocalhost(localhost[127.0.0.1])
bybjapp9.163.net(Postfix)withSMTPidE1C761D84C631
for;Mon,5May200301:07:26+0800(CST)
Received:[email protected](unknown[211.99.162.194])
bybjapp9.163.net(Coremail)withSMTPidOgEAAM1ItT7MNaLC.1
for;Mon,05May200301:07:26+0800(CST)
從上面的例子中不難看出，該郵件的傳輸路徑是：211.99.162.194→bjapp9.163.net(Coremail202.108.255.197?)→bjapp9.163.net(Postfix,202.108.255.197?)→202.106.182.244。恰好出現了發件人信箱[email protected]，但多數情況不一定能列出來。
此例的localhost[127.0.0.1]，意味著bjapp9.163.net上安裝了郵件服務代理性質的軟體