MIME邮件面面观(转自clearsmoking的专栏http://blog.csdn.net/clearsmoking/archive/2008/01/07/2028675.aspx)

最新推荐文章于 2022-09-05 11:05:35 发布

kinomn

最新推荐文章于 2022-09-05 11:05:35 发布

阅读量1.9k

点赞数 1

文章标签：邮件服务器 express microsoft c html .net

本文链接：https://blog.csdn.net/kinomn/article/details/2064738

版权

Q 什么是 MIME ？什么是 MIME 邮件？

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

自然， MIME 邮件就是符合 MIME 规范的电子邮件，或者说根据 MIME 规范编码而成的电子邮件。

在 MIME 出台之前，使用 RFC 822 只能发送基本的 ASCII 码文本信息，邮件内容如果要包括二进制文件、声音和动画等，实现起来非常困难。 MIME 提供了一种可以在邮件中附加多种不同编码文件的方法，弥补了原来的信息格式的不足。实际上不仅仅是邮件编码，现在 MIME 经成为 HTTP 协议标准的一个部分。

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

例 1

1 Date: Thu, 18 Apr 2002 09:32:45 +0800 2 From: <bhw98@sina.com> 3 To: <bhwang@jlonline.com> 4 Subject: Test 5 Mime-Version: 1.0 6 Content-Type: text/plain; charset="iso-8859-1" 7 8 This is a simple mail. 9

例 2

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

例 3

1 Return-Path: <bluesky7810@163.com> 2 Delivered-To: bhw98@sina.com 3 Received: (qmail 75513 invoked by alias); 20 May 2002 02:19:53 -0000 4 Received: from unknown (HELO bluesky) (61.155.118.135) 5 by 202.106.187.143 with SMTP; 20 May 2002 02:19:53 -0000 6 Message-ID: <007f01c3111c$742fec00$0100007f@bluesky> 7 From: "=?gb2312?B?wLbAtrXEzOwNCg==?=" <bluesky7810@163.com> 8 To: "bhw98" <bhw98@sina.com> 9 Cc: <bhwang@jlonline.com> 10 Subject: =?gb2312?B?ztK1xLbgtK6/2rPM0PI=?= 11 Date: Sat, 20 May 2002 10:03:36 +0800 12 MIME-Version: 1.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. 21 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 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_01C3115F.80DFC5E0 41 Content-Type: text/html; charset="gb2312" 42 Content-Transfer-Encoding: quoted-printable 43 44 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> 45 <HTML><HEAD><TITLE>=C7=E7=C0=CA</TITLE> 46 <META content=3D"text/html; charset=3Dgb2312" http-equiv=3DContent-Type> 47 <STYLE>BODY { 48 COLOR: #0033cc; FONT-SIZE: = 49 9pt; MARGIN-LEFT: 10px; MARGIN-TOP: 25px 50 } 51 </STYLE> 52 <META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR></HEAD> 53 <BODY background=3Dcid:007901c3111c$72b978a0$0100007f@bluesky = 54 bgColor=3D#ffffff> 55 <DIV> 56 <DIV>bhw98, =C4=E3=BA=C3!</DIV> 57 <P>=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!</P></DIV> 59 <P> </P></BODY></HTML> 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: base64 66 Content-ID: <007901c3111c$72b978a0$0100007f@bluesky> 67 68 /9j/4AAQSkZJRgABAgEASABIAAD/7QVoUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAASAAAAAEA 69 AQBIAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgAB 70 AAAAAAAAAAI4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEA ... ... ... ... 169 RxVw98Vawq12xQ44q0cKtHFDWKGsKt4EtiuKt4q//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 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/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: base641694 Content-Disposition: attachment;1695 filename="=?gb2312?B?tuC0rr/azajQxbXE1LTC6y56aXA=?="16961697 UEsDBBQAAAAIAFKAoi7qOMOvLw0AAABWAAAUAAAAtuC0rr/azajQxbXE1LTC6y5kb2PtXHtwVNUZ1698 /+4+kk3IQoAkBkRYQkSgbrKb7IYNEMwmm6ckG0jCI0boZneTbJJ9sNlAEsdOtFqd8Z846tQ6PhB11699 hrZTJoK0Vhgf1aGt4rMy6D8tdugfTjuOpcBIR9j+vvsIy4YkRNTRen87v/ud53cee+6557vn7L73 ... ... ... ...3125 zajQxbXE1LTC6y5kb2NQSwUGAAAAAAEAAQBCAAAAYQ0AAA==31263127 ------=_NextPart_000_007A_01C3115F.80DFC5E0--3128

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

A 一些功能比较完善的邮件客户端软件，如微软的 Outlook Express ，国产的 Foxmail 等，都提供了查看和保存邮件源码 ( 原始信息 ) 的功能。在 Foxmail 中，选择邮件列表右键菜单的 “ 原始信息 ” 进行查看，主菜单的 “ 文件 - 导出 ” 进行保存。在 Outlook Express 中，对应的操作分别是 “ 属性 ” 和 “ 另存为 ” 。所保存的 .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, 18 Apr 2002 09:32:45 +0800From: <bhw98@sina.com>To: <bhwang@jlonline.com>Subject: TestMime-Version: 1.0Content-Type: multipart/alternative; boundary="{[(^_^)]}" --{[(^_^)]}Content-Type: text/plain; charset="iso-8859-1"Content-Transfer-Encoding: 7bit This is a simple mail. --{[(^_^)]}--

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

A 在邮件头中，有很多从 RFC 822 沿用的域名， 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” 。

Q Content-Type 以及它们的参数有哪些形式？

A Content-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 里有很多补充规定，有的允许带几个参数，较为常见的有

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

其中字符集也能在 Windows 注册表的 “HKEY_CLASSES_ROOT/MIME/Database/Charset” 内见到。

Q Content-Transfer-Encoding 有哪些？有什么特点？

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

Base64 将输入的字符串或一段数据编码成只含有 {'A'-'Z', 'a'-'z', '0'-'9', '+', '/'} 这 64 个字符的串， '=' 用于填充。其编码的方法是，将输入数据流每次取 6 bit ，用此 6 bit 的值 (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 编码。

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 为 007901c 3111c $72b978a0$0100007f@bluesky 的图片作为背景 (cid:xxxxxxxx 也是一种超级链接 ) 。而 64-169 行恰好就是这样一个内嵌资源。

除了用 Content-ID 进行联系外，还有另外一种常用形式：用普通超级连接和 Content-Location 。例如：

在 HTML 正文中，

... ... ... ...<IMG SRC="http://www.dangdang.com/images/all/anti_joyo_dm_book.gif">... ... ... ...<IMG SRC="http://www.dangdang.com/dd2001/getimage_small.asp?id=486341">... ... ... ...

对应的内嵌资源为

Content-Type: image/gif; name="anti_joyo_dm_book.gif"Content-Transfer-Encoding: base64Content-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: base64Content-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.gifContent-Base: http://www.dangdang.com/images/all/

是等效的。

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

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

MIME-Version: 1.0Content-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 <HTML><HEAD></HEAD><BODY bgColor=#ffffff><iframe src=cid:EA4DMGBP9p height=0 width=0></iframe></BODY></HTML>--====_ABC0987654321DEF_====-- --====_ABC1234567890DEF_====Content-Type: audio/x-wav; name="readme.exe"Content-Transfer-Encoding: base64Content-ID: <EA4DMGBP9p> TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2AAAAA4fug4AtAn

NIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0KJAAAAAAAAAA11CFvcbVPPHG1TzxxtU88E6pcPHW1TzyZqkU8dbVPPJmqSzxytU88cbVO... ... ... ... ... ... ... ...AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --====_ABC1234567890DEF_====

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

纵观历史，病毒刚出来时是厉害，但没有任何一种能够持续肆虐下去。 Nimda 如此， SARS 亦当如此。曰： “ 多难兴邦，众志成城 ” ，又曰： “ 非典终将倒下，城市精神永存 ” ，相信我们定能很快战胜 “ 非典 ”!

病毒库升级是跟在新病毒屁股后进行的，不要过分依赖杀毒软件。一个良好的习惯是关闭邮件预览功能，或者设定预览纯文本部分，先查看邮件源码，确信排除病毒嫌疑后再打开。对陌生人发来的带超文本正文的邮件，尤其要当心。永远不要在邮件客户端软件内直接打开附件。

Q 一些垃圾邮件采取隐藏发件人的方式，如何追查它们来自哪里？

A 从上面的邮件头域名表中可以看出，邮件的创建者可以掌握大部分的域的内容，但 Received 等域由各级服务器自动添加，发件人是鞭长莫及。垃圾邮件一般采用了群发软件发送，邮件头的 From 域 ( 发件人地址 ) 可以任意伪造，甚至写成收件人地址 ( 收到了自己并没有发过的垃圾邮件，气愤吧？ ) 。查看 Received 域 ( 传输路径 ) 链可以找到真正的出处。每个服务器添加的 Received 语句都在邮件首，故最下面一个 Received 就包含了发件人所用的 SMTP 或 HTTP 服务器，及最初的网关外部 IP 地址。

Receive 语句的基本格式是： from A by B 。 A 为发送方， B 为接收方。例如：

Received: (qmail 45304 invoked from network); 4 May 2003 17:05:47 -0000Received: from unknown (HELO bjapp9.163.net) (202.108.255.197) by 202.106.182.244 with SMTP; 4 May 2003 17:05:47 -0000Received: from localhost (localhost [127.0.0.1]) by bjapp9.163.net (Postfix) with SMTP id E1C761D84C631 for <bhw98@sina.com>; Mon, 5 May 2003 01:07:26 +0800 (CST)Received: from fanyingxxxx@tom.com (unknown [211.99.162.194]) by bjapp9.163.net (Coremail) with SMTP id OgEAAM1ItT7MNaLC.1 for <bhw98@sina.com>; Mon, 05 May 2003 01:07:26 +0800 (CST)

从上面的例子中不难看出，该邮件的传输路径是： 211.99.162.194 → bjapp9.163.net (Coremail 202.108.255.197?) → bjapp9.163.net (Postfix, 202.108.255.197?) → 202.106.182.244 。恰好出现了发件人邮箱 fanyingxxxx@tom.com ，但多数情况不一定能列出来。

此例的 localhost [127.0.0.1] ，意味着 bjapp9.163.net 上安装了邮件服务代理性质的软件。