SMTP协议分析

1、SMTP协议分析第1章. SMTP概述1.1. SMTP在邮件通信中的位置SMTP，即简单邮件传送协议，所对应RFC文档为RFC821。同http等多数应用层协议一样，它工作在C/S模式下，用来实现因特网上的邮件传送。SMTP在整个电子邮件通信中所处的位置如图 1所示。图 1电子邮件的通信过程可以看出，SMTP是用来将客户机上的邮件传送到服务器上。这里的客户机是指某次连接中的发送方，服务器是指相应的接收方。在讲解发送邮件的整个通信过程前，先解释一下面几个术语。1.2. 几个术语1.2.1. 邮件邮件是一种消息的格式，由信封、首部和正文组成。信封上最重要的是收信人的地址。邮件服务器用这个地址将邮

2、件发送到收信人所在的邮件服务器上。首部是由用户代理或邮件服务器添加的一些信息。包括Received、Message-ID、From、Data、Reply-To、X-Phone、X-Mailer、To和Subject等字段。正文是是发送用户发给接收用户报文的内容。RFC 822 规定正文为NVT ASCII文字行。更为详细的说明，请参考RFC821和RFC822等协议。1.2.2. 用户代理用户代理UA（User Agent）是用户与电子邮件系统的交互接口，一般来说它就是我们PC机上的一个程序。Windows上常见的用户代理是Foxmail和Outlook Express。用户代理提供一个好的用

3、户界面，它提取用户在其界面填写的各项信息，生成一封符合SMTP等邮件标准的邮件，然后采用SMTP协议将邮件发送到发送端邮件服务器。1.2.3. 邮件服务器邮件服务器是电子邮件系统的核心，它用来发送和接收邮件。邮件服务器不同于普通PC的是它几乎是全天工作的，所以它可以在任何时候为用户提供服务，后面将提到这正是为什么需要邮件服务器的一个重要原因。很多ISP都提供免费的邮件服务器，如126提供邮件服务器。邮件服务器向其它邮件服务器转发邮件也是采用SMTP协议。1.3. 邮件的收发过程一般情况下，一封邮件的发送和接收过程如下。1) 发信人在用户代理里编辑邮件，包括填写发信人邮箱、收信人邮箱和邮件标题等

4、等。2) 用户代理提取发信人编辑的信息，生成一封符合邮件格式标准（RFC822）的邮件。3) 用户代理用SMTP将邮件发送到发送端邮件服务器（即发信人邮箱所对应的邮件服务器）。4) 发送端邮件服务器用SMTP将邮件发送到接收端邮件服务器（即收信人邮箱所对应的邮件服务器）。5) 收信人调用用户代理。用户代理用POP3协议从接收端邮件服务器取回邮件。6) 用户代理解析收到的邮件，以适当的形式呈现在收信人面前。第2章. SMTP详解2.1. 通信过程一个具体的SMTP通信（如发送端邮件服务器与接收端服务器的通信）的过程如下。1) 发送端邮件服务器（以下简称客户端）与接收端邮件服务器（以下简称服务器）

5、的25号端口建立TCP连接。2) 客户端向服务器发送各种命令，来请求各种服务（如认证、指定发送人和接收人）。3) 服务器解析用户的命令，做出相应动作并返回给客户端一个响应。4) 2)和3)交替进行，直到所有邮件都发送完或两者的连接被意外中断。从这个过程看出，命令和响应是SMTP协议的重点，下面将予以重点讲述。2.2. 命令和响应2.2.1. 格式SMTP的命令不多（14个），它的一般形式是：COMMAND Parameter 。其中COMMAND是ASCII形式的命令名，Parameter是相应的命令参数，是回车换行符(0DH, 0AH)。SMTP的响应也不复杂，它的一般形式是：XXX Rea

6、dable Illustration。XXX是三位十进制数；Readable Illustration是可读的解释说明，用来表明命令是否成功等。XXX具有如下的规律：以2开头的表示成功，以4和5开头的表示失败，以3开头的表示未完成（进行中）。2.2.2. 一个例子命令和响应的格式是语法，各命令和响应的意思则是语义，各命令和各响应在时间上的关系则是同步。下面将通过一个简单的SMTP通信过程来说明协议的这三个要素。C：telnet 25 /*以telnet方式连接126邮件服务器*/S：220 Anti-spam GT for Coremail System (126com071018)/* 22

7、0为响应数字，其后的为欢迎信息，会应服务器不同而不同*/C：HELO /* HELO 后用来填写返回域名（具体含义请参阅RFC821），但该命令并不检查后面的参数 */：250 OKC: MAIL FROM: bripengandre /* 发送者邮箱 */S：250 ./* “”代表省略了一些可读信息 */C：RCPT TO: bripengandre/* 接收者邮箱 */S：250 ./* “”代表省略了一些可读信息 */C：DATA /* 请求发送数据 */S：354 Enter mail, end with . on a line by itselfC：Enjoy Protocol S

8、tudingC：.S：250 Message sentC：QUIT /* 退出连接 */S：221 Bye分析上面的过程可参考注释进行，这里要补充如下几点。1) “C：”开头的行(不包括C：)是客户端的输入，而以“S：”开头的行(不包括S：)则是服务器的输出。2) 上述的命令并不一定会一次性成功，服务器会返回错误响应，客户端应该按照协议规定的时序，来输入后续的命令（或重复执行失败的命令，或重置会话，或退出会话等等）。2.2.3. 常用命令SMTP命令不区分大小写，但参数区分大小写，有关这方面的详细说明请参考RFC821。常用的命令如下。HELO 。向服务器标识用户身份发送者能欺骗，说谎，但一般

9、情况下服务器都能检测到。MAIL FROM: 。为发送者地址，此命令用来初始化邮件传输，即用来对所有的状态和缓冲区进行初始化。RCPT TO： 。用来标志邮件接收者的地址，常用在MAIL FROM后，可以有多个RCPT TO。DATA 。将之后的数据作为数据发送，以.标志数据的结尾。REST 。重置会话，当前传输被取消。NOOP 。要求服务器返回OK应答，一般用作测试。QUIT 。结束会话。VRFY 。验证指定的邮箱是否存在，由于安全方面的原因，服务器大多禁止此命令。EXPN 。验证给定的邮箱列表是否存在，由于安全方面的原因，服务器大多禁止此命令。HELP 。查询服务器支持什么命令。2.2.4

10、. 常用响应常用的响应如下所示，数字后的说明是从英文译过来的。更详细的说明请参考RFC821。501参数格式错误502命令不可实现503错误的命令序列504命令参数不可实现211系统状态或系统帮助响应214帮助信息220domain服务就绪221domain服务关闭421domain服务未就绪，关闭传输信道250要求的邮件操作完成251用户非本地，将转发向forward-path450要求的邮件操作未完成，邮箱不可用550要求的邮件操作未完成，邮箱不可用451放弃要求的操作；处理过程中出错551用户非本地，请尝试forward-path452系统存储不足，要求的操作未执行552过量的存储分配，

11、要求的操作未执行553邮箱名不可用，要求的操作未执行354开始邮件输入，以.结束554操作失败第3章. SMTP的扩充3.1. SMTP的缺点从2.2.2的例子可以看出，SMTP至少还有如下缺点。1) 命令过于简单，没提供认证等功能。2) 只传送7位的ASCII码，不能传送二进制文件。针对缺点1)，标准化组织制定了扩充的SMTP（即ESMTP），对应的RFC文档为RFC1425。针对缺点2)，标准化组织在兼容SMTP的前提下，提出了传送非7位ASCII码的方法，对应的RFC文档有两个：邮件首部的扩充对应于RFC1522，邮件正文的扩充对应与RFC1521（即MIME）。3.2. ESMTPES

12、MTP最显著的地方是添加了用户认证功能。如果用户想使用ESMTP提供的新命令，则在初次与服务器交互时，发送的命令应该是EHLO而不是HELO。先来看一个例子。C：telnet 25 /*以telnet方式连接126邮件服务器*/S：220 Anti-spam GT for Coremail System (126com071018)/* 220为响应数字，其后的为欢迎信息，会应服务器不同而不同*/C：EHLO /* 除了HELO所具有的功能外，EHLO主要用来查询服务器支持的扩充功能 */S：250-mailS：250-AUTH LOGIN PLAINS：250-AUTH=LOGIN PLAI

13、NS：250 8BITMIME /* 最后一个响应数字应答码之后跟的是一个空格，而不是- */C：AUTH LOGIN /* 请求认证 */S：334 dxNlcm5hbWU6 /* 服务器的响应经过base64编码了的“Username” */C：Y29zdGFAYW1heGl0Lm5ldA= /* 发送经过BASE64编码了的用户名 */S：334 UGFzc3dvcmQ6 /* 经过BASE64编码了的Password: */C：MTk4MjIxNA= /* 客户端发送的经过BASE64编码了的密码 */S：235 auth successfully/* 认证成功 */C: MAIL F

14、ROM: bripengandre /* 发送者邮箱 */S：250 ./* “”代表省略了一些可读信息 */C：RCPT TO: bripengandre/* 接收者邮箱 */S：250 ./* “”代表省略了一些可读信息 */C：DATA /* 请求发送数据 */S：354 Enter mail, end with . on a line by itselfC：Enjoy Protocol StudingC：.S：250 Message sentC：QUIT /* 退出连接 */S：221 Bye对于这个例子有如下几点说明。1) 只是一个示意性的过程，再输入用户名、密码时需采用base64

15、编码，这需要专门的计算，所以在telnet终端上模拟比较麻烦。2) 认证过程有很多种，有基于明文的认证，也有基于MD5加密的认证，这里给出的只是一个示意性的过程。3) EHLO对于具体服务器，响应会不同，关键字“8BITMIME”用来说明服务器是否支持正文中传送位ASCII码，而以“X”开头的关键字都是指服务器自定义的扩充（还没纳入RFC标准）更详细的说明，请参看RFC1425。3.3. 邮件首部的扩充首部通过两种编码方式来支持传送非7位ASCII码。它首先通过一个如下格式的编码字来表明所用的编码方式。=?charset?encoding?encoded-text?textcharset是字符

16、集规范。有效值是两个字符串us-ascii和iso-8859-x，其中x 是一个单个数字，例如iso-8859-1中的数字为“ 1”。encoding是一个单个字符用来指定编码方法，支持两个值。Q代表quoted-printable（可打印）编码。任何要发送的字符若其第8比特置1则被作为3个字符发送：第1个是字符是“=”，后面的两个字符对应于字符的十六进制表示。例如对于二进制码11111111，其对应的十六进制表示为“FF”，所以对应的编码位“=FF”。为了能够传输“=”，“=”的编码方式与第比特置的字符相同，因为其二进制代码为00111101，所以对应的编码为“=3D”。可以看出这种编码方式

17、的开销达200%，所以只适合传送只含有少量非7位ASCII码的文本。B代表base64编码。它的编码方法是先将二进制代码划分为一个24bit长的单元，然后将这24 bit单元划分为4个6 bit组。每个组按图 2所示的方法转换成ASCII码。图 2base64映射表可以看出这种映射方法是这样的：0-25依次映射成A-Z，26-51依次映射成a-z,52-61依次映射成数字0-9，然后62映射成+，63映射成/。对于二进制代码01001001 00110001 01111001，先将其划分成4个6 bit组，即010010 0100011 000101 111001。接着按图 2所示的映射表，可

18、得到base64编码为：STF5。可以看出，这种编码方式的开销是25%，相对quoted-printable编码来说，它更适合用来传送含大量非7位ASCII码的二进制文件。3.4. 正文的扩充正文的扩充主要是使正文不仅可以传输NVT ASCII字符，而且可以传输任意字符，对应的文档为RFC1511（即MIME）。MIME全称为“Multiple Internet Mail Extensions”, 比较确切的中文名称为“多用途互联网邮件扩展”。它通过新增一些邮件首部字段、邮件内容格式和传送编码，使得其成为一种应用很广泛的可以传输多媒体的电子邮件规范。更详细的说明请参看另一篇文章MIME协议分析

19、和RFC1511。第4章. 常见的疑问4.1. 为什么需要SMTP服务器一般的PC资源不够，处理能力不够，不可能全天候地连接在因特网上来收发邮件。所以使用SMTP服务器，可以让多个用户共用服务器，有效地降低了成本。4.2. SMTP和邮件格式的关系如前所述，SMTP是客户机向服务器发送邮件时所使用的协议，其核心是2.2中所述的命令和响应，至于它命令和响应中所带的参数采用什么格式，则是依赖于其他标准的。例如DATA后所带的参数，则应遵循邮件格式标准RFC822SMTP和邮件格式的关系可用这么一个例子来说明。甲与乙书信往来，甲通过邮局向乙发信，邮局间转交邮件可看成使用了SMTP协议，至于书信的格式

20、则会因为地区习惯等的不同而不同（中国人的书信格式和美国人的书信格式不同），这个书信格式则可看成是邮件格式标准。应当认识到不能孤立地看待协议，各个协议之间往往存在着耦合关系，但为了分析方便，我们在具体叙述某个协议时，只能抓住主要矛盾主要阐述单个协议。4.3. 浏览器发送邮件用的什么协议浏览器如IE、Maxthon可通过登陆用户邮箱，来收发邮件，这是怎样实现的？例如bripengandre可通过登陆来收发邮件。这个过程是这样的：bripengandre在提供的邮件页面上填写的相应信息（如发信人邮箱、收信人邮箱等），通过http协议被提交给126服务器；126服务器根据这些信息组装一封符合邮件规范的

21、邮件（就像用户代理一样）；然后通过SMTP协议将这封邮件发送到接收端邮件服务器。可以看出，浏览器发送邮件只是用户代理的功能直接放到邮件服务器上去做了，至于邮件服务器间发送邮件还是采用的SMTP协议。我们看问题，如果有必要还是要适当地透过现象看本质。4.4. 如何用实验验证SMTP的通信过程1) 可以通过ethereal等协议分析软件来抓包分析协议。2) 可以利用socket编程实现SMTP的通信过程。3) 可以利用用户代理来查看一封邮件的原始编码。例如在Foxmail中，可以选择邮件列表右键菜单的“原始信息”进行查看。第5章. 分析方案IDProtocolCaptured contentsus

22、er namepasswordsenderreceiversubjectcontentsattachments4smtp表 1 协议分析要求表 1给出了协议分析要求。容易看出，获取各个字段是比较容易的。我们可以抓取客户端与服务器端的交互信息，然后根据各命令字或响应字来提取出我们想要的字段。例如，要获取user name，我们只需检测到服务器端要求客户端发送用户名这个时候，然后提取这之后客户端的发送信息即可。需要说明的是，虽然客户端与服务端交互的信息可能经过了编码或加密，但我们仍能够通过解码或解密来获得所需要的信息。第6章. 参考资料1 RFC文档：RFC821对应SMTP协议，RFC822对应

23、邮件标准，RFC1425对应ESMTP，RFC1522对应邮件首部的扩充，RFC1521对应邮件正文的扩充，RFC1939对应POP3协议。2 /rfcs/，上面有全面的英文RFC文档3 4 Stevens, W.R., TCP/IP Illustrated, Vol1. Addision-Wesley, 机械工业出版社，2002MIME邮件面面观(转载) 分类： Network Security 2008-03-11 20:08 714人阅读 评论(0) 收藏 举报 转载自Q 什么是MIME？什么是MIME邮件？ A MIME, 全称为“Multipurp

24、ose Internet Mail Extensions”, 比较确切的中文名称为“多用途互联网邮件扩展”。它是当前广泛应用的一种电子邮件技术规范，基本内容定义于RFC 2045-2049。 自然，MIME邮件就是符合MIME规范的电子邮件，或者说根据MIME规范编码而成的电子邮件。 在MIME出台之前，使用RFC 822只能发送基本的ASCII码文本信息，邮件内容如果要包括二进制文件、声音和动画等，实现起来非常困难。MIME提供了一种可以在邮件中附加多种不同编码文件的方法，弥补了原来的信息格式的不足。实际上不仅仅是邮件编码，现在MIME经成为HTTP协议标准的一个部分。 下面举几个MIME邮

25、件的例子，让我们先对MIME编码的格式有个直观的印象。例1是最简单的，只带纯文本正文，基本上就是RFC 822格式；例2复杂一些，包含纯文本和超文本正文；例3是最复杂的，包含纯文本正文、超文本正文、内嵌资源和文件附件。其中，行号和行号后的空格是为了分析方便而另外加的，“. . . .”表示此处省略了大段编码。 例1 1 Date: Thu, 18 Apr 2002 09:32:45 +0800 2 From: 3 To: 4 Subject: Test 5 Mime-Version: 1.0 6 Content-Type: text/plain; charset=iso-8859-1 7 8

26、This is a simple mail. 9例2 1 From: bhw98 2 Reply-To: bhw98 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 Cont

27、ent-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

28、=A12003-04-07 31 32 -=002_Dragon307572345230_= 33 Content-Type: text/html; charset=GB2312 34 Content-Transfer-Encoding: quoted-printable 35 36 37 38 40 . . . . 79 80 81 -=002_Dragon307572345230_=- 82例3 1 Return-Path: 2 Delivered-To: bhw98 3 Received: (qmail 75513 invoked by alias); 20 May 2002 02:19

29、:53 -0000 4 Received: from unknown (HELO bluesky) (35) 5 by 43 with SMTP; 20 May 2002 02:19:53 -0000 6 Message-ID: 7 From: =?gb2312?B?wLbAtrXEzOwNCg=?= 8 To: bhw98 9 Cc: 10 Subject: =?gb2312?B?ztK1xLbgtK6/2rPM0PI=?= 11 Date: Sat, 20 May 2002 10:03:36 +0800 12 MIME-Version: 1

30、.0 13 Content-Type: multipart/mixed; 14 boundary=-=_NextPart_000_007A_01C3115F.80DFC5E0 15 X-Priority: 3 16 X-MSMail-Priority: Normal 17 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 18 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 19 20 This is a multi-part message in MIME format. 2

31、1 22 -=_NextPart_000_007A_01C3115F.80DFC5E0 23 Content-Type: multipart/related; type=multipart/alternative; 24 boundary=-=_NextPart_001_007B_01C3115F.80DFC5E0 25 26 27 -=_NextPart_001_007B_01C3115F.80DFC5E0 28 Content-Type: multipart/alternative; 29 boundary=-=_NextPart_002_007C_01C3115F.80DFC5E0 30

32、 31 -=_NextPart_002_007C_01C3115F.80DFC5E0 32 Content-Type: text/plain; charset=gb2312 33 Content-Transfer-Encoding: quoted-printable 34 35 bhw98, =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_0

33、1C3115F.80DFC5E0 41 Content-Type: text/html; charset=gb2312 42 Content-Transfer-Encoding: quoted-printable 43 44 45 =C7=E7=C0=CA 46 47 BODY 48 COLOR: #0033cc; FONT-FAMILY: =CB=CE=CC=E5, Arial, Helvetica; FONT-SIZE: = 49 9pt; MARGIN-LEFT: 10px; MARGIN-TOP: 25px 50 51 52 53 55 56 bhw98, =C4=E3=BA=C3!

34、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 64 Content-Type: image/jpeg; name=?gb2312?B?x+fAyrGzvrAuSlBH?= 65 Content-Transfer-Encoding: base6

35、4 66 Content-ID: 67 68 /9j/4AAQSkZJRgABAgEASABIAAD/7QVoUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAASAAAAAEA 69 AQBIAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgAB 70 AAAAAAAAAAI4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEA . . . . 169 RxVw98Vawq12xQ44q0cKtHFDWKGs

36、Kt4EtiuKt4q/9k= 170 171 -=_NextPart_001_007B_01C3115F.80DFC5E0- 172 173 -=_NextPart_000_007A_01C3115F.80DFC5E0 174 Content-Type: application/msword; name=readme.doc 175 Content-Transfer-Encoding: base64 176 Content-Disposition: attachment; filename=readme.doc 177 178 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAA

37、PgADAP7/CQAGAAAAAAAAAAAAAAABAAAAJgAAAAAAAAAA 179 EAAAKAAAAAEAAAD+/AAAAACUAAAD/ 180 / . . . .1688 AAAAAAAAAAAAAAAAAAA=16891690 -=_NextPart_000_007A_01C3115F.80DFC5E01691 Content-Type: application/x-zip-compressed;1692 name=?gb2312?B?tuC0rr/azajQxbXE1LTC6y56aXA=?=1693 Content-Transfer-Encoding: base64

38、1694 Content-Disposition: attachment;1695 filename=?gb2312?B?tuC0rr/azajQxbXE1LTC6y56aXA=?=16961697 UEsDBBQAAAAIAFKAoi7qOMOvLw0AAABWAAAUAAAAtuC0rr/azajQxbXE1LTC6y5kb2PtXHtwVNUZ1698 /+4+kk3IQoAkBkRYQkSgbrKb7IYNEMwmm6ckG0jCI0boZneTbJJ9sNlAEsdOtFqd8Z846tQ6PhB11699 hrZTJoK0Vhgf1aGt4rMy6D8tdugfTjuOpcBIR9

39、j+vvsIy4YkRNTRen87v/ud53cee+6557vn7L73 . . . .3125 zajQxbXE1LTC6y5kb2NQSwUGAAAAAAEAAQBCAAAAYQ0AAA=31263127 -=_NextPart_000_007A_01C3115F.80DFC5E0-3128Q 在开始研究MIME邮件的时候，如何得到这样的源码？ A 一些功能比较完善的邮件客户端软件，如微软的Outlook Express，国产的Foxmail等，都提供了查看和保存邮件源码(原始信息)的功能。在Foxmail中，选择邮件列表右键菜单的“原始信息”进行查看，主菜单的“文件-导出”进行保存。

40、在Outlook Express中，对应的操作分别是“属性”和“另存为”。所保存的.eml文件，可以调用这些程序打开。 Q 请介绍一下MIME邮件的组成？ A 总体来说，MIME消息由消息头和消息体两大部分组成。现在我们关注的是MIME邮件，因此在以下的讨论中姑且称“消息”为“邮件”。在上面的例子中，例1的1-6行，例2的18行，例3的1-18行，是邮件头；例1的89行，例2的1082行，例3的203128行，是邮件体。邮件头与邮件体之间以空行进行分隔，如例1的第7行，例2的第9行，例3的第19行。邮件头中不允许出现空行。有一些邮件不能被邮件客户端软件识别，显示的是原始码，就是因为首行是空行。

41、 邮件头包含了发件人、收件人、主题、时间、MIME版本、邮件内容的类型等重要信息。每条信息称为一个域，由域名后加“: ”和信息内容构成，可以是一行，较长的也可以占用多行。域的首行必须“顶头”写，即左边不能有空白字符（空格和制表符）；续行则必须以空白字符打头，且第一个空白字符不是信息本身固有的，解码时要过滤掉。如例2的7-8行，例3的4-5行，13-14行，分别属于一个域。 邮件体包含邮件的内容，它的类型由邮件头的“Content-Type”域指出。常见的简单类型有text/plain(纯文本)和text/html(超文本)。 例2和例3中出现的multipart类型，是MIME邮件的精髓。邮件

42、体被分为多个段，每个段又包含段头和段体两部分，这两部分之间也以空行分隔。常见的multipart类型有三种：multipart/mixed, multipart/related和multipart/alternative。从它们的名称，不难推知这些类型各自的含义和用处。它们之间的层次关系可归纳为下图所示： +- multipart/mixed -+| | +- multipart/related -+ | | | | | +- multipart/alternative -+ +-+ | +-+ | | | | | 内嵌资源 | | | 附件 | | | | +-+ +-+ | +-+ | +

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

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

45、，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行是纯文

46、本正文，40-59行是超文本正文。 例1只有纯文本正文，实际上属于multipart层次关系图中的一个特殊情况。如果非要避简就繁，写成下面的形式，也是完全符合MIME精神的。 Date: Thu, 18 Apr 2002 09:32:45 +0800From: To: Subject: TestMime-Version: 1.0Content-Type: multipart/alternative; boundary=(_) -(_)Content-Type: text/plain; charset=iso-8859-1Content-Transfer-Encoding: 7bit This

47、is a simple mail. -(_)-Q 在邮件头和段头中，有哪一些常见的域？ A 在邮件头中，有很多从RFC 822沿用的域名，MIME也增加了一些。常见的标准域名和含义如下 域名 含义 添加者 Received 传输路径 各级邮件服务器 Return-Path 回复地址 目标邮件服务器 Delivered-To 发送地址 目标邮件服务器 Reply-To 回复地址 邮件的创建者 From 发件人地址 邮件的创建者 To 收件人地址 邮件的创建者 Cc 抄送地址 邮件的创建者 Bcc 暗送地址 邮件的创建者 Date 日期和时间 邮件的创建者 Subject 主题 邮件的创建者 Me

48、ssage-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 段体的位置(路径) Co