第1章. SMTP概述
1.1. SMTP在邮件通信中的位置
SMTP，即简单邮件传送协议，所对应RFC文档为RFC821。同http等多数应用层协议一样，它工作在C/S模式下，用来实现因特网上的邮件传送。SMTP在整个电子邮件通信中所处的位置如图 1所示。
图 1电子邮件的通信过程
可以看出，SMTP是用来将客户机上的邮件传送到服务器上。这里的客户机是指某次连接中的发送方，服务器是指相应的接收方。在讲解发送邮件的整个通信过程前，先解释一下面几个术语。
1.2. 几个术语
1.2.1. 邮件
邮件是一种消息的格式，由信封、首部和正文组成。
信封上最重要的是收信人的地址。邮件服务器用这个地址将邮件发送到收信人所在的邮件服务器上。
首部是由用户代理或邮件服务器添加的一些信息。包括Received、Message-ID、From、Data、Reply-To、X-Phone、X-Mailer、To和Subject等字段。
正文是是发送用户发给接收用户报文的内容。RFC 822 规定正文为NVT ASCII文字行。
更为详细的说明，请参考RFC821和RFC822等协议。
1.2.2. 用户代理
用户代理UA（User Agent）是用户与电子邮件系统的交互接口，一般来说它就是我们PC机上的一个程序。Windows上常见的用户代理是Foxmail和Outlook Express。
用户代理提供一个好的用户界面，它提取用户在其界面填写的各项信息，生成一封符合SMTP等邮件标准的邮件，然后采用SMTP协议将邮件发送到发送端邮件服务器。
1.2.3. 邮件服务器
邮件服务器是电子邮件系统的核心，它用来发送和接收邮件。邮件服务器不同于普通PC的是它几乎是全天工作的，所以它可以在任何时候为用户提供服务，后面将提到这正是为什么需要邮件服务器的一个重要原因。很多ISP都提供免费的邮件服务器，如126提供smtp.126.com邮件服务器。
邮件服务器向其它邮件服务器转发邮件也是采用SMTP协议。
1.3. 邮件的收发过程
一般情况下，一封邮件的发送和接收过程如下。
1) 发信人在用户代理里编辑邮件，包括填写发信人邮箱、收信人邮箱和邮件标题等等。
2) 用户代理提取发信人编辑的信息，生成一封符合邮件格式标准（RFC822）的邮件。
3) 用户代理用SMTP将邮件发送到发送端邮件服务器（即发信人邮箱所对应的邮件服务器）。
4) 发送端邮件服务器用SMTP将邮件发送到接收端邮件服务器（即收信人邮箱所对应的邮件服务器）。
5) 收信人调用用户代理。用户代理用POP3协议从接收端邮件服务器取回邮件。
6) 用户代理解析收到的邮件，以适当的形式呈现在收信人面前。
第2章. SMTP详解
2.1. 通信过程
一个具体的SMTP通信（如发送端邮件服务器与接收端服务器的通信）的过程如下。
1) 发送端邮件服务器（以下简称客户端）与接收端邮件服务器（以下简称服务器）的25号端口建立TCP连接。
2) 客户端向服务器发送各种命令，来请求各种服务（如认证、指定发送人和接收人）。
3) 服务器解析用户的命令，做出相应动作并返回给客户端一个响应。
4) 2)和3)交替进行，直到所有邮件都发送完或两者的连接被意外中断。
从这个过程看出，命令和响应是SMTP协议的重点，下面将予以重点讲述。
2.2. 命令和响应
2.2.1. 格式
SMTP的命令不多（14个），它的一般形式是：COMMAND [Parameter] <CRLF>。其中COMMAND是ASCII形式的命令名，Parameter是相应的命令参数，<CRLF>是回车换行符(0DH, 0AH)。
SMTP的响应也不复杂，它的一般形式是：XXX Readable Illustration。XXX是三位十进制数；Readable Illustration是可读的解释说明，用来表明命令是否成功等。XXX具有如下的规律：以2开头的表示成功，以4和5开头的表示失败，以3开头的表示未完成（进行中）。
2.2.2. 一个例子
命令和响应的格式是语法，各命令和响应的意思则是语义，各命令和各响应在时间上的关系则是同步。下面将通过一个简单的SMTP通信过程来说明协议的这三个要素。（每条命令结尾的<CRLF>省略）
C：telnet smtp.126.com 25 /* 以telnet方式连接126邮件服务器 */
S：220 126.com Anti-spam GT for Coremail System (126com[071018]) /* 220为响应数字，其后的为欢迎信息，会应服务器不同而不同*/
C：HELO smtp.126.com /* HELO 后用来填写返回域名（具体含义请参阅RFC821），但该命令并不检查后面的参数 */
Ｓ：250 OK
C: MAIL FROM: bripengandre@126.com /* 发送者邮箱 */
S：250 … ./* “…”代表省略了一些可读信息 */
C：RCPT TO: bripengandre@smail.hust.edu.cn /* 接收者邮箱 */
S：250 … ./* “…”代表省略了一些可读信息 */
C：DATA /* 请求发送数据 */
S：354 Enter mail, end with "." on a line by itself
C：Enjoy Protocol Studing
C：.
S：250 Message sent
C：QUIT /* 退出连接 */
S：221 Bye
分析上面的过程可参考注释进行，这里要补充如下几点。
1) “C：”开头的行(不包括"C：")是客户端的输入，而以“S：”开头的行(不包括"S：")则是服务器的输出。
2) 上述的命令并不一定会一次性成功，服务器会返回错误响应，客户端应该按照协议规定的时序，来输入后续的命令（或重复执行失败的命令，或重置会话，或退出会话等等）。
2.2.3. 常用命令
SMTP命令不区分大小写，但参数区分大小写，有关这方面的详细说明请参考RFC821。常用的命令如下。
HELO <domain> <CRLF>。向服务器标识用户身份发送者能欺骗，说谎，但一般情况下服务器都能检测到。
MAIL FROM: <reverse-path> <CRLF>。<reverse-path>为发送者地址，此命令用来初始化邮件传输，即用来对所有的状态和缓冲区进行初始化。
RCPT TO：<forward-path> <CRLF>。 <forward-path>用来标志邮件接收者的地址，常用在MAIL FROM后，可以有多个RCPT TO。
DATA <CRLF>。将之后的数据作为数据发送，以<CRLF>.<CRLF>标志数据的结尾。
REST <CRLF>。重置会话，当前传输被取消。
NOOP <CRLF>。要求服务器返回OK应答，一般用作测试。
QUIT <CRLF>。结束会话。
VRFY <string> <CRLF>。验证指定的邮箱是否存在，由于安全方面的原因，服务器大多禁止此命令。
EXPN <string> <CRLF>。验证给定的邮箱列表是否存在，由于安全方面的原因，服务器大多禁止此命令。
HELP <CRLF>。查询服务器支持什么命令。
2.2.4. 常用响应
常用的响应如下所示，数字后的说明是从英文译过来的。更详细的说明请参考RFC821。
501参数格式错误
502命令不可实现
503错误的命令序列
504命令参数不可实现
211系统状态或系统帮助响应
214帮助信息
220＜domain＞服务就绪
221＜domain＞服务关闭
421＜domain＞服务未就绪，关闭传输信道
250要求的邮件操作完成
251用户非本地，将转发向＜forward-path＞
450要求的邮件操作未完成，邮箱不可用
550要求的邮件操作未完成，邮箱不可用
451放弃要求的操作；处理过程中出错
551用户非本地，请尝试＜forward-path＞
452系统存储不足，要求的操作未执行
552过量的存储分配，要求的操作未执行
553邮箱名不可用，要求的操作未执行
354开始邮件输入，以"."结束
554操作失败
第3章. SMTP的扩充
3.1. SMTP的缺点
从2.2.2的例子可以看出，SMTP至少还有如下缺点。
1) 命令过于简单，没提供认证等功能。
2) 只传送7位的ASCII码，不能传送二进制文件。
针对缺点1)，标准化组织制定了扩充的SMTP（即ESMTP），对应的RFC文档为RFC1425。针对缺点2)，标准化组织在兼容SMTP的前提下，提出了传送非7位ASCII码的方法，对应的RFC文档有两个：邮件首部的扩充对应于RFC1522，邮件正文的扩充对应与RFC1521（即MIME）。
3.2. ESMTP
ESMTP最显著的地方是添加了用户认证功能。如果用户想使用ESMTP提供的新命令，则在初次与服务器交互时，发送的命令应该是EHLO而不是HELO。先来看一个例子。(注意每行数据末尾的 )
- C：telnet smtp.126.com 25//以telnet方式连接126邮件服务器
- S：220 126.com Anti-spam GT for Coremail System (126com[071018])//220为响应数字，其后的为欢迎信息，会应服务器不同而不同
- C：EHLO smtp.126.com //除了HELO所具有的功能外，EHLO主要用来查询服务器支持的扩充功能
- S：250-mail
- S：250-AUTH LOGIN PLAIN
- S：250-AUTH=LOGIN PLAIN
- S：250 8BITMIME//最后一个响应数字应答码之后跟的是一个空格，而不是'-'
- C：AUTH LOGIN //请求认证
- S：334 dxNlcm5hbWU6//服务器的响应——经过base64编码了的“Username”
- C：Y29zdGFAYW1heGl0Lm5ldA== //发送经过BASE64编码了的用户名
- S：334 UGFzc3dvcmQ6//经过BASE64编码了的"Password:"
- C：MTk4MjIxNA== //客户端发送的经过BASE64编码了的密码
- S：235 auth successfully//认证成功
- C: MAIL FROM: bripengandre@126.com //发送者邮箱
- S：250 … .//“…”代表省略了一些可读信息
- C：RCPT TO: bripengandre@smail.hust.edu.cn //接收者邮箱
- S：250 … .//“…”代表省略了一些可读信息
- C：DATA //请求发送数据
- S：354 Enter mail, end with "." on a line by itself
- C：Enjoy Protocol Studing
- C：.
- S：250 Message sent
- C：QUIT //退出连接
- S：221 Bye
C：telnet smtp.126.com 25//以telnet方式连接126邮件服务器 S：220 126.com Anti-spam GT for Coremail System (126com[071018])//220为响应数字，其后的为欢迎信息，会应服务器不同而不同 C：EHLO smtp.126.com //除了HELO所具有的功能外，EHLO主要用来查询服务器支持的扩充功能 S：250-mail S：250-AUTH LOGIN PLAIN S：250-AUTH=LOGIN PLAIN S：250 8BITMIME//最后一个响应数字应答码之后跟的是一个空格，而不是'-' C：AUTH LOGIN //请求认证 S：334 dxNlcm5hbWU6//服务器的响应——经过base64编码了的“Username” C：Y29zdGFAYW1heGl0Lm5ldA== //发送经过BASE64编码了的用户名 S：334 UGFzc3dvcmQ6//经过BASE64编码了的"Password:" C：MTk4MjIxNA== //客户端发送的经过BASE64编码了的密码 S：235 auth successfully//认证成功 C: MAIL FROM: bripengandre@126.com //发送者邮箱 S：250 … .//“…”代表省略了一些可读信息 C：RCPT TO: bripengandre@smail.hust.edu.cn //接收者邮箱 S：250 … .//“…”代表省略了一些可读信息 C：DATA //请求发送数据 S：354 Enter mail, end with "." on a line by itself C：Enjoy Protocol Studing C：. S：250 Message sent C：QUIT //退出连接 S：221 Bye
对于这个例子有如下几点说明。
1) 只是一个示意性的过程，再输入用户名、密码时需采用base64编码，这需要专门的计算，所以在telnet终端上模拟比较麻烦。
2) 认证过程有很多种，有基于明文的认证，也有基于MD5加密的认证，这里给出的只是一个示意性的过程。
3) EHLO对于具体服务器，响应会不同，关键字“8BITMIME”用来说明服务器是否支持正文中传送８位ASCII码，而以“X”开头的关键字都是指服务器自定义的扩充（还没纳入RFC标准）
更详细的说明，请参看RFC1425。
3.3. 邮件首部的扩充
首部通过两种编码方式来支持传送非7位ASCII码。它首先通过一个如下格式的编码字来表明所用的编码方式。
=?charset?encoding?encoded-text?text
charset是字符集规范。有效值是两个字符串us-ascii和iso-8859-x，其中x 是一个单个数字，例如iso-8859-1中的数字为“ 1”。
encoding是一个单个字符用来指定编码方法，支持两个值。
Q代表quoted-printable（可打印）编码。任何要发送的字符若其第8比特置1则被作为3个字符发送：第1个是字符是“=”，后面的两个字符对应于字符的十六进制表示。例如对于二进制码11111111，其对应的十六进制表示为“FF”，所以对应的编码位“=FF”。为了能够传输“=”，“=”的编码方式与第８比特置１的字符相同，因为其二进制代码为00111101，所以对应的编码为“=3D”。可以看出这种编码方式的开销达200%，所以只适合传送只含有少量非7位ASCII码的文本。
B代表base64编码。它的编码方法是先将二进制代码划分为一个24bit长的单元，然后将这24 bit单元划分为4个6 bit组。每个组按图 2所示的方法转换成ASCII码。
图 2 base64映射表
可以看出这种映射方法是这样的：0-25依次映射成A-Z，26-51依次映射成a-z,52-61依次映射成数字0-9，然后62映射成+，63映射成/。
对于二进制代码01001001 00110001 01111001，先将其划分成4个6 bit组，即010010 0100011 000101 111001。接着按图 2所示的映射表，可得到base64编码为：STF5。可以看出，这种编码方式的开销是25%，相对quoted-printable编码来说，它更适合用来传送含大量非7位ASCII码的二进制文件。
3.4. 正文的扩充
正文的扩充主要是使正文不仅可以传输NVT ASCII字符，而且可以传输任意字符，对应的文档为RFC1511（即MIME）。
MIME全称为“Multiple Internet Mail Extensions”, 比较确切的中文名称为“多用途互联网邮件扩展”。它通过新增一些邮件首部字段、邮件内容格式和传送编码，使得其成为一种应用很广泛的可以传输多媒体的电子邮件规范。
更详细的说明请参看另一篇文章《MIME协议分析》和RFC1511。
第4章. 常见的疑问
4.1. 为什么需要SMTP服务器
一般的PC资源不够，处理能力不够，不可能全天候地连接在因特网上来收发邮件。所以使用SMTP服务器，可以让多个用户共用服务器，有效地降低了成本。
4.2. SMTP和邮件格式的关系
如前所述，SMTP是客户机向服务器发送邮件时所使用的协议，其核心是2.2中所述的命令和响应，至于它命令和响应中所带的参数采用什么格式，则是依赖于其他标准的。例如DATA后所带的参数，则应遵循邮件格式标准RFC822．
SMTP和邮件格式的关系可用这么一个例子来说明。甲与乙书信往来，甲通过邮局向乙发信，邮局间转交邮件可看成使用了SMTP协议，至于书信的格式则会因为地区习惯等的不同而不同（中国人的书信格式和美国人的书信格式不同），这个书信格式则可看成是邮件格式标准。
应当认识到不能孤立地看待协议，各个协议之间往往存在着耦合关系，但为了分析方便，我们在具体叙述某个协议时，只能抓住主要矛盾——主要阐述单个协议。
4.3. 浏览器发送邮件用的什么协议
浏览器如IE、Maxthon可通过登陆用户邮箱，来收发邮件，这是怎样实现的？例如bripengandre@126.com可通过登陆www.126.com来收发邮件。
这个过程是这样的：bripengandre@126.com在www.126.com提供的邮件页面上填写的相应信息（如发信人邮箱、收信人邮箱等），通过http协议被提交给126服务器；126服务器根据这些信息组装一封符合邮件规范的邮件（就像用户代理一样）；然后smtp.126.com通过SMTP协议将这封邮件发送到接收端邮件服务器。
可以看出，浏览器发送邮件只是用户代理的功能直接放到邮件服务器上去做了，至于邮件服务器间发送邮件还是采用的SMTP协议。我们看问题，如果有必要还是要适当地透过现象看本质。
4.4. 如何用实验验证SMTP的通信过程
1) 可以通过ethereal等协议分析软件来抓包分析协议。
2) 可以利用socket编程实现SMTP的通信过程。
3) 可以利用用户代理来查看一封邮件的原始编码。例如在Foxmail中，可以选择邮件列表右键菜单的“原始信息”进行查看。
第5章. 分析方案
|
ID |
Protocol |
Captured contents |
||||||
|
user name |
password |
sender |
receiver |
subject |
contents |
attachments |
||
|
4 |
smtp |
√ |
√ |
√ |
√ |
√ |
√ |
|
表 1给出了协议分析要求。容易看出，获取各个字段是比较容易的。我们可以抓取客户端与服务器端的交互信息，然后根据各命令字或响应字来提取出我们想要的字段。例如，要获取user name，我们只需检测到服务器端要求客户端发送用户名这个时候，然后提取这之后客户端的发送信息即可。需要说明的是，虽然客户端与服务端交互的信息可能经过了编码或加密，但我们仍能够通过解码或解密来获得所需要的信息。