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

 

9-3 MIME 郵件標準

內容：

之前我們介紹所謂安全郵件，即是將安全措施嵌入於分段郵件上，而此分段機制就是 MIME（Multipurpose 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 II（7 bits）編碼文字，MIME 增加其他訊息編碼方式。

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

9-3-3 MIME 標頭列

MIME 所定義的 5 個標頭列，說明如下：

  • MIME-Version：目前 MIME 版本為 1（MIME-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：表示主體內是包含某一種已格式化的訊息，MIME（RFC 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 參數表示存取型態（如 ftp、mail-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/Gif：GIF 格式。

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

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

  • Video：表示主體內承載為視訊檔案。目前 MIME 僅定義 Video/mpeg（MPEG 格式）型態。

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

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

        • Application/PostScript：Adobe 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)

=

 

翻轉工作室：粘添壽

 

資訊與網路安全技術

 

 

翻轉電子書系列：