28.1 引言
电子邮件( e - mail)无疑是最流行的应用程序。
[Caceres et al.1991]说明,所有TCP连接中大约一半是用于简单邮件传送协议SMTP
(Simple Mail Transfer Protocol)的(以比特计算为基础,FTP连接传送更多的数据)。
[Paxson 1993] 发现,平均每个邮件中包含大约1 5 0 0字节的数据,
但有的邮件中包含兆比特的数据,因为有时电子邮件也用于发送文件。
用户与用户代理( user agent)打交道,可能会有多个用户代理可供选择。
常用的U n i x上的用户代理包括M H,Berkeley Mail, Elm和M u s h。
用TCP进行的邮件交换是由报文传送代理MTA(Message Transfer Agent)完成的。
最普通的U n i x系统中的MTA是Send mail。用户通常不和MTA打交道,由系统管理员负责设置本地的MTA。
通常,用户可以选择它们自己的用户代理。本章研究在两个MTA之间如何用TCP交换邮件。
我们不考虑用户代理的运行或实现。RFC 821规范了SMTP协议,指定了在一个简单TCP连接上,两个MTA如何进行
通信。RFC 822 [Crocker 1982] 指定了在两个MTA之间用RFC 821 发送的电子邮件报文的格式。
28.2 SMTP协议
两个MTA之间用NVT ASCII进行通信。
客户向服务器发出命令,服务器用数字应答码和可选的人可读字符串进行响应。
客户只能向服务器发送很少的命令：不到1 2个(相比较而言, FTP超过4 0个)。
我们用简单的例子说明发送邮件的工作过程,并不仔细描述每个命令。
28.2.1 简单例子
我们将发送一个只有一行的简单邮件,并观察SMTP连接。
我们用-v 标志调用用户代理,它被传送给邮件传送代理(本例中是Send mail)。
当设置该标志时,该MTA显示在SMTP连接上发送和接收的内容。
只有5个SMTP命令用于发送邮件： HELO,mail,RCTP,DATA和QUIT。
我们键入mail启动用户代理,然后键入主题( subject)的提示；键入后,再键入报文的正文。
在一行上键入一个句点结束报文,用户代理把邮件传给MTA,由MTA进行交付。
客户主动打开TCP端口2 5。
返回时,客户等待从服务器来的问候报文(应答代码为2 2 0)。
该服务器的应答必须以服务器的完全合格的域名开始：本例中为noao.edu。
下一步客户用HELO命令标识自己。
参数必须是完全合格的的客户主机名： sun.tuc.noao.edu。mail命令标识出报文的发起人。
下一个命令, RCPT,标识接收方。如果有多个接收方,可以发多个RCPT命令。
邮件报文的内容由客户通过DATA命令发送。
报文的末尾由客户指定,是只有一个句点的一行。
最后的命令QUIT,结束邮件的交换。
28.2.2 SMTP命令
最小SMTP实现支持8种命令。我们在前面的例子中遇到5个： HELO,mail,RCPT,DATA和QUIT。
R S E T命令异常中止当前的邮件事务并使两端复位。
丢掉所有有关发送方、接收方或邮件的存储信息。
V R F Y命令使客户能够询问发送方以验证接收方地址,而无需向接收方发送邮件。
通常是系统管理员在查找邮件交付差错时手工使用的。
我们将在下一节中给出这方面的例子。
N O O P命令除了强迫服务器响应一个O K应答码(2 0 0)外,不做任何事情。
还有附加和可选命令。EXPN扩充邮件表,与V R F Y类似,通常是由系统管理员使用的。
事实上,许多Send mail的版本都把这两者等价地处理。
4.4BSD 中的Send mail版本8不再将两者等同处理。V R F Y不扩充别名也不接受.forward文件。
T U R N命令使客户和服务器交换角色,无需拆除TCP连接并建立新的连接就能以相反方向发送邮件( Send mail不支持这个命令)。
其他还有三个很少被实现的命令( Send、S O M L和S A M L)取代mail命令。
这三个命令允许邮件直接发送到客户终端(如果已注册)或发送到接收方的邮箱。
28.2.3 信封、首部和正文
电子邮件由三部分组成：
1) 信封(envelope)是MTA用来交付的。在我们的例子中信封由两个SMTP命令指明：
MAIL From: <rstevens@sun.tuc.noao.edu>
RCPT To: <estevens@noao.edu>
RFC 821指明了信封的内容及其解释,以及在一个TCP连接上用于交换邮件的协议。
2) 首部由用户代理使用。在我们的例子中可以看到9个首部字段： Received、
Message-Id、From、Data、Reply-To、X-Phone、X-mailer、To和Subject。
每个首部字段都包含一个名,紧跟一个冒号,接着是字段值。
RFC 822指明了首部字段的格式的解释(以X-开始的首部字段是用户定义的字段,其他是由RFC 822定义的)。
长首部字段,如例子中的Received,被折在几行中,多余行以空格开头。
3) 正文(b o d y)是发送用户发给接收用户报文的内容。
RFC 822 指定正文为NVT ASCII文字行。当用DATA命令发送时,先发送首部,紧跟一个空行,然后是正文。
用DATA命令发送的各行都必须小于1 0 0 0字节。
用户接收我们指定为正文的部分,加上一些首部字段,并把结果传到MTA。
MTA加上一些首部字段,加上信封,并把结果发送到另一个MTA。
内容(Content)通常用于描述首部和正文的结合。
内容是客户用DATA命令发送的。
28.2.4 中继代理
在我们的例子中本地MTA的信息输出的第1行是：“Connecting to mailhost via ether”。
这是因为作者的系统已被配置成把所有非本地的向外的邮件发送到一台中继机上进行转发。
这样做的原因有两个。
第一,简化了除中继系统MTA外的其他所有MTA的配置(所有曾使用过Send mail的人都能证明,配置一个MTA并不简单)。
第二,它允许某个机构中的一个系统作为邮件集线器,从而可能把其他所有系统隐藏起来。
如果将来用于中继的主机改变了,只需改变它的DNS名—其他所有单个系统的邮箱配置都无需改变。
在这种情况下,在发送方和接收方之间有4个MTA。
发送方主机上的本地MTA只把邮件交给它自己的中继MTA(该中继MTA可能在该机构的域中有一个mail host的主机名)。
这个通信就在该机构的本地互联网上用SMTP。
然后,发送方机构的中继MTA就在Internet上把邮件发送到接收方机构的中继MTA上,
而这个中继MTA就通过与接收方主机上的本地MTA通信,
把邮件交给接收方主机。尽管可能存在其他协议,但这个例子中所有MTA均使用SMTP协议。
28.2.6 重试间隔
当用户把一个新的邮件报文传给它的MTA时,通常立即试图交付。
如果交付失败, MTA必须把该报文放入队列中以后再重试。
Host Requirements RFC推荐初始时间间隔至少为3 0分钟。发送方至少4 ~ 5天内不能放弃。
因为交付失败通常是透明的(接收方崩溃或临时网络连接中断),
所以当报文在队列中等待的第1个小时内,尝试两次连接是有意义的。
28.4 SMTP的未来
Internet邮件发生了很多改变。
应当记得Internet邮件的三个组成部分：信封、首部和正文。
新加入的SMTP命令影响了信封,首部中可以使用非ASCII字母,正文( MIME)中也加入了结构。
本节中我们依次对这三部分的扩充进行讨论。
RFC 1425 [Klensin等,1993a] 定义了扩充的SMTP的框架,其结果被称为扩充的SMTP(ESMTP)。
与其他我们已经讨论过的新特性一样,这些变化以向后兼容的方式被加入,所以不影响已有的实现。
如果客户想使用新的特性,首先通过发布一个E H L O而不是HELO命令启动一个与服务器的会话。
相兼容的服务器用2 5 0应答码响应。这个应答通常有好几行,每行都包含一个关键字和一个可选的参数。
这些关键字指定了该服务器支持的SMTP扩充。新的扩充将在一个R F C中描述并以I A N A注册。
28.4.2 首部变化：非ASCII字符
RFC 1522 [Moore 1993] 指明了一个在RFC 822报文首部中如何发送非ASCII字符的方法。
这样做的主要用途是为了允许在发送方名、接收方名以及主题中使用其他的字符。
首部字段中可以包含编码字(coded word)。
它们具有以下格式：= ?charset?encoding?encoded - text? =charset是字符集规范。
有效值是两个字符串us -ASCII和iso-8859-x,其中x 是一个单个数字,
例如在iso-8859 - 1中的数字“ 1”。
encoding是一个单个字符用来指定编码方法,支持两个值。
1) Q编码意思是引号中可打印的(quoted-printable),目的是用于拉丁字符集。
大多数字符是作为NVT ASCII(当然最高位比特置0)发送的。
任何要发送的字符若其第8比特置1则被作为3个字符发送：第1个是字符是“=”,跟着两个十六进制数。
例如,字符é(它的二进制8b i t值为0 x e 9)作为三个字符发送： = E 9。空格通常作为下划线或三个字符= 2 0发送。
这种编码的目的在于,某些文本中除了大多数ASCII字符外,还有几个特殊字符。
2) B意思是以6 4为基数的编码。文本中的3个连续字节( 2 4 b i t)被编码成4个6 bit值。
28.4.3 正文变化：通用Internet邮件扩充我们已经提到RFC 822指定正文是NVT ASCII文本行,没有结构。
RFC 1521 [Borenstein和Freed 1993] 把扩充定义为允许把结构置入正文。
这被称为MIME,即通用Internet邮件扩充。
MIME不要求任何扩充,我们在本节前面已作了说明(扩充的SMTP或非ASCII标题)。
MIME正好加入了一些告知收件者正文结构的新标题(与RFC 822相一致)。
正文仍可以用NVT ASCII码来发送,而不考虑邮件内容。
虽然我们前面所述的一些扩充可能会和MIME合在一起产生好的效果—扩充的SMTP SIZE命令,
因为MIME报文能变得很长,以及非ASCII标题—这些扩充并不是MIME所要求的。
与另一方交换MIME报文所需的一切,就是双方都要有一个能够理解MIME的用户代理。
在任何一个MTA中不需要做任何改变。
MIME定义这5个新标题字段如下：
MIME - Version :
Content - Type :
Content - Transfer- Encoding :
Content - ID :
Content - Description :
作为例子,下面两个标题行可以出现在一个Internet邮件报文中：
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
当前MIME版本是1 . 0,内容类型是无格式ASCII码文本,即Internet邮件的默认选择。
P L A I N这个字被认为是内容类型( T E X T)的一个子类型,字符串charset = US-ASCII是一个参数。
Te x t是MIME的7个被定义的内容类型之一。
内容类型和用于内容的传送编码是相互独立的。
前者由首部字段Content - Ty p e指明,后者由首部字段Content - Transfer-Encoding指明。
在RFC 1521中定义了5种不同的编码格式。
1) 7bit,是默认的NVT ASCII；
2) quoted-printable,我们在前面的一个例子中看到有非ASCII首部。
当字符中只有很少一部分的第8 bit 置1时非常有用；
3) base64,如图2 8 - 6所示；
4) 8bit,包含字符行,其中某些为非ASCII字符且第8 b i t置1；
5) binary编码,无需包含多行的8 bit数据。
对RFC 821 MTA,以上5种编码格式中只有前3种是有效的。
因为这3种产生只包含N V TASCII字符的正文。使用有8 B I T MIME支持的扩充SMTP允许使用8 b i t编码。
尽管内容类型和编码是独立的, R F C 1 5 2 1推荐有非ASCII数据的t e x t使用q u o t e d - p r i n t a b l e,
而image、a u d i o、v i d e o和octet-stream application 使用base64。
这样允许与符合RFC 821的MTA保持最大的互操作性。
而且, m u l t i p a r t和m e s s a g e内容类型必须以7 b i t编码。
这一部分是MIME的一个简要概述。
MIME的详细细节和例子,见RFC 1521 和[ R o s e1 9 9 3 ]。
28.5 小结
电子邮件包括在两端(发送方和接收方)都有的一个用户代理以及两个或多个报文传送代理。
可以把一个邮件报文分成三个部分：信封、首部和正文。
我们已经看到这三个部分用SMTP和Internet标准是如何进行交换的。
所有都作为NVT ASCII字符进行交换。
我们也看到了一些新的扩充：用于信封和非ASCII首部的扩充SMTP,以及使用MIME的
正文增加了结构。MIME的结构和编码允许使用已有的7bit SMTP MTA交换任意二进制数据。
习题
28.1 读RFC 822,找到域文字(domain literal)的意思。试试用其中一个给自己发送邮件。
28.2 除了连接建立和终止外,要发送一个小的邮件报文的最小网络往返次数是多少？
28.3 TCP是一个全双工协议,但是SMTP用半双工的形式使用TCP。客户发送一个命令后停
止等待应答。为什么客户不一次发送多个命令,如一行中包括HELO、mail、RCPT、
DATA和QUIT命令(假定正文不是太大)？
28.4 当网络在接近其容量运行时, SMTP的这种半双工操作如何欺骗缓慢的启动机制？
28.5 当存在多个具有相同优先值的M X记录时,名服务器是否总能以相同的顺序返回它们？