第二章应用层
2.4因特网中的电子邮件
因特网电子邮件系统的3个组成部分：用户代理（useragent）、邮件服务器（mailserver）、简单邮件传输协议（SimpleMailTransferProtocol，SMTP）。
用户代理允许用户阅读、回复、转发、保存和撰写报文。但A完成邮件撰写时，他的邮件代理向其邮件服务器发送邮件，并且该邮件被放在邮件服务器发送报文队列中。当B想读取一条报文（一封电子邮件）时，其邮件代理从他的位于邮件服务器的邮箱中获取该报文。
邮件服务器组成了电子邮件体系结构的核心。每个接收方在其中的某个服务器上有一个邮箱（mailbox）。一个典型的邮件发送过程是：从发送方的用户代理开始，传输到发送方的邮件服务器，再传输到接收方的邮件服务器，然后在这里被分发到接收方的邮箱中。
SMTP是因特网电子邮件中主要的应用层协议。它使用TCP可靠数据传输服务，从发送方的邮件服务器向接收方的邮件服务器发送邮件。SMTP也有两个部分：运行在发送方邮件服务器的客户机端和运行在接收方邮件服务器的服务器端。
2.4.1SMTP
SMTP历史悠久，因此它具有一些‘陈旧’的东西。例如，它限制所有邮件报文的主体部分只能采用简单的7位ASCII码表示。在20世纪80年代早期，因为当时带宽不足，没有人会通过电子邮件发送大的附件或大的图片、声音、视频文件。然而在今天的多媒体时代，7位ASCII码的限制就很痛苦，在用SMTP传送邮件之前，需要将二进制多媒体数据编码为ASCII码，并且在使用SMTP传输后需要将相应的ASCII码邮件解码还原为多媒体数据。
为了描述SMTP的基本操作，假设A想给B发送一封简单的ASCII报文（邮件）。
A调用他的邮件代理程序并提供B的邮件地址，撰写邮件，然后通过用户代理发送该邮件。
A的用户代理把报文发给A的邮件代理服务器，在那里该报文被放在发送队列中。
运行在A邮件服务器上的SMTP客户机端发现了报文发送队列中的这个报文，它就创建一个运行在B的邮件服务器上的SMTP服务器的TCP连接
在经过一些初始SMTP握手后，SMTP客户机通过该TCP连接发送A的报文。
在B的邮件服务器上，SMTP的服务器端接收该报文，B的邮件服务器然后将该报文放入B的邮箱中。
在B方便的时候，他调用用户代理阅读该报文。
SMTP一般不使用中间邮件服务器发送邮件，即使这两个邮件服务器位于地球的两端也是这样。假设A的邮件服务器在中国，而B的邮件服务器在美国，那么这个TCP连接也是从中国到美国服务器之间的直接相连。假如B的邮件服务器没有开机，该报文会保留在A的邮件服务器上并在稍后进行新的尝试。
使用SMTP将一个报文从发送邮件服务器传送到接收邮件服务器的过程：首先，SMTP客户机（运行在发送邮件服务器上）在25号端口上建立一个到SMTP服务器（运行在接收邮件服务器上）的TCP连接。如果某服务器没有开机，客户机会在稍后继续尝试连接。一旦连接建立，服务器和客户机就执行一些应用层的握手，就像人们在互相交流前先进行自我介绍一样。SMTP的客户机和服务器再传输信息前先相互介绍。在SMTP握手的阶段，SMTP客户机指明发送方的邮件地址和接收方的邮件地址。一旦该SMTP客户机和服务器彼此介绍之后，客户机就发送该报文。SMTP可以利用TCP提供的可靠数据传输无差错地将邮件投递到接收服务器。该客户机如果有另外的报文要发送到该服务器，就在该相同的TCP连接上重复这种处理；否则，它指示TCP关闭连接。SMTP使用的是持久连接。
2.4.2与HTTP的对比
两者的区别：第一，HTTP主要是一个拉协议（pullprotocol），也就是说用户使用HTTP从该服务器拉取信息。特别是，TCP连接是由想获取文件的机器发起的。SMTP基本上是一个推协议（pushprotocol），即发送邮件服务器把文件推向接收邮件服务器，特别是，这个TCP连接是由要发送文件的机器发起的。第二，SMTP要求每个报文（包括主体）都使用7位ASCII码格式。如果某报文包含了非7位ASCII字符或二进制数据（如图形文件），则该报文必须按照7位ASCII码进行编码。HTTP数据则没有这个限制。第三个区别在于如何处理一个既包含文本又包含图形的文档，HTTP把每个对象封装到它自己的HTTP响应报文中，而因特网电子邮件则把所有报文对象放在一个报文之中。
2.4.3邮件报文格式和MIME
当A向B写一封普通邮件时，他可能要在信的上部包含所有各种环境首部信息，如B的地址，他自己的回复地址以及日期等。同样。当从一个人给另一个人发送电子邮件时，在报文主体前面也附有环境信息。这些环境信息包括在一系列首部行中，这些行由[RFC822]定义。如同HTTP协议，每个首部行都包含了可读的文本，它们是由关键词后跟冒号再后跟值组成的。某些关键词是必须的，某些是可选的。每个首部都必须含有一个From:首部行和一个To:首部行，可以包含一个Subject:首部行或其它可选的首部行。一个典型的报文首部如下：
From:alice@crepes.fr
To:bob@hanburger.edu
Subject:Searchingforthemeaningoflife.
在报文首部之后，紧接着是一个空白行，然后是以ASCII格式表示的报文主体。
虽然在[RFC822]中描述的报文首部适合于发送普通ASCII文本，但它们不能充分地满足多媒体报文或携带有非ASCII文本格式（非英语语言的字符）的报文的需求。为发送非ASCII文本的内容，发送方的用户代理必须在报文中使用附加的首部行。这些额外的首部行定义在[RFC2045]和[RFC204]6中，多用途因特网邮件扩展（MultipurposeInternetMailExtension，MIME）是对[RFC822]的扩展。
支持多媒体的两个关键MIME首部是Content-Type:和Content-Transfer-Encoding:。Content-Type:首部允许接收用户代理对报文采取适当的动过。例如，通过支持报文主体包含一个JPEG图形，接收用户代理可以为报文主体启用一个JPEG图形的解压缩程序。为什么需要Content-Transfer-Encoding:首部行，为了不致扰乱SMTP的正常工作，非ASCII报文必须编码成ASCII格式。Content-Transfer-Encoding:首部行提示接收用户代理该报文主体已经使用了ASCII编码，并指出了所有的编码类型。因此，当用户代理接收到包含这两个首部行的报文时，就会根据Content-Transfer-Encoding:的值将报文主体还原成非ASCII的格式，然后根据Content-Type:首部行决定它应当采取何种动作来处理报文主体。
我们看一个例子。假设A想发送一个JPEG图形给B。为此，A调用他的电子邮件用户代理，指定B的地址，定义该报文的主题，并在该报文主体中插入该JPEG图形。写完他的报文后，A点击‘发送’。A的用户代理则产生了一个MIME报文，该报文看起来具有如下形式：
From:alice@crepes.fr
To:bob@hamburger.edu
Subject:Pictureofyummycrepe.
MIME-Version:1.0
Content-Transfer-Encoding:base64
Content-Type:image/jpeg
(base64encodeddata…..
………………………….
…..base64encodeddata)
从上述MIME报文可以看到，A的用户代理使用base64编码对该JPEG图形进行了编码。这是在MIME[RFC2045]中标准化的几种编码技术之一，用于转换为可接受的7位ASCII码格式。另外一个流行的编码技术是引用可打印内容转换编码（quoted-printablecontent-transfer-encoding），该编码常用于将一个8位ASCII转换为7位ASCII码格式。
当B用他的用户代理阅读该邮件时，他的用户代理对相同的MIME报文进行操作。当B的用户代理发现了Content-Transfer-Encoding:base64首部行时，它会对base64编码的报文主体执行解码操作。该报文同时包含Content-Type:image/jpeg首部行，用于提示B的用户代理程序，该报文主体应当进行JPEG文件解压缩。最后该报文中包含MIME-Version:首部行，它用于指出MIME的版本号。该报文的其它部分遵从[RFC822]格式，在报文首部后有一个空白行，接下来是报文主体。
接收服务器一旦接收到具有RFC822和MIME首部行的报文，就在该报文的顶部添加一个Received:首部行，该首部行定义了发送该报文的SMTP服务器的名称（from），接收该报文的SMTP服务器的名称（by），以及接收服务器接收到的时间。目的用户看到的邮件具有如下所示的格式：
Recived:fromcrepes.frbyhamburger.edu;12Oct98
15:27:39GMT
From:alice@crepes.fr
To:bob@hamburger.edu
Subject:Pictureofyummycrepe.
MIME-Version:1.0
Content-Transfer-Encoding:base64
Content-Type:image/jpeg
Base64encodeddata…….
…………………………………..
……base64encodeddata
几乎每个用过电子邮件的用户都在电子邮件报文的前面看到过Received:首部行。一个邮件有时有多个Received:行和一个更为复杂的Return-Path:首部行。这是因为有的邮件在发送方和接收方之间的路径上要经过不止一个SMTP服务器转发。
2.4.4邮件访问协议
一旦SMTP将邮件报文从A的邮件服务器交付给B的邮件服务器，该报文就被放入了B得邮箱中。在20世纪90年代早期，登录到服务器主机并直接在该主机上运行一个邮件阅读程序来阅读他的邮件是一种标准方式。而在今天，邮件访问使用了一种客户机/服务器体系结构，即用户一般通过在端系统上运行一个用户代理来阅读电子邮件，这里的端系统可能是电脑、笔记本、手机。
假设接收方在他的本地电脑上运行用户代理程序，我们自然而然地也可以考虑在他的本地电脑上放置一个邮件服务器。在这种情况下A的邮件服务器就直接与B的本地电脑进行对话。然而这样会带来一个问题，邮件服务器管理用户的邮箱，并且运行SMTP的客户机和服务器端。如果B的邮件服务器位于他的电脑上，那么为了能够及时接收到可能在任何时候到达的新的邮件，他的电脑必须总是不间断地运行着并一直保持在线。这对于大多数因特网用户是不现实的。通常用户在本地运行一个用户代理程序，而它访问位于共享邮件服务器上的邮箱，该共享邮件服务器总是保持开机并一直保持在线。
接收方是如何通过运行在他本地电脑上的用户代理，获得邮件服务器上的邮件呢？接收方的用户代理不能使用SMTP取回邮件，因为取邮件是一个拉操作，而SMTP协议时一个推协议。因此，通过一个邮件访问协议将接收方邮件服务器上的邮件传给他的本地电脑。目前流行的邮件访问协议有：第三版的邮局协议（PostOfficeProtocol-Version3，POP3）、因特网邮件访问协议（InternetMailAccessProtocol，IMAP）以及HTTP。
POP3是一个非常简单的邮件访问协议，由[RFC1939]定义。因为协议简单，故其功能相当有限。
当用户代理打开了一个邮件服务器端口110上的TCP连接后，POP3就开始工作了。随着TCP连接的创建，POP3按照三个阶段进行工作：特许、事务处理以及更新。
在第一个特许阶段，用户发送用户名和口令以鉴别用户。在第二阶段，用户代理取回报文，并能进行如下操作：对报文做删除标记，取消报文删除标记，以及获取邮件的统计信息。在第三阶段，它出现在客户机发出了quit命令之后，目的是结束该POP3会话，这时邮件服务器删除那些被标记为删除的报文。
在POP3的事物处理过程中，用户代理发出一些命令，服务器对每个命令做出回答。回答可能有两种：+OK（有时后面还跟有服务器到客户机的数据），服务器用它来指示前面的命令是正常的；-ERR，服务器用它来指示前面的命令出现了某些差错。
特许阶段有两个主要命令：user和pass
使用POP3的用户代理通常由用户配置为‘下载并删除’或者‘下载并保留’方式。第一种方式带来这样一个问题：邮件接收方可能是移动的，希望从多个不同的端系统访问他的邮件报文，如办公室电脑、家里的电脑或手机来访问邮件。如果接收方最先在办公室电脑上收取了一个邮件，那么晚上他在家里时通过他家的电脑将不能再次收取该邮件。而使用第二种方式，用户代理下载某邮件后，该邮件仍保留在邮件服务器上，这时接收方可以通过不同的端系统重新读取这些邮件
使用POP3访问时，一旦接收方将邮件下载到本地主机后，他能建立邮件文件夹，并且将下载的邮件放入该文件夹中。然后，可以删除报文，在文件夹间移动报文，也可以查询报文。但这种文件夹和报文存放在本地主机上的方法，会给移动用户带来问题，因为他更喜欢使用一个远程服务器上的层次文件夹，这样他可以从任何一个端系统上对所有报文进行访问，POP3不能做到这一点，它没有给用户提供任何创建远程文件夹以及为报文指派文件夹的方法。
为了解决这个或其它一些问题，由RFC3501定义的因特网邮政访问协议IMAP应运而生。IMAP比POP3具有更多的特色，也复杂得多。
IMAP服务器把每个报文与一个文件夹联系起来，当报文第一次到达服务器时，它是放在收件人的收件箱文件夹里。收件人可以把邮件移到一个新的、用户创建的文件夹中，或阅读、删除邮件等。IMAP协议为用户提供了创建文件夹以及在文件夹之间移动邮件的命令。IMAP还为用户提供了再远程文件夹中查询邮件的命令，按指定条件去查询匹配的邮件。与POP3不同的是，IMAP服务器维护了IMAP会话的用户状态信息，例如，文件夹的名字以及哪个报文与哪个文件夹相关联。
IMAP另一个重要特性是它具有允许用户代理获取报文组件的命令。例如，用户代理可以只读取一个报文的报文首部，或只是一个多方MIME报文的一部分。在用户代理和其邮件服务器之间使用低带宽连接的时候，这个特性非常有用。
如今大部分用户使用他们的Web浏览器收发电子邮件。20世纪90年代中期，Hotmail引入了基于Web的访问。使用这种服务，用户代理就是普通浏览器，用户和其远程邮箱之间的通信则通过HTTP进行。当一个收件人想从他的邮箱中收取一个报文时，该电子邮件报文从他的邮件服务器发送到他的浏览器，使用的是HTTP而不是POP3或IMAP。当发件人要发送一封电子邮件报文时，该电子邮件报文从他的浏览器发送到他的邮件服务器，使用的是HTTP而不是SMTP。然而，他的邮件服务器与其它邮件服务器之间发送和接收邮件时，仍然使用SMTP。
|
|
