MIME协议分析

第1 章.    MIME概述

MIME,全称为“Multipurpose Internet Mail Extensions”,比较确切的中文 名称为“多用途互 联网邮件扩展”。 它是当前广泛应用的一种电子邮件技术规范，基本内容定义于RFC 2045-2049（注意RFC1521和RFC1522是它的过时版本）。

MIME试图在不改变SMTP协议和RFC822（邮件格式标准）的基础上，使得邮件可以传送任意二进制文件。为此，它在这些协议之上，采取了一些 措施，这就是我们下面所要重点讲述的内容。

第2 章.    MIME详解

2.1. 改进措施

一封邮件包括信封、邮件头和邮件体等三个 部分。信封显然可以不含有二进制信息，而其它两部分则可能包含任意二进制序列，因此需要加以改进。MIME正是抓住了这两个地方来对 他们加以改进。

1)       新增了一些邮件头信息，用来协商MIME的一些参数。

2)       定义了许多邮件内容的格式，对多媒体电子邮件的表示方法进行了标准 化。

3)       定义了传送编码，从而可以传送任意二进制文件。

在这里，我还是要不厌其烦地强调指出，所 有的改进措施都是建立在不改变原来的SMTP协议和RFC822的基础上的。事实上，我们可以把这些改进措施，看成是在用SMTP等发送邮件前所采取的 预处理。

2.2. 一封简单邮件的源码

为了对MIME邮 件有个直观的了解，先给出一封简单邮件的源码。源码中，行号和行号后的空格是为了分析方便而另外加的，“... ... ... ...” 表示此处省略了大段编码。

1 From: "bhw98"

  2 Reply-To: bhw98@sina.com

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 Content-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=A12003-04-07

 31

 32 --=====002_Dragon307572345230_=====

 33 Content-Type: text/html; charset="GB2312"

 34 Content-Transfer-Encoding: quoted-printable

 35

36

37

38 39 http-equiv=3DContent-Type>

40

    ... ... ... ...

79

 80

 81 --=====002_Dragon307572345230_=====--

 82

我们可以在用户代理中查看到这样的源码。 例如可以利用用户代理来查看一封邮件的原始编码。例如在Foxmail中，选定邮件后，单击右键，选择“原始信息”项即可。至于源码的具体意思则正是后续内容所要讲的。

2.3. 邮件头

2.3.1. 邮件头的域

邮件头包含了发件人、收件人、主题、时 间、MIME版本、邮件内容的类型等重要信息。每条信息称为一个域，由域名后加“:”和信息内容构成，可以是一行，较长的也 可以占用多行。域的首行必须“顶头”写，即左边不能有空白字符（空格和制表符）；续行则必须以空白字符打头，且第一个空白字符不是信息本身固有的，解码时 要过滤掉。如例2的7-8行分别属于一个域。

表 1中给出了邮件头中常见的域，域的含义，和域值的添加者。

非标准的、自定义域名都以X-开 头，例如X-Mailer, X-MSMail-Priority等，通常在接收和发送邮件的是同一程序时才能理解它们的意义。除了后面两个域外，其他的域的意思很 明了，所以下面只对后两个域做解释。

2.3.2. Content-Type域

Content-Type域，即内容类型域，它用来说明传输的内容的类型。Cotent-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\\Content Type”内列举了除multipart之外大部分已知的Content-Type。

各种各种类型一般都可以带参数。至于参数 的形式，RFC里有很多补充规定，有的允许带几个参数，较为常见的如表 2所示

2.3.3. Content-Transfer-Encoding域

Content-Transfer-Encoding域即传送编码域，它用来说明后面传输的内容的编码方式。

Content-Transfer-Encoding共有Base, Quoted-printable, 7bit, 8bit, Binary等几种。其中7bit是缺省的编码方式。电子邮件源码最初设计为全部是可打印的ASCII码的形式。非ASCII码的文本或数据要编码成要求的格 式，如上面的三个例子。Base, Quoted-Printable是在非英语国家使用最广使的编码方式。Binary方式只具有象征意义，而没有任何实用价值。关于Base编码和Quoted-Printable编码请参 考RFC文档或另 外一篇文章《SMTP协议分析》。

近年来，国内多数邮件服务器已经支持8bit方 式，因此只在国内传输的邮件，特别是在邮件头中，可直接使用8bit编码，对汉字不做处理。如果邮件要出国，还是老老实实地按Base或Quoted-printable编码才行

2.4. 邮件体

邮件体的类型由邮件头的“Content-Type”域指出。常见的简单类型有text/plain(纯文本)和text/html(超文本)。 

源码中出现的multipart类型，是MIME邮件的精髓。邮件体被分为多个段，每个段又包含段头和段体两部分，这两部分之间也以空行分隔。常见的multipart类型有三种：multipart/mixed, multipart/related和multipart/alternative。从它们的名称，不难推知这些类型各自的含义和用处。它们之间的层次关系可归纳为图 1所示

+------------------------- multipart/mixed ----------------------+                                                                     | +----------------- multipart/related -------------+           |                                                   | |                                                |           |                                                                | |                                                |           |

| | +----multipart/alternative ---+ +----------+ | +------+ | | | |                            | |内嵌资源 | | |附件 | | |  | | +-----------+ +----------+ |  +----------+ | +------+ |

| | | |纯文本正文| |超文本正文| |               |           |

| | | +-----------+ +----------+ | +----------+ | +------+ |

| | |                            | |内嵌资源 | | |附件 | | | | +-----------------------------+ +----------+ | +------+ |

| |                                                |           |           | +-------------------------------------------------+           |                                                                 +-----------------------------------------------------------------+

图 1邮件体的层次关系图

可以看出，如果在邮件中要添加附件，必须 定义multipart/mixed段；如果存在内嵌资源，至少要定义multipart/related段；如果纯文本与超文本共存，至少要定义multipart/alternative段。什么是“至少”？举个例子说，如果只有纯文本与超文本正文，那么在邮件头中将类型扩大化，定义 为multipart/related，甚至multipart/mixed，都是允许的。 

multipart诸类型的共同特征是，在段头指定“boundary”参数字符串，段体内的每个子段以此串定界。所有的子段都以“--”+boundary行开始，父段则以“--”+boundary+“--”行结束。段与段之间也以空行分隔。在 邮件体是multipart类型的情况下，邮件体的开始部分(第一个“--”+boundary行之前)可以有一些附加的文本行，相当于注释，解码时应忽略。段间也可以有一些附加的文本行，不会显示出来， 如果有兴趣，不妨验证一下。

结合boundary定界和multipart层次关系图，我们分析一下源码中的邮件体层次与段嵌套关系。 在源码中，10-12行是附加文本行，13-82行是multipart/alternative型的段，包含两个子段：13-30行是纯文本正文，32-79行是超文本正文。 

需要补充说明地是，构成邮件体的各段有自 己的属性，这些属性由段头的域来说明。表 3给出了段头中常见的域。

各域的含义与邮件头中同名的域的含义一 样，只是前者的作用域为段，而后者的作用域为整个邮件体

第3 章.    常见的疑问

3.1. 如何得到MIME邮件的源码

在一些些功能比较完善的邮件客户端软件， 如微软的Outlook Express，国产的Foxmail等，都提供了查看和保存邮件源码(原始信息)的功能。在Foxmail中，选择邮件，单击右键，选择“原始信息”菜单项可查看到邮件的源码。

第4 章.    分析方案

因为MIME是 一种电子邮件规范，所以被广泛用在其他协议中。如SMTP和POP3协议中所谓的邮件就大部分遵循MIME邮件规范。所以虽然功能需求表中未对MIME作出要求，但当我们想要从SMTP或POP3通信等中提取有效信息时，我们不得不了解MIME协议（因为提取到的邮件信息是符合MIME规范的）。

当我们得到了SMTP或POP3通信中的MIME信息后，只需对其进行简单的MIME解码就可得到发送的 原始信息。

第5 章.    参考资料

[1]     http://dev.csdn.net/article/18/18448.shtm [Online]

[2]     RFC文档：RFC821对应SMTP协议，RFC822对应邮件标准，RFC1425对应ESMTP，RFC1939对应POP3协议，RFC2045-RFC2049对应MIME协议的基本内容。

[3]     http://www.faqs.org/rfcs/，上面有全面的英文RFC文档

[4]     http://www.cnpaf.net/，上面有不少有用的协议分析文档，也有中文RFC文档，但质量不是特别高

[5]     Stevens, W.R., TCP/IP Illustrated, Vol1. Addision-Wesley,机械工业出版社，2002