TCP/IP详解卷一 SMTP：简单邮件传送协议

SMTP：简单邮件传送协议

概述

所有TCP连接中大约一半是用于简单邮件传送协议 SMTP (Simple Mail Transfer Protocol)的（以比特计算为基础，FTP连接传送更多的数据）。平均每个邮件中包含大约1500字节的数据，但有的邮件中包含兆比特的数据，因为有时电子邮件也用于发送文件。

下图显示了一个用TCP/IP交换电子邮件的示意图：

用户与用户代理（ user agent）打交道，可能会有多个用户代理可供选择。常用的Unix上的用户代理包括MH，Berkeley Mail, Elm和Mush。

用TCP进行的邮件交换是由报文传送代理MTA（Message Transfer Agent）完成的。最普通的Unix系统中的MTA是Sendmail。用户通常不和MTA打交道，由系统管理员负责设置本地的MTA。通常，用户可以选择它们自己的用户代理。

SMTP协议

两个MTA之间用NVT ASCII进行通信。客户向服务器发出命令，服务器用数字应答码和可选的人可读字符串进行响应。

客户只能向服务器发送很少的命令：不到12个（相比较而言，FTP超过40个）。

SMTP命令

最小的SMTP实现支持8种命令：
- HELO：HELO命令标示自己。参数必须是完全合格的的客户主机名。
- MAIL：MAIL命令标识出报文的发起人。
- RCPT：标识接收方。如果有多个接收方，可以发多个RCPT命令。
- DATA：邮件报文的内容由客户通过DATA命令发送。报文的末尾由客户指定，是只有一个句点的一行。
- QUIT：结束邮件的交换。
- RSET：异常中止当前的邮件事务并使两端复位。丢掉所有有关发送方、接收方或邮件的存储信息。
- VRFY：使客户能够询问发送方以验证接收方地址，而无需向接收方发送邮件。通常是系统管理员在查找邮件交付差错时手工使用的。
- NOOP：该命令除了强迫服务器响应一个OK应答码（200）外，不做任何事情。
还有附加和可选命令。EXPN扩充邮件表，与VRFY类似，通常是由系统管理员使用的。TURN命令使客户和服务器交换角色，无需拆除 TCP连接并建立新的连接就能以相反方向。发送邮件（Sendmail不支持这个命令）。其他还有三个很少被实现的命令（SEND、SOML和SAML）取代MAIL命令。这三个命令允许邮件直接发送到客户终端（如果已注册）或发送到接收方的邮箱。
信封、首部和正文

电子邮件由三部分组成：
1. 信封（envelope）是MTA用来交付的。
2. 首部由用户代理使用。以X-开始的首部字段是用户定义的字段。长首部字段被折在几行中，多余行以空格开头。
3. 正文（body）是发送用户发给接收用户报文的内容。 RFC 822 指定正文为NVT ASCII文字行。当用DATA命令发送时，先发送首部，紧跟一个空行，然后是正文。用DATA命令发送的各行都必须小于1000字节。
用户接收我们指定为正文的部分，加上一些首部字段，并把结果传到MTA。MTA加上一些首部字段，加上信封，并把结果发送到另一个MTA。
内容（content）通常用于描述首部和正文的结合。内容是客户用DATA命令发送的。
中继代理

中继系统在本地域中有一个主机名，而其他所有系统都被配置成把它们的邮件发往该主机。如果将来用于中继的主机改变了，只需改变它的DNS名—其他所有单个系统的邮箱配置都无需改变。

下图是修改后的Internet邮件图：

在图中情况下，在发送方和接收方之间有 4个MTA。发送方主机上的本地MTA只把邮件交给它自己的中继MTA。这个通信就在该机构的本地互联网上用SMTP。然后，发送方机构的中继MTA就在Internet上把邮件发送到接收方机构的中继MTA上，而这个中继 MTA就通过与接收方主机上的本地MTA通信，把邮件交给接收方主机。尽管可能存在其他协议，但这个例子中所有MTA均使用SMTP协议。
NVT ASCII

SMTP的一个特色是它用 NVT ASCII表示一切：信封、首部和正文。

Internet邮件的一些新特性、允许发送和接收诸如音频和视频数据的扩充S M T P和多媒体邮件（MIME）。MIME和NVT ASCII一起表示信封、首部和正文，只需对用户代理作一些改变。
重试间隔

当用户把一个新的邮件报文传给它的MTA时，通常立即试图交付。如果交付失败，MTA必须把该报文放入队列中以后再重试。

SMTP的未来

Internet邮件的三个组成部分：信封、首部和正文。新加入的SMTP命令影响了信封，首部中可以使用非ASCII字母，正文（MIME）中也加入了结构。

信封的变化：扩充的SMTP

RFC 1425定义了扩充的SMTP的框架，其结果被称为扩充的SMTP（ESMTP）。这些变化以向后兼容的方式被加入，所以不影响已有的实现。

如果客户想使用新的特性，首先通过发布一个EHLO而不是HELO命令启动一个与服务器的会话。相兼容的服务器用 2 5 0应答码响应。
首部变化：非ASCII字符

首部字段中可以包含编码字 (coded word)。它们具有以下格式：
1
=?charset?encoding?encoded-text? =
charset是字符集规范。有效值是两个字符串us-ascii和iso-8859-x，其中x是一个单个数字，例如在iso-8859-1中的数字“1”。

encoding是一个单个字符用来指定编码方法，支持两个值：
- Q编码意思是引号中可打印的（quoted-printable），目的是用于拉丁字符集。大多数字符是作为NVT ASCII（当然最高位比特置 0）发送的。任何要发送的字符若其第 8比特置1则被作为3个字符发送：第1个是字符是“=”，跟着两个十六进制数。例如，字符é （它的二进制 8b i t值为0xe9）作为三个字符发送： =E9。空格通常作为下划线或三个字符 = 2 0发送。这种编码的目的在于，某些文本中除了大多数ASCII字符外，还有几个特殊字符。
- B意思是以64为基数的编码。文本中的3个连续字节（24bit）被编码成4个6bit值。用于表示所有可能的 6bit值的64个NVT ASCII字符如下图所示。当要编码的个数不是3的倍数时，等号符“=”被用作填充符。
正文变化：通用Internet邮件扩充

正文是NVT ASCII文本行，没有结构。RFC 1521把扩充定义为允许把结构置入正文。这被称为MIME，即用Internet邮件扩充。

MIME不要求任何扩充，MIME正好加入了一些告知收件者正文结构的新标题。正文仍可以用NVT ASCII码来发送，而不考虑邮件内容。一些扩充可能会和MIME合在一起产生好的效果—扩充的SMTP SIZE命令，因为MIME报文能变得很长，以及非ASCII标题—这些扩充并不是MIME所要求的。与另一方交换MIME报文所需的一切，就是双方都要有一个能够理解MIME的用户代理。在任何一个MTA中不需要做任何改变。
下图总结了RFC 1521中定义的16个不同的内容类型和子类型：

内容类型和用于内容的传送编码是相互独立的。前者由首部字段Content-Type指明，后者由首部字段Content-Transfer-Encoding指明。有5种不同的编码格式：
1. 7bit，是默认的NVT ASCII
2. quoted-printable。当字符中只有很少一部分的第8 bit置1时非常有用；
3. base64，如下图所示：
4. 8bit，包含字符行，其中某些为非ASCII字符且第8bit置1；
5. binary编码，无需包含多行的8 bit数据。
对RFC 821 MTA，以上5种编码格式中只有前 3种是有效的。因为这 3种产生只包含NVT ASCII字符的正文。使用有8BITMIME支持的扩充SMTP允许使用8bit编码。

尽管内容类型和编码是独立的， RFC 1521推荐有非ASCII数据的text使用quoted-printable，而image、audio、video和octet-stream application使用base64。这样允许与符合 RFC 821的MTA保持最大的互操作性。而且，multipart和message内容类型必须以7bit编码。

作为一个multipart内容类型的例子，子类型是mixed，意思是各部分是顺序处理的，各部分的边界是字符串NextPart，其前面是行首的两个连字符。

每个边界上可跟一行用于指明下一部分首部字段。忽略报文中第 1个边界之前和最后一个边界之后的所有内容。