windecember

　　电子邮件是因特网上最为流行的应用之一。如同邮递员分发投递传统邮件一样，电子邮件也是异步的，也就是说人们是在方便的时候发送和阅读邮件的，无须预先与别人协同。与传统邮件不同的是，电子邮件既迅速，又易于分发，而且成本低廉。另外，现代的电子邮件消息可以包含超链接、HTML格式文本、图像、声音甚至视频数据。我们将在本文中查看处于因特网电子邮件核心地位的应用层协议。但在深入讨论这些协议之前，让我们先概览一下因特网邮件系统及其重要部件。

　　下图展示了因特网邮件系统的高层概貌。我们看到，该系统由三类主要部件构成:用户代理、邮件服务器利简单邮件传送协议(simple Mail Transfer Protocol，简称SMTP)。我们将在这样的上下文中说明每类部件:发信人A1ice给收传人Bob发送一个电于邮件消息。用户代理允许用户阅读、回复、转寄、保存和编写邮件消息(电子邮件的用户代理有时称为邮件阅读器，不过我们在本文中避免使用这个说法)。Alice写完电子邮件消息后，她的用户代理把这个消息发送给邮件服务器，再由该邮件服务器把这个消息排入外出消息队列中。当Bob想阅读电子邮件消息时，他的用户代理将从他在其邮件服务器上的邮箱中取得邮件。20世纪90年代后期，图形用户界面(GUI)的电子邮件用户代理变得流行起来，它们允许用户阅读和编写多媒体消息。当前流行的用户代理包括Ootlook,foxmail等。公共域中还有许多基于文本的电于邮件用户代理，包括mail、pine和elm。

图1 因特网电子邮件系统概貌

　　邮件服务器构成了电子邮件系统的核心。每个收信人都有一个位于某个邮件服务器上的邮箱(mailbox)。Bob的邮箱用于管理和维护已经发送给他的邮件消息。一个邮件消息的典型旅程是从发信人的用户代理开始，游经发信人的邮件服务器，中转到收信人的邮件服务器，然后投递到收信人的邮箱中。当Bob想查看自己的邮箱中的邮件消息时，存放该邮箱的邮件服务器将以他提供的用户名和口令认证他。Alice的邮件服务器还得处理Bob的邮件服务器出故障酌情况。如果Alice的邮件服务器无法把邮件消息立即递送到Bob的邮件服务器，A1ice的服务器就把它们存放在消息队列(message queue)中，以后再尝试递送。这种尝试通常每30分钟左右执行一次:要是过了若干天仍未尝试成功，该服务器就把这个消息从消息队列中去除掉，同时以另一个邮件消息通知发信人(即Alice)。

　　简单邮件传送协议(SMTP)是因特网电子邮件系统首要的应用层协议。它使用由TCP提供的可靠的数据传输服务把邮件消息从发信人的邮件服务器传送到收信人的邮件服务器。跟大多数应用层协议一样，SMTP也存在两个端:在发信人的邮件服务器上执行的客户端和在收信人的邮件服务器上执行的服务器端。SMlP的客户端和服务器端同时运行在每个邮件服务器上。当一个邮件服务器在向其他邮件服务器发送邮件消息时，它是作为SMTP客户在运行。当一个邮件服务器从其他邮件服务器接收邮件消息时，它是作为SMTP服务器在运行。

windecember

　　SMTP

　　SMTP在RFC 821中定义，它的作用是把邮件消息从发信人的邮件服务器传送到收信人的邮件服务器。SMIP的历史比HTTP早得多，其RFC是在1982年编写的，而SMTP的现实使用又在此前多年就有了。尽管SMTP有许多奇妙的品质(它在因特网上的无所不在就是见证)，但却是一种拥有某些“古老”特征的传统战术。例如，它限制所有邮件消息的信体(而不仅仅是信头)必须是简单的7位ASCII字符格式。这个限制在20世纪80年代早期是有意义的，当时因特网传输能力不足，没有人在电子邮件巾附带大数据量酌图像、音频或视频文件。然而到了多媒体时代的今天，这个限制就多少显得局促了——它迫使二进制多媒体数据在文由SMTP传送之前首先编码成7位ASCII文本;SMTP传送完毕之后，再把相应的7位ASCII文本邮件消息解码成二进制数据。HTTP不需要对多媒体数据进行这样的编码解码操作。

　　下面我们通过查看一个常见的情形来说明SMTP的基本操作。假设Alice给Bob发送一个简单的ASCII文本邮件消息:

　　●Alice调用自己的电子邮件用户代理，给出Bob的电子邮件地址(譬如说bob@someschool.edu)，写好邮件内容，然后让用户代理发送本邮件消息。

　　●Alice的用户代理把该邮件消息发送到她的邮件服务器中，由邮件服务器把该消息排人某个消息队列中。

　　●运行在A1ice的邮什服务器上的SMTP客户端看到消息队列中的这个邮件消息后，打开一个到运行在Bob的邮件服务器主机上的SMTP服务器端的TCP连接。

　　●经过最初的一些SMTP握手之后，SMTP客户把A1ice的邮件消息发送到TCP连接上。

　　●在Bob的邮件服务器主机上，SMTP服务器收到这个邮件消息后，把这个消息投递到Bob的邮箱中。

　　●Bob在方便的时候调用自己的电子邮件用户代理阅读该邮件消息。

　　图2展示了上述情形。

图2 alice的邮件服务器把邮件消息传送到Bob的邮件服务器

　　需注意的是，SMTP通常不使用中间的邮件服务器主机中转邮件，即便源端和目的端邮件服务器主机位于地球上相反的位置也一样。假设Aiice的邮件服务器主机在香港，Bob的邮件服务器主机在阿拉巴马州，那么所建立的TCP连接将是这两台服务器主机之间的连接。具体地说，如果Bob的邮件服务器不工作了，那么A1ice发给Bob的邮件消息将存留在Alice的邮件服务器中等待新的尝试，而不会存放到某个中间的邮件服务器中。

　　下面查看SWPT把邮件消息从发送端邮件服务器传送到接收端邮件服务器的具体过程。我们将看到，SMTP协议与人们用于面对面交互的礼仪之间有许多相似之处。首先，运行在发送端邮件服务器主机上的SMTP客户，发起建立一个到运行在接收端邮件服务器主机上的SMTP服务器端口号25之间的TCP连接。如果接收邮件服务器当前不在工作，SMTP客户就等待一段时间后再尝试建立该连接。这个连接建立之后，SMTP客户和服务器先执行一些应用层握手操作。就像人们在转手东西之前往往先自我介绍那样，SMTP客户和服务器也在传送信息之前先自我介绍一下。在这个SMTP握手阶段，SMTP客户向服务器分别指出发信人和收信人的电子邮件地址。彼此自我介绍完毕之后，客户发出邮件消息。SMTP可以指望由TCP提供的可靠数据传输服务把该消息无错地传送到服务器。如果客户还有其他邮件消息需发送到同一个服务器，它就在同一个TCP连接上重复上述过程;否则，它就指示TCP关闭该连接。

　　让我们看一个客户(C)和服务器(S)交互的例子。客户所在主机名为crepes.fr，服务器所在主机名为hamburger.edu。前面标以“C:”的ASCII文本行是客户发送到它的TCP套接字中的完整文本行，前面标以“S:”的ASCII文本行是服务器发送到它的TCP套接字中的完整文本行。以下传输脚本在TCP连接建立之后马上发生:

S:220 hamburger.edu 　　C:HELO crepes.fr 　　S:250 Hello crepes.fr,pleased to meet you 　　C:MAIL FROM: 　　S:250 alice@crepes.fr ... Serder OK 　　C:RCPT T 　　S:250 bob@hamburger.edu...Recipient OK 　　CATA 　　S:354 Enter mail,end with "." on a line by its self 　　Co you like ketchup? 　　C:How about pickles? 　　C:. 　　S;250 Message accepted for delivery 　　CUIT 　　S:221 hamburger.edu cloing connection

　　在这个例子中，客户发送了一个从邮件服务器主机crepes.fr到hamburger.edu的邮件消息，信体内容为:“Do you like ketchup?How about pickles?”。客户总共发出了5个命令，分别为:HELO，MAIL FROM，RCPT TO，DATA和QUIT。这些命令的含义是不言自明的。服务器给每个命令发回应答，其中每个应答都由应答码和一些英语解释(可选)构成。这里需指出的是，SMTP使用持久连接，也就是说，如果发送邮件服务器有多个邮件消息需发送到同一个接收邮件服务器，那么所有这些消息可以在同一个TCP连接中发送。对于其中的每一个消息，客户以一个新的“HELO crepes.fr”命令开始整个消息发送过程，但是QUIT命令要等到所有消息都发送完之后才发出。

　　我们可以尝试使用nc工具直接与SMTP服务器进行对话。首先指定使用SMTP端口号25连接到某台邮件服务器主机，这样就在本地主机和该邮件服务器主机之间建立了一个SMTP使用的TCP连接。登录完毕之后，应该立即收到来服务器的应答，接着就可以在合适的时刻依次发出现SMTP命令了。如果你连接到你朋友的5MTP服务器，就可以用这种方式向你的朋友发送邮件了(也就是说，不必使用邮件用户代理)。当然你也可以使用更常见的telnet工具，不过我发现用telnet建立起连接后常会遇到一些输入方面的问题。

windecember

　　与HTTP的比较

　　我们简单地比较一下SMTP和HTTP。这两个协议都是用于从一台主机向另一台主机传送文件;HTTP用于从web服务器向Web用户代理(即浏览器)传送文件(或对象)，SMTP用于从一个邮件服务器向另一个邮件服务器传送文件(也就是电子邮件消息)。在传送文件时，SMTP和持久HTTP都使用持久连接。可见，这两个协议具有一些共同的特征，不过它们之间的差别也是显著的。首先，HTTP基本上是一个内拉式协议(pull protocol)——有人把信息上传到web服务器中，用户则在方便的时候使用HTTP把这些信息从服务器上拉过来。更确切地说，TCP连接是由想要接收文件的主机发起的。SMIP则基本上是一个外推式协议(pushProtoco1)——发送端邮件服务器把文件推送给接收端邮件服务器。更确切地说，TCP连接是由想要发送文件的主机发起的。

　　SMTP和HTTP的第二个重要差别是，SMTP要求包括信体部分在内的每个邮件消息都是7位ASCII文本格式。另外，SMTP RFC还要求每个邮件消息的信体以仅由单个点号构成的一行结束，改用ASCII字符名称来说就是每个邮件消息的信体必须以“CRLF.CRLF“结尾，其中CR和LF分别代表回车符和换行符。这种方式下，当从同一个SMTP客户接收一系列邮件消息时，SMTP服务器可以通过在字节流中搜索“CRLF.CRLF”来分割每个消息。要是信体不是ASCII文本，而是二进制数据(譬如说一幅JPEG图像)，那么这些二进制数据字节流中偶尔出现“CRLF.CRLF”这一模式是有可能的。这将导致SMTP服务器不正确地认定当前邮件消息已结束。为避免这样的问题，二进制数据应以一定的方式先编码成ASCII文本，保证其中不使用特定的ASCH字符(包括点号)。HTTP无论是持久的还是非持久的都不需要预先把二进制数据转换成ASCII本。对于持久的HTTP，每个TCP连接只传送一个对象:服务器关闭连接后，客户就知道己接收到一个完整的响应消息。对于非持久的HTTP，每个响应消息中包含一个Content-length:头部，使得客户能够确定每个响应消息的边界。

　　SMTP和HTTP的第三个重要差别涉及如何处理包含文本和图像或其他媒体类型的文档。HTTP是把每个对象封装在各自的HTTP响应消息中。SMTP(正如接下去要详细讨论的那样)是把同一个邮件内的各个对象置于同一个邮件消息中。

　　邮件消息格式和MIME

　　当Alice给Bob发一封普通的邮政信件时，她把这封信装入一个信封里，在信封上写明Bob的地址和自己的回信地址，然后投入邮箱;邮政业务在递送这封信的过程中，也会把表明时间和地点的邮戳盖在信封上。类似地，当电子邮件消息从一个人传送到另——个人时，在信体之前会有一个含有这些外围信息的信头。这些信息实际上由一系列在RFC 822中定义的邮件消息头部及其值构成。邮件消息中构成信头的各个头部和信体之间以一个空行(也就是CRLF)分割。RFC 822详细说明了各个邮件消息头部的格式和含义。与HTTP一样，邮件消息的每个头部都是直观可读的文本，由一个后跟冒号的关键字和相应的值构成。邮件消息的头部有些是必须的，有些则是司选的。每个信头必须有一个From:头部和一个T头部.还可以有一个Subject:头部和其他头部。需注意的是，这些头部和先前讨论的SMTP命令不是一回事:SMTP命令是SMTP握手协议的一部分，邮件消息头部则属于邮件消息的一部分。

　　下面是一个典型的电子邮件信头:

　　From:alice@crepes.fr

　　Tbob@hamburger.edu

　　Subject:this is a test

　　信头之后空一行就是信体。整个消息以只含有一个点号的单独行结束。

windecember

　　非ASCII数据的MlME扩展

　　RFC 822中说明的邮件消息头部尽管足以满足发送普通ASCII文本邮件的要求，但是在多媒体消息(例如，包含图像、音频或视频数据的消息)的描述和非ASCII文本格式(例如，非英语国家使用的文字)的承载上，却显然不够。要发送非ASCII文本的邮件消息，必须由发送者的用户代理在其中增添额外的头部RFC 2045和RFC 2046定义了这些额外的头部，它们是对RFC 822的多用途因特网邮件扩展(Multipurpose Internet Mail Extensions，简称MIME)。

　　支持多媒体的两个关键MIME头部是Content-Type:和Content-Tansfer-Encoding:。Content-Type:头部允许接收用户代理对邮件消息采取合适的行动。例如，通过指出信体内容为一个JPG图像，接收用户代理可以把信仲定向到某个JNG解压缩例程。我们已经知道，为确保SMTP正常工作，非ASCII文本消息必须预先编码成ASCH文本格式。

　　Content-Tansfer-Encoding:头部用于告知接收用户代理信体已被编码咸ASCII格式，并指出具体编码方式。这样，当某个用户代理收到一个包含这两个头部的邮件消息时，它首先使用Content-Tansfer-Encoding:头部的值把信体转换成原始的非AscH文本形式，再使用Content-Type:头部的值确定自己应该对信体采取什么行动。

　　下面看一个具体的例子。假设Alice想给Bob发送一个JPEG图像，她为此调用自己的用户代理，给出Bob的电子邮件地址和邮件消息的主题，并把这个JPG图像插入这个邮件消息的信体中(这个图像有可能是作为该邮件消息的“附件”插入的，具体取决于Alice所用的用户代理)。Alice填写完邮件消息后让用户代理把它发送出去。Alice的用户代理生成一个大体如下的MIME消息:

From:alice@crepes.fr 　　Tbob@hamburger.edu 　　Subject:picture of mine 　　MIME-Version:1.0 　　Content-Transfer-Encoding:base64 　　Content-Type:image/jpeg 　　{...base64编码数据...) 　　{...base64编码数据...)

　　从中我们可以看到，alice的用户代理采用base64编码格式对这个JPEG图像进行编码i而base64是在MIME中标准化的用于转换成某种可接受的7位ASCII格式的编码技术之一[RFC 2045]。另一种流行的内容传送编码技术称为带转义的可打印(叫quoted-printable)编码格式，一般用于把普通的ASCII邮件消息转换成不带非期望字符串(例如由单个点号构成的行)的ASCII文本。

　　Bob阅读邮件时，其用户代理所操作的是同一个MIME消息。该用户代理看到值为base64的Content-Transfer-Encoding:头部后，知道该邮件消息中还有一个值为image/jpeg的Content-Type:头部，它告知Bob的用户代理应该对信体进行JPEG解压缩。该邮件消息中的MIME-Version:头部自然是在指示本消息所用的MIME版本。需注意的是，邮件消息的其余部分仍然遵循标准的RFC 922/SMTP格式。具体地说，在信头之后有一个空行，接着是信体:在信体结束处是一个仅由单个点号构成的行。

　　我们接下去深入讨论一下Content-Type;头部。该头部按照MIME规范[RFC 2046]有如下的格式;

　　Content-Type: type/subtype; parameters

　　其中parameters(以及其前面的分号)是可选的。通过在Content-Type:头部给出媒体类型名和子类型名，MIME消息信体中数据的性质得以说明。类型名和子类型名之后的其余部分是一组参数。总的说来，顶级类型名用于声明数据的一般类型，子类型名用于指明这类数据中的某种具体格式。参数是对于类型的修饰说明，具体取决于类型和子类型本身，基本上不影响内容性质的指定。MIME是按照可扩展这一目标仔细地设计的，并预期媒体类型/子类型以及它们的相关参数会随时间显著增长。为确保以有秩序的文档完备公开的方式开发这些类型/子类型，MIME建立了一套注册程式，把因特网已分配数值权威(Internet Asigned Numbers Authority，简称IANA)作为MIME各个可扩展域的中心注册处。BFC 2048具体说明了这些可扩展域的注册程式。

　　当前已定义的MIME顶级类型共有7个，每个类型关联一组子类型，其数量在逐年增长。下面是其中的5个类型;

　　●text;text类型用于向接收者的用户代理指出消息体为文本。该类型极为普遍的一个类型/子类型对为text/plain。子类型plain指定不含任何格式定义信息的普通文本。　　plain文本应该不加任何解释地按照原样显示，不需要特殊的软件，能支持给定的字符集就行。在实际的邮件消息中经常能看到值为比text/plain;charset=gb2312或　　text/plain;charset="ISO—8859—1"的Content-Type:头部，其中的参数指出用于产生相应消息的字符集。另一个变得越来越普遍的类型/子类型对是text/html。子类型html指示接收用户代理解释嵌埋在消息体中的html标记，从而像Web页面那样显示信件内容，其中有可能包含各种字体的文本、超链接、Java小应用程序，等等。

　　●image:image类型用于向接收用户代理指出消息体为图像。该类型较为流行的两个类型/子类型对为iamge/gif和image/jpeg，接收用户代理碰到这样的类型时，就知　　道该把消息体作为GIF图像或JPEG图像解码并显示。

　　●audiaudio类型需要音频输出设备(例如扬声器或电话)来表达内容。这类型中常见的已标准化子类型包括basic(基本8位u-law编码)和32kadpcm(RFC 1911中定义的　　一种32Kbps格式)。

　　●videvideo类型的子类型包括mpeg和quicktime。

　　●application:application类型适用于不适合归为其他类别的数据，通常用在必须由某个应用程序预先处理才能为用户所见或所用的数据上。例如.当用户在某个电子邮件消息中附带一个微软word文档时，其用户代理一般把它的类型子类型对指定为application/msword;这将导致接收用户代理启动微软word应用程序，并把该MIME消息的信体传递给它处理。这类型极为重要的一个子类型是octet-stream，它用于指示信体含有任意的二进制数据。收到内容类型为application/octet-stream的邮件消息后，接收用户代理会提示用户是否把信体保存到硬盘中，以便稍后处理。

windecember

　　MIME顶级类型中有一个相当重要的名为MultiPart的类型需要专门讨论。就像一个web页面中可以包含多个对象(例如文本、图像、JAVA小应用程序等)那样，一个电子邮件消息也可以包含多个对象。我们已经知道，Web是通过各自独立的HTTP响应消息传送每个对象的。因特网电子邮件则相反，它把同一个邮件消息的所有对象(即部分)封装在单个消息中。具体地说，当一个多媒体消息含有不止一个对象时(例如多个图像或ASCII文本与图像共存)，其Content-Type:头部的值通常为multipart/mixed。这头部向接收用户代理指出本消息中含有多个对象。既然多个对象共处同一个邮件消息，接收用户代理就得有办法确定1)每个对象的起止位置，(2)每个非ASCII文本对象的传送编码方式，(3)每个对象的内容类型。这是通过在每个对象之间放置边界字符串，并在每个对象之前定义Content-Type:和Content-Transfer-Encoding:头部实现的。

　　为便于理解multipart/mixed，让我们看一个例子。假设Alice想给BOb发送一个邮件消息，其内容为一些ASCII文本，后跟一个JPEG图像，再跟一些ASCII文本。Alice使用自己的用户代理编辑文本并附上图像后，该用户代理生成一个大体如下的邮件消息;

From:alice@crepes.fr 　　Tbob@hamburger.edu 　　MIME-Version:1.0 　　Content-type:multipart/mixed;Boundary=StartOfNextPart 　　--StartOfNextPart 　　Dear bob, 　　Please look at the picture 　　--StartOfNextPart 　　Content-Transfer-Encoding:base64 　　Content-type:image/jpeg 　　(...base64编码的数据... 　　...base64编码的数据...) 　　--StartOfNextPart 　　there is some acsii letter here

　　从中我们可以看出，Content-type:头部的Boundary参数用于指定分隔各个部分的边界字符串。在邮件消息体中，该分隔字符串以两个短划线开头，以CRLF结尾。

　　Received:头部

　　我们已经知道一个电子邮件消息由多个部件构成。信体是邮件消息的核心，它是发送者发送给接收者的真正数据。对于多部分邮件消息来说，其信体本身由多个部分组成，而每个部分又有一个或多个说明其数据性质的头部。信体之前是一个空行和由多个邮件消息头部组成的信头。这些头部既包括在RFC 822中定义的头部，例如From:、T和subject:也包括MIME头部，例如Content-type:和Content-Transfer-Encoding:。除此之外，我们还得提及由SMTP接收服务器插到每个邮件消息的项端的Received:头部，它给出了发出本消息的SMTP服务器的主机名(“from”)、收取本消息的SMTP服务器的主机名(“by”)以及接收服务器收取本消息的时间。因此，作为接收者的用户看到的邮件消息大体如下:

Received:from crepes.fr by hamburger.edu;18 Oct 2005 05:53:37 GMT 　　From:alice@crepes.fr 　　Tbob@hamburger.edu 　　MIME-Version:1.0 　　Content-type:multipart/mixed;Boundary=StartOfNextPart 　　--StartOfNextPart 　　Dear bob, 　　Please look at the picture 　　--StartOfNextPart 　　Content-Transfer-Encoding:base64 　　Content-type:image/jpeg 　　(...base64编码的数据... 　　...base64编码的数据...) 　　--StartOfNextPart 　　there is some acsii letter here

　　有时候，单个邮件消息会有多个Received:头部，有的还会有一个较复杂的Return-path:头部。这是因为邮件消息在从发送者的主机到接收者的主机的传送过程中，可能会被转发到不止一个SMTP服务器。例如，如果Bob指示他在主机hamburger.edu上的邮件服务器把他的所有邮件转发到主机sushi.jp，那么他通过其用户代理看到的邮件消息可能以大体如下的两行开头:

　　Received:from hamburger.edu by sushi.jp;18 Oct 2005 05:55:37 GMT

　　Received:from crepes.fr by hamburger.edu;18 Oct 2005 05:53:37 GMT

　　这些头部给接收用户代理提供了相应邮件消息访问过的SMTP服务器及访问时间的踪迹。SMTP规范所在的RPC 822详细定义丁Received:头部的语法。

windecember

　　MIME顶级类型中有一个相当重要的名为MultiPart的类型需要专门讨论。就像一个web页面中可以包含多个对象(例如文本、图像、JAVA小应用程序等)那样，一个电子邮件消息也可以包含多个对象。我们已经知道，Web是通过各自独立的HTTP响应消息传送每个对象的。因特网电子邮件则相反，它把同一个邮件消息的所有对象(即部分)封装在单个消息中。具体地说，当一个多媒体消息含有不止一个对象时(例如多个图像或ASCII文本与图像共存)，其Content-Type:头部的值通常为multipart/mixed。这头部向接收用户代理指出本消息中含有多个对象。既然多个对象共处同一个邮件消息，接收用户代理就得有办法确定1)每个对象的起止位置，(2)每个非ASCII文本对象的传送编码方式，(3)每个对象的内容类型。这是通过在每个对象之间放置边界字符串，并在每个对象之前定义Content-Type:和Content-Transfer-Encoding:头部实现的。

　　为便于理解multipart/mixed，让我们看一个例子。假设Alice想给BOb发送一个邮件消息，其内容为一些ASCII文本，后跟一个JPEG图像，再跟一些ASCII文本。Alice使用自己的用户代理编辑文本并附上图像后，该用户代理生成一个大体如下的邮件消息;

From:alice@crepes.fr 　　Tbob@hamburger.edu 　　MIME-Version:1.0 　　Content-type:multipart/mixed;Boundary=StartOfNextPart 　　--StartOfNextPart 　　Dear bob, 　　Please look at the picture 　　--StartOfNextPart 　　Content-Transfer-Encoding:base64 　　Content-type:image/jpeg 　　(...base64编码的数据... 　　...base64编码的数据...) 　　--StartOfNextPart 　　there is some acsii letter here

　　从中我们可以看出，Content-type:头部的Boundary参数用于指定分隔各个部分的边界字符串。在邮件消息体中，该分隔字符串以两个短划线开头，以CRLF结尾。

　　Received:头部

　　我们已经知道一个电子邮件消息由多个部件构成。信体是邮件消息的核心，它是发送者发送给接收者的真正数据。对于多部分邮件消息来说，其信体本身由多个部分组成，而每个部分又有一个或多个说明其数据性质的头部。信体之前是一个空行和由多个邮件消息头部组成的信头。这些头部既包括在RFC 822中定义的头部，例如From:、T和subject:也包括MIME头部，例如Content-type:和Content-Transfer-Encoding:。除此之外，我们还得提及由SMTP接收服务器插到每个邮件消息的项端的Received:头部，它给出了发出本消息的SMTP服务器的主机名(“from”)、收取本消息的SMTP服务器的主机名(“by”)以及接收服务器收取本消息的时间。因此，作为接收者的用户看到的邮件消息大体如下:

Received:from crepes.fr by hamburger.edu;18 Oct 2005 05:53:37 GMT 　　From:alice@crepes.fr 　　Tbob@hamburger.edu 　　MIME-Version:1.0 　　Content-type:multipart/mixed;Boundary=StartOfNextPart 　　--StartOfNextPart 　　Dear bob, 　　Please look at the picture 　　--StartOfNextPart 　　Content-Transfer-Encoding:base64 　　Content-type:image/jpeg 　　(...base64编码的数据... 　　...base64编码的数据...) 　　--StartOfNextPart 　　there is some acsii letter here

　　有时候，单个邮件消息会有多个Received:头部，有的还会有一个较复杂的Return-path:头部。这是因为邮件消息在从发送者的主机到接收者的主机的传送过程中，可能会被转发到不止一个SMTP服务器。例如，如果Bob指示他在主机hamburger.edu上的邮件服务器把他的所有邮件转发到主机sushi.jp，那么他通过其用户代理看到的邮件消息可能以大体如下的两行开头:

　　Received:from hamburger.edu by sushi.jp;18 Oct 2005 05:55:37 GMT

　　Received:from crepes.fr by hamburger.edu;18 Oct 2005 05:53:37 GMT

　　这些头部给接收用户代理提供了相应邮件消息访问过的SMTP服务器及访问时间的踪迹。SMTP规范所在的RPC 822详细定义丁Received:头部的语法。

windecember

　　邮件访问协议

　　一旦SMTP把Alice发给Bob的邮件消息从Alice的邮件服务器传送到Bob的邮件服务器，该邮件消息就存放在Bob的邮箱中。在此前的讨论中，我们已假设Bob通过直接登录到自己的邮件服务器主机启动用户代理来阅读该邮件消息。直到20世纪90年代早期，这仍然是标准的做法。然而，当今的用户一般使用在本地PC机(或Mac机)上执行的用户代理来阅读邮件，而不管是办公室PC机、家庭PC机还是便携机。用户在本地PC机上执行用户代理可享受诸多好处，包括方便查看多媒体邮件消息和附件。

　　邮件消息的接收者在本地PC机上执行用户代理时，很自然的一个想法是在本地PC机上也运行邮件服务器。然而这种方法存在一个问题。我们已经知道，邮件服务器是管理邮箱并运行SMlP的客户端和服务器端的，这意味着如果收信人把自己的邮件服务器驻留在本地PC上，那么他不得不始终开着这台PC机并连接在因特网上，以便接收可能在任意时刻到达的新邮件。对于大多数因特网用户来说，这显然是不现实或不经济的做法。相反，用户一般只在本地PC机上运行一个用户代理，由它远程访问存放在某台共享的邮件服务器主机上的邮箱，而该邮件服务器主机总是连接在因特网上并为多个用户所共享。该主机及其上的邮件服务器—般由该用户的ISP(例如大学或公司)维护。

　　既然用户代理运行在各个用户的本地PC机上，邮件服务器则运行在ISP或机构内部网络中的某台服务器主机上，用户代理和邮件服务器之间就得有一个彼此通信的协议。我们先查看一下出自从Alice的本地PC机的某个邮件消息如何设法到达Bob的SMTP邮件服务器。这个任务可简单地由A11ce的用户代理使用SMTP直接与Bob的邮件服务器进行通信来完成。具体地说，从Alice的用户代理发起建立一个到Bob的邮件服务器的TCP连接，并通过该连接发出SMTP握手命令，再用DATA命令上传邮件消息，最后关闭连接。这种方法尽管切实可行，却很少被采用，因为它没有给Alice的用户代理提供任何资源来应对目标邮件服务器临时崩溃的情况。相反，通常采用的方法是先由Alice的用户代理发起与自己的邮件服务器的一个SMTP会话，把邮件消息上传到该邮件服务器;再由Alice的邮件服务器发起与Bob的邮件服务器的一次SMTP会话，把邮件消息中转给Bob的邮件服务器。如果Bob的邮件服务器暂时不可用，Alice的邮件服务器就暂存该邮件消息，以后继续尝试。SMTP的RFC定义了可用于跨多个邮件服务器中转邮件消息的SMTP命令。

　　现在的问题是，像Bob这样在本地PC机上运行用户代理的收信人该如何获取已到达自己的邮件服务器的邮件消息(该邮件服务器运行在Bob的ISP中的某台主机上)。通过引入用于从自己的邮件服务器到本地PC机上的用户代理传送邮件消息的邮件访问协议，这个问题彻底得以解决。日前流行的邮件访问协议有两个:邮局协议版本3(Post office ProtocolVersion 3，简称POP3)和因特网邮件访问协议(Internet Mail Access Protocol，简称IMAP)。注意，用户代理不可能使用SMTP从邮件服务器获取邮件消息，因为邮件消息的获取是一个内拉操作，而SMTP是一个外推协议。图3汇总了因特网电子邮件系统个所用的协议:SMTP用于从发送者的邮件服务器到接收者的邮件服务器传送邮件消息，也用于从发送者的用户代理到发送者的邮件服务器传送邮件消息OP3或IMAP用于从接收者的邮件服务器到接收者的用户代理传送邮件消息。

图3 电子邮件协议及它们的通信实体

windecember

　　POP3

　　RFC 1939个定义的POP3是一个极为简单的邮件访问协议。正因为它过于简单，其功能也相当有限。POP3开始于用户代理(客户)打开一个到POP3服务器(服务器)端口号110的TCP连接。POP3服务器与邮件服务器运行在相同的服务器主机上，前者从用户的邮箱中读取并可能删除邮件消息，后者往用户的邮箱中写入邮件消息。TCP连接建立好之后，POP3依次经历授权队证、处理和更新3个阶段。在授权阶段，用户代理分别发出一个用户名和一个口令以认证下载邮件消息的用户。在处理阶段，用户代理获取邮件消息，并可以标记待删除的邮件消息或去掉这些标记，获取邮件统计信息。更新阶段发生在用户代理发出quit命令以结束当前POP3会话之后，期间POP3服务器删除己加过删除标记的邮件消息。

　　在POP3会话期间，用户代理发出命令，PoP3服务器则对每个命令响应以一个应答。可能的应答有两个:指出刚才的命令执行成功的+oK(有时后跟一个解释性消息)和指出刚才的命令执行有误的-ERR。

　　授权阶段共有两个基本命令:user <用户名>和pass<口令>。我们可以便用telnet工具指定使用POP端口号110直接登录到某台POP3服务器主机，并发出这些命令来展示它们的用法。假设mailserver是你的邮件服务器主机的名字，这个过程大体如下;

telnet mailserver 110 　　+OK POP3 server ready 　　user alice 　　+OK 　　pass password 　　+OK user successfully logged on

　　当然要是写错了某个命令，POP3服务器将返回一个-ERR应答。

　　下面查看一下处理阶段。使用POP3的用户代理可由用户配置成“下载并删除”或“下载并保留”两种模式之一。POP3用尸代理发出的一系列命令取决于自己运行在哪种模式。在下载井删除模式中，用户代理会发出list，retr和dele命令。作为例子，我们假设用户的邮箱中已存有两个邮件消息，共POP3处理阶段大体如下(其中前面标以“C:”的是用户代理发出的命令，前面标以“S:”的是POP3服务器返回的应答):

C:list 　　S:1 498 　　S:2 912 　　S:. 　　C:retr 1 　　Sblab ...... 　　S: ............ 　　S: ......) 　　S:. 　　C:dele 1 　　C:retr 2 　　S... ... 　　S:... 　　S:......) 　　S:. 　　C:dele 2 　　C:quit 　　S:+OK POP3 server signing off

　　用户代理首先要求POP3服务器列出存放在自己的邮箱中的每个邮件消息的大小，接着依次取回并删除每个邮件消息。需注意的是，授权阶段结束之后，用户代理只能发出4个命令:list，retr，deie，quitt。这些命令的具体语法定义在RFC 1939中。处理完quit命令后，POP3服务器进入更新阶段，把邮件消息1和2从相应的邮箱中删除。

　　下载并删除模式存在一个问题，也就是收信人可能希望从不止一台主机访问自已的邮箱，如既能从办公室PC机访问.也能从家庭PC机访问，还能从使携机访问。下裁并删除模式将导致同一用户的邮件消息散布到他的多台主机上;例如，要是他先在家里的PC机上阅读了某个邮件消息，以后就没法在使携机上阅读同一个邮件消息了。下裁并保留模式则恰好相反，用户代理把己从POP3服务器下载的邮件消息继续保留在邮件服务器中。这种模式下，用户可以在不同的时间从不向的主机访问同样的邮件消息。

　　在用户代理和邮件服务器之间的POP3会话期间，POP3务器维护一定的状态信息:具体地说，它跟踪哪些邮件消息己被标记成待删除。不过POP3服务器不会跨会话保存状态信息。例如，每次会话开始之时没有任何邮件消息被标记成待删除。这种不跨会话保存状态信息的处理办法极大地简化了PoP3服务器软件的实现。

windecember

　　IMAP

　　收信人使用POP3把邮件消息下载到本地机之后，就可以把它们移入现行的或新创建的邮件夹中。他然后可以删除邮件消息，跨邮件夹转移邮件消息，按发信人名字或消息主题搜索邮件消息，等等。然而，这种邮件夹和邮件消息都存放在本地机上的模式对于游动用户却构成了问题。游动用户更愿意在远程邮件服务器主机上维护邮件夹，这样从任何主机都可以访问它。使用POP3是不可能做到达一点的。

　　RFC 2060中定义的IMAP协议正是为解决本问题和其他一些问题而发明的。IMAP提供的特性比POP3多出不少，不过也复杂得多，其客户端和服务器端的实现也相应地更为复杂。IMAP设计成允许用户象对待本地邮箱那样操纵远程邮箱。具体地说，IMAP使得收信人能够在自己的邮件服务器主机中创建并维护多个存放邮件消息的邮件夹。他们可以把邮件消息存入邮件夹，也可以从一个邮件夹到另一个邮件夹转移邮件，还可以在这些远程邮件夹中搜索匹配特定准则的邮件消息。IMAP的实现比POP3的实现复杂得多，原因之一就是IMAP服务器必须为每个用户维护一个邮件夹层次结构。某个用户相继访问自己的IMAP服务器时，这个IMAP服务器为该用户维护的状态信息跨这些相继的访问保持一致。POP3服务器则相反，一旦用户退出当前的POP3会话，它们就不再为他们维护状态信息。

　　IMAP的另一个重要特性是，它有一些允许用户代理获取邮件消息部件的命令。例如，用户代理可以只获取邮件消息的信头，或者只获取多部分MIME消息的某个部分。这个特性在用户代理和邮件服务器主机之间为低带宽连接(例如无线连接或低速调制解调器拨号连接)时非常有用。通过低带宽连接访问邮件时，用户很可能不希望下载自己的邮箱中的所有邮件消息，特别是可能含有音频或视频剪辑的长消息。

　　IMAP会话过程首先是用户代理(客户)发起建立…个到IMAP服务器(服务器)端口号143的TCP连接，然后是服务器返回初始问候消息，接着就是客户和服务器之间的交互了。客户和服务器的交互与POP3的类似，不过要丰富些，由客户发出的命令、服务器返回的数据或命令完成结果响应构成。IMAP服务器在会话期间总是处于以下4个状态之一:未认证(nonauthenticated)、已认证(authenticated)、已选择(selected)和注销(1ogout)。未认证状态是连接刚建立时的初始状合，这种状态下，用户必须提供一个用户名和口令对才能发出更多的命令。在已认证状态下，用户必须选择一个邮件夹才能发出作用于邮件消息的命令。在已选择状态下，用户可以发出作用于邮件消息的任何命令(获取、转移、删除、获取多部分消息的某个部分，等等)。最后的注销状态是会话即将终止时的状态。IMAP命令是按照每个状态下分别能够执行哪些命令来组织的。在IMAP的官方站点可以找到关十IMAP的所有内容。

　　HTTP邮件

　　今天，越来越多的用户转向使用基于浏览器的电子邮件服务，例如Hotmail和Yahoo!Mall。使用提供这种服务的服务器时，用户代理是普通的web浏览器，用户与存放在邮件服务器主机上的邮箱之间的交互相应地经由HTTP完成。当收信人(例如Bob)想要查看自己的邮箱中的邮件消息时，这些消息是通过HTTP协议(而不是POP3或IMAP协议)从邮件服务器主机传送到他的浏览器的。当发信人(例如Alice)想要发送电子邮件消息时，这些消息也是通过HTTP(而不是SMTP)从她的浏览器传送到她的邮件服务器主机的。不过邮件消息在邮件服务器主机之间的中转仍然通过SMTP。这种邮件访问办法对于游动用户来说极为方便。游动用户只要能使用浏览器，就能收发邮件消息，而浏览器可以在网吧、朋友家、装有Web Tv的旅馆等地方找到。与IMAP一样，用户可以在远程服务器主机中使用一个邮件夹层次结构组织邮件消息。基于Web的电子邮件既然如此方便，在未来几年内替换掉POP3或IMAP访问办法也是有可能的。它的主要不足之处在于速度比较慢，因为其服务器主机往往远离客户主机，而且用户的浏览器是通过CGl脚本与邮件服务器间接交互的。

　　持续媒体电子邮件

　　持续媒体(continuous-media，简称CM)电子邮件是包含音频或视频数据的电子邮件系统，它对于朋友之间和家庭成员之间的异步交流很有吸引力。例如，学龄前儿童更愿意使用CM电子邮件给祖父母发送邮件消息。CM电子邮件在公司也可能受欢迎，因为办公室工作人员录制CM邮件消息的速度要比输入文本消息的速度快许多(使用英语每分钟可以说180个单词，但是普通办公室工作人员每分钟只能输入20一40个单词)。CM电子邮件在某些方面类似电话语音留言，不过功能要强大得多。它不仅给用户提供一个访问邮箱的图形界面，而且允许用户评注并回复CM邮件消息，或者把CM邮件消息转发给多个收信人。

　　CM电子邮件与传统文本电子邮件在许多方面存在差异。CM电子邮件可能有大得多的邮件消息，对于端到端延迟有更严格的要求，对于收传人干差万别的因特网访问速率和本地存储容量也更为敏感。不幸的是，当前的电子邮件设施存在一些妨碍CM电于邮件推广的不足之处。首先，许多现有的邮件服务器没有存放大的邮件消息的容量;它们一般拒绝接收或中转CM邮件消息，因此不可能给依附它们的收传人发送这样的消息。其次，收信人的用户代理只在取得完整的邮件消息后才表达其内容，对于CM电子邮件，这会导致网络带宽和本地主机存储容量的过度浪费。事实上，仓储的CM邮件消息往往不是完整地表达的，因此接收未作表达的数据显然浪费了网络带宽和本地存储容量(例如，当某人收到来自相当唠叨的同事的长篇语音邮件消息后，可能只听上前15秒就决定不再听，要删除还剩20分钟内容的整个消息)。再次，当前使用的邮件访问协议(POP3，IMAP，HTTP)不适合为收信人流播放CM邮件消息。

　　具体地说，这些邮件访问协议没有提供这样的功能:允许用户暂停/恢复播放邮件消息内容，或者在邮件消息内重新定位播放点;另外，在TCP上实现流播放往往导致糟糕的接收效果。这些不足之处有望在未来的几年内得到解决。不过近来超大邮箱开始流行起来，如GMAIL等，邮箱容量的限制问题正在得到解决。