第28章 SMTP: 简单邮件传送协议
28.4 SMTP的未来
I n t e r n e t邮件发生了很多改变。应当记得 I n t e r n e t邮件的三个组成部分：信封、首部和正文。新加入的S M T P命令影响了信封，首部中可以使用非 A S C I I字母，正文（M I M E）中也加入了结构。本节中我们依次对这三部分的扩充进行讨论。
28.4.1 信封的变化：扩充的SMTP
RFC 1425 [Klensin等，1993a] 定义了扩充的 S M T P的框架，其结果被称为扩充的 S M T P（E S M T P）。与其他我们已经讨论过的新特性一样，这些变化以向后兼容的方式被加入，所以不影响已有的实现。
如果客户想使用新的特性，首先通过发布一个 E H L O而不是H E L O命令启动一个与服务器的会话。相兼容的服务器用 2 5 0应答码响应。这个应答通常有好几行，每行都包含一个关键字和一个可选的参数。这些关键字指定了该服务器支持的 S M T P扩充。新的扩充将在一个 R F C中描述并以I A N A注册（在一个多行应答中，各行数字应答码的后面都要有一个连字符。最后一 行的数字应答码后面跟一个空行）。
我们将给出到 4个S M T P服务器的初始连接，其中 3个支持扩充的 S M T P。我们用Te l n e t和它们连接，但删掉了不必要的 Te l n e t客户输出。
这个服务器用一个多行2 2 0应答作为它的欢迎报文。对 E H L O命令的2 5 0应答中列出的扩充命令是E X P N、S I Z E和H E L P。第一个和最后一个来自原来的 RFC 821规范，但它们是可选命令。E S M T P服务器说明除了新命令外，它们还支持哪些可选的 RFC 821命令。
这个服务器支持的S I Z E关键字是在RFC 1427 [Klensin, Freed和Moore 1993] 中定义的。它让客户在MAIL FROM命令行中以字节的多少指定报文的大小，这样服务器就可以在客户开始发送该报文之前，验证它是否接收该长度的报文。增加这个命令的原因在于，随着对非 A S C I I码（如图像、音频等）内容的支持， I n t e r n e t邮件报文的长度在不断增大。
下一个主机也支持 E S M T P，注意2 5 0应答指明支持包含一个可选参数的 S I Z E关键字。这表明该服务器将接受长度不超过 4 6 1兆字节的报文。
关键字8 B I T M I M E来自于RFC 1426 [Klensin等，1 9 9 3 a ]。它允许客户把关键字B O D Y加到MAIL FROM命令中，指定正文中是否包含 NVT ASCII字符（默认的）或8 bit数据。除非客户收到服务器应答E H L O命令发来的8 B I T M I M E关键字，否则禁止客户发送任何非 NVT ASCII字符（当我们在本节中谈到M I M E时，我们将看到M I M E不要求8 bit传送）。
该服务器也通告了X A D R关键字。任何以X开头的关键字都指的是本地 S M T P扩充。另一个服务器也支持 E S M T P，通知了我们已经看到的 H E L P和S I Z E关键字。它也支持三个以X开头的本地扩充。
最后，我们将看到当客户试图通过向一个不支持 E H L O的服务器发布 E H L O命令来使用E S M T P时将发生什么。
对E H L O命令，客户收到一个 5 0 0应答而不是2 5 0应答。客户应发布 R S E T命令，并跟着一个H E L O命令。
28.4.2 首部变化：非ASCII字符
RFC 1522 [Moore 1993] 指明了一个在RFC 822报文首部中如何发送非A S C I I字符的方法。这样做的主要用途是为了允许在发送方名、接收方名以及主题中使用其他的字符。
首部字段中可以包含编码字 (coded word)。它们具有以下格式：
代码语言：javascript复制= ?c h a r s e t?e n c o d i n g?e n c o d e d - t e x t? =c h a r s e t是字符集规范。有效值是两个字符串 u s - a s c i i和i s o - 8 8 5 9 - x，其中x 是一个单个数字，例如在i s o - 8 8 5 9 - 1中的数字“1”。
e n c o d i n g是一个单个字符用来指定编码方法，支持两个值。
- Q编码意思是引号中可打印的（ q u o t e d - p r i n t a b l e），目的是用于拉丁字符集。大多数字符是作为NVT ASCII（当然最高位比特置0）发送的。任何要发送的字符若其第 8比特置1则被作为3个字符发送：第1个是字符是“=”，跟着两个十六进制数。例如，字符é（它的二进制 8b i t值为0 x e 9）作为三个字符发送： = E 9。空格通常作为下划线或三个字符 = 2 0发送。这种编码 的目的在于，某些文本中除了大多数 A S C I I字符外，还有几个特殊字符。
- B意思是以6 4为基数的编码。文本中的 3个连续字节（2 4 b i t）被编码成4个6 bit值。用于表示所有可能的 6 b i t值的6 4个NVT ASCII字符如图2 8 - 6所示。当要编码的个数不是 3的倍数时，等号符“=”被用作填充符。
下面两种编码方式的例子取自 RFC 1522：
能处理这些首部的用户代理将输出：.
为说明以6 4为基数的编码方法是如何工作的，我们看一下主题行中前面 4个编码的字符：S W Y g。按照图2 8 - 6写出这4个字符的6 bit值（S = 0 x 1 2 , W = 0 x 1 6 , Y = 0 x 1 8以及g = 0 x 2 0）的二进制码：
代码语言：javascript复制010010 010110 011000 100000然后把这24 bit重新分组成3个8 bit字节：
代码语言：javascript复制01001001 01100110 00100000
=0x49 =0x66 =0x20它们是I、f和空格的A S C I I表示。
28.4.3 正文变化：通用Internet邮件扩充
我们已经提到RFC 822指定正文是NVT ASCII文本行，没有结构。RFC 1521 [Borenstein和 Freed 1993] 把扩充定义为允许把结构置入正文。这被称为 M I M E，即通用I n t e r n e t邮件扩充。
M I M E不要求任何扩充，我们在本节前面已作了说明（扩充的 S M T P或非A S C I I标题）。M I M E正好加入了一些告知收件者正文结构的新标题（与 RFC 822相一致）。正文仍可以用NVT ASCII码来发送，而不考虑邮件内容。虽然我们前面所述的一些扩充可能会和 M I M E合在一起产生好的效果—扩充的SMTP SIZE命令，因为M I M E报文能变得很长，以及非 A S C I I标题—这些扩充并不是M I M E所要求的。与另一方交换 M I M E报文所需的一切，就是双方都要有一个能够理解M I M E的用户代理。在任何一个M TA中不需要做任何改变。M I M E定义这5个新标题字段如下：
代码语言：javascript复制M i m e - V e r s i o n :
C o n t e n t - T y p e :
C o n t e n t - T r a n s f e r - E n c o d i n g :
C o n t e n t - I D :
C o n t e n t - D e s c r i p t i o n作为例子，下面两个标题行可以出现在一个 I n t e r n e t邮件报文中：
代码语言：javascript复制Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII当前M I M E版本是 1 . 0，内容类型是无格式 A S C I I码文本，即 I n t e r n e t邮件的默认选择。P L A I N这个字被认为是内容类型（ T E X T）的一个子类型，字符串 c h a r s e t = U S - A S C I I是一个参数。
Te x t是M I M E的7个被定义的内容类型之一。图 2 8 - 7总结了RFC 1521中定义的1 6个不同的内容类型和子类型。对具体的内容类型和子类型来说都有指定的很多参数。
内容类型和用于内容的传送编码是相互独立的。前者由首部字段 C o n t e n t - Ty p e指明，后者由首部字段C o n t e n t - Tr a n s f e r- E n c o d i n g指明。在RFC 1521中定义了5种不同的编码格式。
- 7bit，是默认的NVT ASCII；
- quoted-printable，我们在前面的一个例子中看到有非 A S C I I首部。当字符中只有很少一部分的第8 bit置1时非常有用；
- base64，如图2 8 - 6所示；
- 8bit，包含字符行，其中某些为非 A S C I I字符且第8 b i t置1；
- binary编码，无需包含多行的8 bit数据。
对RFC 821 MTA，以上5种编码格式中只有前 3种是有效的。因为这 3种产生只包含 N V TA S C I I字符的正文。使用有8 B I T M I M E支持的扩充S M T P允许使用8 b i t编码。
尽管内容类型和编码是独立的， R F C 1 5 2 1推荐有非A S C I I数据的t e x t使用q u o t e d - p r i n t a b l e， 而i m a g e、a u d i o、v i d e o和octet-stream application使用b a s e 6 4。这样允许与符合 RFC 821的M TA保持最大的互操作性。而且， m u l t i p a r t和m e s s a g e内容类型必须以7 b i t编码。
作为一个m u l t i p a r t内容类型的例子，图 2 8 - 8显示了一个来自R F C发布清单的邮件报文。子类型是m i x e d，意思是各部分是顺序处理的，各部分的边界是字符串 N e x t P a r t，其前面是行首的两个连字符。
每个边界上可跟一行用于指明下一部分首部字段。忽略报文中第 1个边界之前和最后一个边界之后的所有内容。
因为在第一个边界后面跟着一个空行，而不是首部，所以在第 1个和第2个边界之间的数据的内容类型被假定为具有 u s - a s c i i字符集的t e x t / p l a i n。这是新R F C的文字描述。
但是第2个边界后面跟着首部字段。它指定了另一个 m u l t i p a r t报文，具有边界O t h e r A c c e s s。子类型为a l t e r n a t i v e，有两种不同的选择。第 1种O t h e r A c c e s s选项是用电子邮件获取R F C，第2种选项是用匿名F T P获取。M I M E用户代理将列出这两种选项，允许我们选择一个，然后自动地用电子邮件或匿名F T P获取一份复制的R F C。
这一部分是 M I M E的一个简要概述。 M I M E的详细细节和例子，见 RFC 1521和[ R o s e 1 9 9 3 ]。
