MIME协议

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" <bhw98@sina.com>

   2 Reply-To: bhw98@sina.com

   3 To: <bluesky7810@163.com>

   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 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

  37 <HTML><HEAD>

  38 <META content=3D"text/html; charset=3Dgb2312"=

  39  http-equiv=3DContent-Type>

  40 <META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>

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

  79 </HTML>

  80

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

  82

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

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

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

域名
 含义
 添加者
 
Received
 传输路径
 各级邮件服务器
 
Return-Path
 回复地址
 目标邮件服务器
 
Delivered-To
 发送地址
 目标邮件服务器
 
Reply-To
 回复地址
 邮件的创建者
 
From
 发件人地址
 邮件的创建者
 
To
 收件人地址
 邮件的创建者
 
Cc
 抄送地址
 邮件的创建者
 
Bcc
 暗送地址
 邮件的创建者
 
Date
 日期和时间
 邮件的创建者
 
Subject
 主题
 邮件的创建者
 
Message-ID
 消息ID
 邮件的创建者
 
MIME-Version
 MIME版本
 邮件的创建者
 
Content-Type
 内容的类型
 邮件的创建者
 
Content-Transfer-Encoding
 内容的传输编码方式
 邮件的创建者
 

表 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所示

主类型
 参数名
 含义
 
text
 charset
 字符集
 
image
 name
 名称
 
application
 name
 名称
 
multipart
 boundary
 边界
 

表 2 常见类型的参数

 

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

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

近年来,国内多数邮件服务器已经支持8bit方式,因此只在国内传输的邮件,特别是在邮件头中,可直接使用8bit编码,对汉字不做处理。如果邮件要出国,还是老老实实地按Base64或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给出了段头中常见的域。

域名
 含义
 
Content-Type
 段体的类型
 
Content-Transfer-Encoding
 段体的传输编码方式
 
Content-Disposition
 段体的安排方式
 
Content-ID
 段体的ID
 
Content-Location
 段体的位置(路径)
 
Content-Base
 段体的基位置
 

表 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

 

本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/bripengandre/archive/2008/03/17/2192982.aspx

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
MIME结构 一、 RFC822协议 RFC822 文档定义了邮件内容的主体结构和各种邮件头字段的详细细节,但是,它没有定义邮件体的格式,RFC822文档定义的邮件体部分通常都只能用于表述一段普通的文本,而无法表达出图片、声音等二进制数据。另外,SMTP服务器在接收邮件内容时,当接收到只有一个“.”字符的单独行时,就会认为邮件内容已经结束,如果一封邮件正文中正好有内容仅为一个“.”字符的单独行,SMTP服务器就会丢弃掉该行后面的内容,从而导致信息丢失。 由于 Internet的迅猛发展,人们已不满足于电子邮件仅仅是用来交换文本信息,而希望使用电子邮件来交换更为丰富多彩的多媒体信息,例如,在邮件中嵌入图片、声音、动画和附件。但是,由于图片和声音等内容是非ASCII码的二进制数据,而RFC822邮件格式只适合用来表达纯文本的邮件内容,所以,要使用 RFC822邮件格式发送这些非ASCII码的二进制数据时,必须先采用某种编码方式将它们“编码”成可打印的ASCII字符后再作为RFC822邮件格式的内容。邮件阅读程序在读取到这种经过编码处理的邮件后,再按照相应的解码方式解码出原始的二进制数据,这样就可以借助RFC822邮件格式来传递多媒体数据了。这种做法需要解决以下两个技术问题: (1) 邮件阅读程序如何知道邮件中嵌入的原始二进制数据所采用的编码方式; (2) 邮件阅读程序如何知道每个嵌入的图像或其他资源在整个邮件内容中的起止位置。 针对这个问题,人们后来专门为此定义了MIME(Multipurpose Internet Mail Extension,多用途Internet邮件扩展)协议。 .....
MIME协议(中文版)》,DOC格式,大小89KB。 内容预览: MIME结构 一、 RFC822协议 RFC822 文档定义了邮件内容的主体结构和各种邮件头字段的详细细节,但是,它没有定义邮件体的格式,RFC822文档定义的邮件体部分通常都只能用于表述一段普通的文本,而无法表达出图片、声音等二进制数据。另外,SMTP服务器在接收邮件内容时,当接收到只有一个“.”字符的单独行时,就会认为邮件内容已经结束,如果一封邮件正文中正好有内容仅为一个“.”字符的单独行,SMTP服务器就会丢弃掉该行后面的内容,从而导致信息丢失。 由于 Internet的迅猛发展,人们已不满足于电子邮件仅仅是用来交换文本信息,而希望使用电子邮件来交换更为丰富多彩的多媒体信息,例如,在邮件中嵌入图片、声音、动画和附件。但是,由于图片和声音等内容是非ASCII码的二进制数据,而RFC822邮件格式只适合用来表达纯文本的邮件内容,所以,要使用 RFC822邮件格式发送这些非ASCII码的二进制数据时,必须先采用某种编码方式将它们“编码”成可打印的ASCII字符后再作为RFC822邮件格式的内容。邮件阅读程序在读取到这种经过编码处理的邮件后,再按照相应的解码方式解码出原始的二进制数据,这样就可以借助RFC822邮件格式来传递多媒体数据了。这种做法需要解决以下两个技术问题: (1) 邮件阅读程序如何知道邮件中嵌入的原始二进制数据所采用的编码方式; (2) 邮件阅读程序如何知道每个嵌入的图像或其他资源在整个邮件内容中的起止位置。 针对这个问题,人们后来专门为此定义了MIME(Multipurpose Internet Mail Extension,多用途Internet邮件扩展)协议。 二、 RFC822结构

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值