資訊與網路安全技術第 九章 安全性電子郵件  上一頁      下一頁

 

9-3 MIME 郵件標準

內容:

之前我們介紹所謂安全郵件,即是將安全措施嵌入於分段郵件上,而此分段機制就是 MIMEMultipurpose Internet Mail Extension的主要特性。早期制定 MIME 目的是欲將多媒體功能植入於死板的文字郵件裡(RFC 822),它的做法是分別將聲音、影像、視訊植入於各個區段郵件裡,每一區段由一個區段標頭描述所承載的訊息型態(聲音或影像),再由另一個實體(Body)承載該訊息。欲瞭解 MIME 郵件格式還是必須先由 RFC 822 郵件開始,以下分別介紹之。

9-3-1 RFC 822 封裝格式

1982 年制定 RFC 822 標準時,網路上信件內容非常單純,大多僅傳送文字而已。因此,RFC 822 所制定的文件格式非常簡單,只包含『標頭』(Header『主體』(Body兩部份,兩者之間是利用一列空白列來區隔。訊息內容是由 ASCII 文字所構成,第一行空白列之前的文字列都被當成標頭列,當郵件被轉送時,就是利用這些標頭列所標示的內容被轉送,標頭列也是採用 ASCII 文字表示。

一封信件的標頭可能包含多個『標頭列』(Header Column,每一標頭列代表文件的控制訊息。至於一個標頭列則是由一個關鍵字、一個冒號,以及所攜帶參數所構成,較常用的關鍵字為 From(發信者地址)To(收信者地址)Subject(信件主旨)Cc(副本收信者)以及 Data(發信日期時間) 等等。另外,信件主體(Boby可利用 SACII 表示任何文字,並以 <LF> <CR> 表示主體的結束。以下為簡單 RFC 822 的信件範例:

From: 志明 <bob@cc.cma.edu.tw>

To:春嬌 <alice@pchome.com.tw>

Subject: See you tomorrow

Date: Fri. 26 Dec 2003 10:12:37 – 0400

 

    Please come to meet me at tomorrow.

<LF>&<CR>

9-3-2 MIME 延伸功能

直到 1993 年,僅文字傳輸的郵件系統,已不能滿足環境需求,『多目的網際郵件擴充』(MIME)郵件格式因而誕生。吾人所期望的郵件豈是文字模式所能滿足,沒有聲音與影像根本不符時代潮流。基本上,MIME RFC 822 版本的延伸其延伸功能如下:

  • 規範 5 個新的標頭列:新的標頭列都可以被包含在 RFC 822 標頭上,每一個標頭列描述與主體(Body)有關的訊息。

  • 規範 7 個內文型態:原來 RFC 822 只能攜帶文字模式,MIME 為了增加攜帶其他訊息,定義了 7 種與攜帶訊息有關的型態,如聲音、影像、或其他訊息等。

  • 規範郵件編碼方法:原來 RFC 822 只能以 ASC II7 bits)編碼文字,MIME 增加其他訊息編碼方式。

接下來,我們來介紹 MIME 所增加的功能。

9-3-3 MIME 標頭列

MIME 所定義的 5 個標頭列,說明如下:

  • MIME-Version:目前 MIME 版本為 1MIME-Version:1)。

  • Content-Type此標頭列表示主體內訊息的格式,其包含 7 種主要型態及 15 種次型態(Subtype,容後說明)。

  • Content-Transfer-Encoding指定郵件編碼方式,MIME 定義 7 種訊息編碼方式,其中 Base64 編碼與安全機制較有關係。

  • Content-ID內文的唯一識別碼。

  • Content-Description此標頭列是說明訊息內文的格式時使用。

基本上,後面兩個標頭列(Content-ID Content-Description)甚少使用,只要的重點在 Content-Type 標頭內如何增加其他訊息的傳輸。

9-3-4 MIME 內文型態

MIME 郵件如何達到『多用途』(Multipurpose,這完全視『內文型態』(Content Type的變化。其實它的道理非常簡單,發信者只要利用 Content-Type 表示目前訊息是何種格式(如 Jepg 圖片);收信者由 Content-Type 知道所接收訊息是何種格式,再利用該格式來觀閱訊息(如 Jpeg 顯示器)即可。也就是說,Content-Type 是用來通知雙方採用何種格式來存放訊息的意思。表 12-2 MIME 所制定的 Content-Type,每一種 Content-Type 又包含若干個次型態(Subtype),說明如下:

9-2 MIME 內文型態

型態

次型態

功能說明

Text

Plain

不具格式的文字,如 ASC II

Enrich

較有彈性的文字格式。

Multipart

Mixed

區段之間為獨立的,但需依照次序。

Parallel

區段之間為獨立的,不需依照次序。

Alternative

各區段皆表示同一訊息,但格式不同。

Digest

Mixed 相同,但採用 rfc822 格式。

Message

rfc822

訊息經由 rfc822 格式包裝。

Partial

訊息是經過切割包裝而成。

External-body

訊息內容再另一個指定位置。

Image

Jpeg

訊息為 JPEG 影像格式。

Gif

訊息為 GIF 影像格式。

Video

Mpeg

訊息為 MPEG 視訊格式。

Audio

Basic

訊息為 Basic 聲音格式。

Application

PostScript

訊息為 PostScript 格式。

Octet-stream

訊息為 8 位元二進位格式。

  • Text如果訊息主體內是文字的話,則利用 Text 來表示文字型態,它有兩個次型態:

        • Text/plaint:表示沒有指定特殊文字模式。

        • Text/Enriched:表示較具有彈性的文字型態,另由 RFC 1341 所制定。

  • Multipart此內文型態表示訊息是由多個獨立部份(或稱區段)所組成,然而這些獨立區段之間的關係,又可區分為:

        • Multipart/Mixed:表示各個區段之間是彼此獨立的,但收信者還是必須依照發信者所排列的次序接收。範例如下:(取自 RFC 1046

l  信者所排列的次序接收。範例如下:(取自 RFC 1046

From: Nathaniel Borenstein 
To: Ned Freed 
Date: Sun, 21 Mar 1993 23:56:48 -0800 (PST)
Subject: Sample message
MIME-Version: 1.0
Content-type: multipart/mixed; boundary="simple boundary"
 
     This is the preamble.  It is to be ignored, though it
     is a handy place for composition agents to include an
     explanatory note to non-MIME conformant readers.
 
--simple boundary
 
     This is implicitly typed plain US-ASCII text.
     It does NOT end with a linebreak.
--simple boundary
Content-type: text/plain; charset=us-ascii
 
     This is explicitly typed plain US-ASCII text.
     It DOES end with a linebreak.
 
--simple boundary--
 
     This is the epilogue.  It is also to be ignored.
        • Multipart/Parallel:各個區段之間也是彼此獨立的,但收信者可以不按照區段次序收信。

        • Multipart/Alternative:所有區段都表達同一種訊息,但各個區段表示方法的版本不同。範例如下:(取自 RFC 1046

From: Nathaniel Borenstein 
To: Ned Freed 
Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST)
Subject: Formatted text mail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=boundary42
 
--boundary42
Content-Type: text/plain; charset=us-ascii
 
       ... plain text version of message goes here ...
--boundary42
Content-Type: text/enriched
 
       ... RFC 1896 text/enriched version of same message
           goes here ...
--boundary42
Content-Type: application/x-whatever
 
       ... fanciest version of same message goes here ...

--boundary42--

        • Multipart/Digest:大致上與 Mixed 型態相同,但訊息型態內定為 Message/rfc822 版本。

  • Message表示主體內是包含某一種已格式化的訊息,MIMERFC 2046)制定有下列次型態:

        • Message/rfc822:表示主體內訊息已經過 RFC 822 規範包裝而成。

        • Message/partial:表示主體內訊息是經由大訊息分割而成,亦即訊息太長而無法由一個信件承載的話,就必須利用此次型態來攜帶分割後的訊息區塊,因此,必須再增加三個參數:id(同一訊息的區段都相同)、sequence number(每一區段的順序號碼)與 total(區段的資料總數)。

Content-Type: Message/Partial; number=2; total=3;
                   id="oc=jpbe0M2Yt4s@thumper.bellcore.com"
        • Message/external-body:表示主體內並沒有承載所欲傳輸的訊息,而訊息是存放在另一位置上。因此,必須有 access-type 參數表示存取型態(如 ftpmail-server)與 name 參數表示檔案名稱。目前許多廣告信件便用此型態傳送,範例如下:

Content-type: message/external-body;
           access-type=local-file;
           name="/u/nsb/Me.jpeg"
Content-type: image/jpeg
Content-ID: <id42@guppylake.bellcore.com>
Content-Transfer-Encoding: binary
 
     THIS IS NOT REALLY THE BODY!
        • 其他訊息型態:針對其他無法閱讀的二進位訊息,MIME 另外以 application 型態表示,譬如 Application/Octet-stream

  • Image表示主體內承載影像檔案。基本上,MIME 定義有:

        • Image/Jpeg:影像是 JPEG 格式。

        • Image/GifGIF 格式。

至於其他影像檔由 RFC 2048 規定。

  • Audio表示主體承載為聲音檔案。目前 MIME 僅定義 Audio/Basic,其為單聲道、8 位元 ISDN mu-law 編碼,採樣頻率為 8 KHz

  • Video表示主體內承載為視訊檔案。目前 MIME 僅定義 Video/mpegMPEG 格式)型態。

  • Application應用型態。簡單的說,上述標準型態無法表示的訊息,都是利用 Application 來表示;目前MIME預留作為未來發展使用,為滿足各種不同的應用,MIME 定義下列兩次型態:

        • Application/Octet-stream:有關由 8 位元組所構成的二進位資料都可使用此型態。

        • Application/PostScriptAdobe Postscript 格式。

上述中,與安全郵件較有關係的是 Multipart Application 型態,S/E-Mail 就是將它的安全機制嵌入於這兩個內文型態之中。

9-3-5 MIME 內容轉換編碼

『內容轉換編碼』(Content Transfer Encoding MIME 另一重要的規範,其功能是指定何種編碼技巧將訊息內容轉換成可傳輸的數碼,MIME 的規範有下列編碼技巧:

  • 7 bit將訊息內容轉換成 7 位元的 ASCII 碼。

  • 8 bit將訊息內容轉換成 8 位元的 SACII 碼;如果原來為 7 位元的字元,則最高位元為 1

  • binary以二進位碼傳輸,一般使用於執行檔或影像檔傳輸。

  • quoted-printable如果訊息內容大部份是 ASC II 文字的話,可將其轉換成可列印的文字編碼格式傳送。

  • base64將訊息以每 6 位元為單位,轉換成 8 個位元的可列印 ASCII 字元編碼;此型態為加密信件主要的轉換格式(容後介紹)。

  • x-token具有名稱的非標準編碼法。

指定內容傳輸編碼的控制與法如下:

Content-Type: text/plain; charset=ISO-8859-1

Content-transfer-encoding: base64

上述編碼技巧中,與 S/E-mail 較有關係的是 Base64(即是 radix-64 編碼法)。訊息經過加密或簽署處理之後,會產生一連串的亂碼,這些亂碼並不適合儲存或傳輸,若希望將這些亂碼轉換成可閱讀的字串,需仰賴 Base64 編碼來轉換。Base64 編碼是將一連串的亂碼,以每 6 個位元為單位,連續將它轉換成可閱讀的字元(ASC II 碼),其轉換編碼如表 12-3 所示。

9-3 Base64 編碼轉換表

6 位元

輸入

編碼輸出

6 位元

輸入

編碼輸出

6 位元

輸入

編碼輸出

6 位元

輸入

編碼輸出

0

A

16

Q

32

g

48

w

1

B

17

R

33

h

49

x

2

C

18

S

34

i

50

y

3

D

19

T

35

j

51

z

4

E

20

U

36

k

52

0

5

F

21

V

37

l

53

1

6

G

22

W

38

m

54

2

7

H

23

X

39

n

55

3

8

I

24

Y

40

o

56

4

9

J

25

Z

41

p

57

5

10

L

26

a

42

q

58

6

11

K

27

b

43

r

59

7

12

M

28

c

44

s

60

8

13

N

29

d

45

t

61

9

14

O

30

e

46

u

62

+

15

P

31

f

47

v

63

-

 

 

 

 

 

 

(pad)

=

 

翻轉工作室:粘添壽

 

 

資訊與網路安全技術

 

 

翻轉電子書系列: