RFC822邮件格式

RFC822邮件格式

邮件内容的格式在RFC822文档中定义，它包括两个主要的组成部分：邮件头和邮件体。在第2章的SMTP协议的实验中，it315_test @sohu.com邮箱中接收到的[e-mail]发送来的邮件的最终内容如例程3-1所示，其中的行号不属于邮件内容，是作者为了便于讲解而加上的。

例程3-1 test.eml

1．Return-Path:<[e-mail]>

2．Delivered-To:[e-mail]

3．Received: fromsmtp.sina.com.cn (unknown [202.108.3.177])

4． bysohumx139.sohu.com (Postfix) with SMTP id E4F9802C1249

5． for<[e-mail]>; Thu, 10 Nov 2005 16:39:50 +0800 (CST)

6．Received: (qmail49221 invoked from network); 10 Nov 2005 08:39: 33 -0000

7．Received: fromunknown (HELO it315?test) (218.246.5.151)

8． by smtp.sina.com.cnwith SMTP; 10 Nov 2005 08:39:33 -0000

9． From:[e-mail]

10．To:[e-mail]

11．subject:test

12．Message-Id:<[e-mail]>

13．Date: Thu, 10 Nov2005 16:39:50 +0800 (CST)

14．Status: RO

15．X-UIDL:1131611863.21509_77.mx72

16．

17．test!!!

例程3-1中的第1～15行是邮件的邮件头，第17行是邮件的邮件体，邮件头和邮件体之间以一个空行进行分隔。这封邮件的邮件体内容非常少，只有一行“test!!!”文本。邮件头部分由多个头字段和字段内容组成，各种头字段分别用于表示邮件的发件人、收件人、发件时间和主题等信息。细心的读者可能已经看到，例程3-1中的邮件头部分比在第2章的SMTP协议的实验中实际发送的邮件头多出了一些头字段，这些头字段是各个SMTP服务器在传递邮件的过程加上的。SMTP服务器在传递邮件时，会把一些相关信息增加到邮件的邮件头中，这种情况有点类似于现实生活中的邮局在处理邮件时，通常都会在信封上加盖邮戳一样，表示这封邮件在什么时候经过了哪个邮局和由哪个工作人员经手处理。SMTP服务器按从下往上的方式添加各个字段，即先添加的字段位于后添加的字段的下面，例如，例程3-1中的邮件是由sina发送给sohu的，它首先经过sina的SMTP服务器，然后经过sohu的SMTP服务器，所以，sohu的SMTP服务器添加的头字段（1～5行）位于sina的SMTP服务器添加的头字段（6～8行）的上面。另外，POP3服务器也会在邮件头中增加一些头字段，例如，例程3-1中的12～15行。

每一个邮件头以“字段名：字段值”的格式出现，即每一行邮件头的内容依次由字段名、冒号、空格、字段值、回车换行符组成。RFC822文档中定义了多个标准的邮件头字段，每一个邮件头字段表示一种特定的信息。邮件头中也可以包含自定义的头字段，这种自定义的头字段通常是某个组织或机构内部专用的。下面是对例程3-1中出现的一些主要的邮件头字段的解释：

— Return-Path 该字段代表邮件的回复地址，该字段内容由接收邮件的SMTP服务器填写，接收邮件的SMTP服务器从邮件发送程序发出的mail form命令中获得该字段内容。

 

— Received 该字段的基本格式为Receivedfrom A by B for C，其中A为发送方，B为接收方，C为收件人的邮箱地址。该字段的内容由接收邮件的SMTP服务器填写，常常被用来追踪邮件传输的路线和分析邮件的来源，例如，从例程3-1中的各个Received字段中，可以知道这封邮件的传输路径：从IP地址为【218.246.5.151】的机器上发出→【smtp.sina.com.cn】→【sohumx139.sohu.com】→【[e-mail]】。例程3-1中的第6行的“Received: (qmail 49221 invoked from network)”是sina的SMTP服务器内部调用的一个邮件发送模块添加的，它说明sina的SMTP服务器接收到邮件后再通过这个邮件发送模块将邮件转发出去。显然，通过分析一封邮件的源内容，是可以知道发件人的IP地址的。

 

— From 该字段用于指定的发件人地址，邮件阅读程序显示的发件人地址就来源于这个字段。From字段中指定的发件人地址可以随意乱写，甚至不写，所以，邮件阅读程序显示的发件人地址不一定是真实的，这通常可以通过查看邮件头中的Return-Path字段来判断发件人的真实性。注意，SMTP协议中mail from命令中指定的发件人地址也可以伪造，所以，邮件头中的Return-Path字段也不是可以完全信赖的，对于比较重要的邮件，最好还是通过电话确认一下。

 

— to该字段用于指定收件人地址。

 

— subject 该字段用于指定邮件的主题，如果主题内容中包含有ASCII码以外的字符，通常要对其内容进行编码。

 

— date 该字段用于指定邮件的发送时间。邮件头中除了包含上面的这些字段外，还有另外两个比较常用的字段：

 

— cc 该字段用于指定邮件的抄送地址。

 

— bcc 该字段用于指定邮件的暗送地址。抄送地址和暗送地址的区别在于，邮件阅读程序通常都不显示暗送地址，而会显示抄送地址。

RFC822文档定义了邮件内容的主体结构和各种邮件头字段的详细细节，但是，它没有定义邮件体的格式，RFC822文档定义的邮件体部分通常都只能用于表述一段普通的文本，而无法表达出图片、声音等二进制数据。另外，SMTP服务器在接收邮件内容时，当接收到只有一个“.”字符的单独行时，就会认为邮件内容已经结束，如果一封邮件正文中正好有内容仅为一个“.”字符的单独行，SMTP服务器就会丢弃掉该行后面的内容，从而导致信息丢失。

由于Internet的迅猛发展，人们已不满足于电子邮件仅仅是用来交换文本信息，而希望使用电子邮件来交换更为丰富多彩的多媒体信息，例如，在邮件中嵌入图片、声音、动画和附件。但是，由于图片和声音等内容是非ASCII码的二进制数据，而RFC822邮件格式只适合用来表达纯文本的邮件内容，所以，要使用RFC822邮件格式发送这些非ASCII码的二进制数据时，必须先采用某种编码方式将它们“编码”成可打印的ASCII字符后再作为RFC822邮件格式的内容。邮件阅读程序在读取到这种经过编码处理的邮件后，再按照相应的解码方式解码出原始的二进制数据，这样就可以借助RFC822邮件格式来传递多媒体数据了。这种做法需要解决一下两个技术问题：

（1）邮件阅读程序如何知道邮件中嵌入的原始二进制数据所采用的编码方式；

（2）邮件阅读程序如何知道每个嵌入的图像或其他资源在整个邮件内容中的起止位置。

针对这个问题，人们后来专门为此定义了MIME（Multipurpose Internet Mail Extension，多用途Internet邮件扩展）协议。

MIME协议用于定义复杂邮件体的格式，它可以表达多段平行的文本内容和非文本的邮件内容，例如，在邮件体中内嵌的图像数据和邮件附件等。另外，MIME协议的数据格式也可以避免邮件内容在传输过程中发生信息丢失。MIME协议不是对RFC822邮件格式的升级和替代，而是基于RFC822邮件格式的扩展应用。一言以蔽之，RFC822定义了邮件内容的格式和邮件头字段的详细细节，MIME协议则是定义了如何在邮件体部分表达出的丰富多样的数据内容。

一个采用了MIME协议的电子邮件就叫做MIME邮件，MIME邮件在RFC822文档中定义的邮件头字段的基础上，扩充了一些自己专用的邮件头字段，例如，使用MIME-Version头字段指定MIME协议的版本，使用Content-Type头字段指定邮件体的MIME类型，使用Content-Transfer-Encoding头字段指定编码方法，如下所示：

MIME-Version:1.0

Content-Type:multipart/mixed;boundary="----=_NextPart_000_0050_01C"

其中，“multipart/mixed”部分说明邮件体中包含有多段数据，每段数据之间使用boundary属性中指定的字符文本作为分隔标识符。另外，MIME邮件也扩展了RFC822文档中已经定义了的邮件头字段的内涵，例如，定义了subject头字段中的值内容的格式，以便通过编码的方式让邮件主题中也可以使用非ASCII码的字符。subject头字段中的值嵌套在一对“=?”和“?=”标记符之间，标记符之间的内容由三部分组成：邮件主题的原始内容的字符集、当前采用的编码方式、编码后的结果，这三部分之间使用“?”进行分隔。下面是一个对包含有非ASCII码字符的邮件主题进行了编码后的结果：

Subject:=?gb2312?B?TUlNRdCt0unLtcP308q8/g==?=

其中，“gb2312”部分说明邮件主题的原始内容为gb2312编码的字符文本，“B”部分说明对邮件主题的原始内容按照BASE64方式进行了编码，“TUlNRdCt0unLtcP308q8/g==”为对邮件主题的原始内容进行了BASE64编码后的结果。

可见，MIME邮件与普通的RFC822邮件的关系犹如Java编程语言中的子类与父类的关系，子类是对父类的扩展，子类功能更强大，但子类离不父类的支持。如果需要了解MIME的详细细节，可以查阅RFC 2045～2049系列文档