SMTP协议分析
第1章. SMTP概述
1.1. SMTP在邮件通信中的位置
SMTP，即简单邮件传送协议，所相应RFC文档为RFC821。同http等多数应用层协议一样，它工作在C/S模式下，用来实现因特网上的邮件传送。SMTP在整个电子邮件通信中所处的位置如图 1所看到的。
图 1电子邮件的通信过程
能够看出，SMTP是用来将客户机上的邮件传送到server上。这里的客户机是指某次连接中的发送方，server是指对应的接收方。在解说发送邮件的整个通信过程前，先解释一以下几个术语。
1.2. 几个术语
1.2.1. 邮件
邮件是一种消息的格式，由信封、首部和正文组成。
信封上最重要的是收信人的地址。邮件server用这个地址将邮件发送到收信人所在的邮件server上。
首部是由用户代理或邮件server加入的一些信息。包含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协议将邮件发送到发送端邮件server。
1.2.3. 邮件server
邮件server是电子邮件系统的核心，它用来发送和接收邮件。邮件server不同于普通PC的是它差点儿是全天工作的，所以它能够在不论什么时候为用户提供服务，后面将提到这正是为什么须要邮件server的一个重要原因。非常多ISP都提供免费的邮件server，如126提供smtp.126.com邮件server。
邮件server向其他邮件server转发邮件也是採用SMTP协议。
1.3. 邮件的收发过程
普通情况下，一封邮件的发送和接收步骤例如以下。
1) 发信人在用户代理里编辑邮件，包含填写发信人邮箱、收信人邮箱和邮件标题等等。
2) 用户代理提取发信人编辑的信息，生成一封符合邮件格式标准（RFC822）的邮件。
3) 用户代理用SMTP将邮件发送到发送端邮件server（即发信人邮箱所相应的邮件server）。
4) 发送端邮件server用SMTP将邮件发送到接收端邮件server（即收信人邮箱所相应的邮件server）。
5) 收信人调用用户代理。用户代理用POP3协议从接收端邮件server取回邮件。
6) 用户代理解析收到的邮件，以适当的形式呈如今收信人面前。
第2章. SMTP具体解释
2.1. 通信过程
一个详细的SMTP通信（如发送端邮件server与接收端server的通信）的步骤例如以下。
1) 发送端邮件server（下面简称client）与接收端邮件server（下面简称server）的25号port建立TCP连接。
2) client向server发送各种命令，来请求各种服务（如认证、指定发送人和接收人）。
3) server解析用户的命令，做出对应动作并返回给client一个响应。
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通信过程来说明协议的这三个要素。
C：telnet smtp.126.com 25 /* 以telnet方式连接126邮件server */
S：220 126.com Anti-spam GT for Coremail System (126com[071018]) /* 220为响应数字，其后的为欢迎信息，会应server不同而不同*/
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：")是client的输入，而以“S：”开头的行(不包含"S：")则是server的输出。
2) 上述的命令并不一定会一次性成功，server会返回错误响应，client应该依照协议规定的时序，来输入兴许的命令（或反复运行失败的命令，或重置会话，或退出会话等等）。
2.2.3. 经常使用命令
SMTP命令不区分大写和小写，但參数区分大写和小写，有关这方面的具体说明请參考RFC821。经常使用的命令例如以下。
HELO <domain> <CRLF>。向server标识用户身份发送者能欺骗，说谎，但普通情况下server都能检測到。
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>。要求server返回OK应答，一般用作測试。
QUIT <CRLF>。结束会话。
VRFY <string> <CRLF>。验证指定的邮箱是否存在，因为安全方面的原因，server大多禁止此命令。
EXPN <string> <CRLF>。验证给定的邮箱列表是否存在，因为安全方面的原因，server大多禁止此命令。
HELP <CRLF>。查询server支持什么命令。
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的缺点
从
1) 命令过于简单，没提供认证等功能。
2) 仅仅传送7位的ASCII码，不能传送二进制文件。
针对缺点1)，标准化组织制定了扩充的SMTP（即ESMTP），相应的RFC文档为RFC1425。针对缺点2)，标准化组织在兼容SMTP的前提下，提出了传送非7位ASCII码的方法，相应的RFC文档有两个：邮件首部的扩充相应于RFC1522，邮件正文的扩充相应与RFC1521（即MIME）。
3.2. ESMTP
ESMTP最显著的地方是加入了用户认证功能。假设用户想使用ESMTP提供的新命令，则在初次与server交互时，发送的命令应该是EHLO而不是HELO。先来看一个样例。
C：telnet smtp.126.com 25 /* 以telnet方式连接126邮件server */
S：220 126.com Anti-spam GT for Coremail System (126com[071018]) /* 220为响应数字，其后的为欢迎信息，会应server不同而不同*/
C：EHLO smtp.126.com /* 除了HELO所具有的功能外，EHLO主要用来查询server支持的扩充功能 */
S：250-mail
S：250-AUTH LOGIN PLAIN
S：250-AUTH=LOGIN PLAIN
S：250 8BITMIME /* 最后一个响应数字应答码之后跟的是一个空格，而不是'-' */
C：AUTH LOGIN /* 请求认证 */
S：334 dxNlcm5hbWU6 /* server的响应——经过base64编码了的“Username” */
C：Y29zdGFAYW1heGl0Lm5ldA== /* 发送经过BASE64编码了的username */
S：334 UGFzc3dvcmQ6 /* 经过BASE64编码了的"Password:" */
C：MTk4MjIxNA== /* client发送的经过BASE64编码了的password */
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) 仅仅是一个示意性的过程，再输入username、password时需採用base64编码，这须要专门的计算，所以在telnet终端上模拟比較麻烦。
2) 认证过程有非常多种，有基于明文的认证，也有基于MD5加密的认证，这里给出的仅仅是一个示意性的过程。
3) EHLO对于详细server，响应会不同，keyword“8BITMIME”用来说明server是否支持正文中传送８位ASCII码，而以“X”开头的keyword都是指server自己定义的扩充（还没纳入RFC标准）
更具体的说明，请參看RFC1425。
3.3. 邮件首部的扩充
首部通过两种编码方式来支持传送非7位ASCII码。它首先通过一个例如以下格式的编码字来表明所用的编码方式。
=?charset?encoding?encoded-text?text
charset是字符集规范。有效值是两个字符串us-ascii和iso-8859-x，当中x 是一个单个数字，比如iso-8859-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. 为什么须要SMTPserver
一般的PC资源不够，处理能力不够，不可能全天候地连接在因特网上来收发邮件。所以使用SMTPserver，能够让多个用户共用server，有效地减少了成本。
4.2. SMTP和邮件格式的关系
如前所述，SMTP是客户机向server发送邮件时所使用的协议，其核心是2.2中所述的命令和响应，至于它命令和响应中所带的參数採用什么格式，则是依赖于其它标准的。比如DATA后所带的參数，则应遵循邮件格式标准RFC822．
SMTP和邮件格式的关系可用这么一个样例来说明。甲与乙书信往来，甲通过邮局向乙发信，邮局间转交邮件可看成使用了SMTP协议，至于书信的格式则会由于地区习惯等的不同而不同（中国人的书信格式和美国人的书信格式不同），这个书信格式则可看成是邮件格式标准。
应当认识到不能孤立地看待协议，各个协议之间往往存在着耦合关系，但为了分析方便，我们在详细叙述某个协议时，仅仅能抓住主要矛盾——主要阐述单个协议。
4.3. 浏览器发送邮件用的什么协议
浏览器如IE、Maxthon可通过登陆用户邮箱，来收发邮件，这是如何实现的？比如bripengandre@126.com可通过登陆www.126.com来收发邮件。
这个过程是这种：bripengandre@126.com在www.126.com提供的邮件页面上填写的对应信息（如发信人邮箱、收信人邮箱等），通过http协议被提交给126server；126server依据这些信息组装一封符合邮件规范的邮件（就像用户代理一样）；然后smtp.126.com通过SMTP协议将这封邮件发送到接收端邮件server。
能够看出，浏览器发送邮件仅仅是用户代理的功能直接放到邮件server上去做了，至于邮件server间发送邮件还是採用的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 协议分析要求
表 1给出了协议分析要求。easy看出，获取各个字段是比較easy的。我们可以抓取client与server端的交互信息，然后依据各命令字或响应字来提取出我们想要的字段。比如，要获取user name，我们仅仅需检測到server端要求client发送username这个时候，然后提取这之后client的发送信息就可以。须要说明的是，尽管client与服务端交互的信息可能经过了编码或加密，但我们仍可以通过解码或解密来获得所须要的信息。
第6章. 參考资料
[1] RFC文档：RFC821相应SMTP协议，RFC822相应邮件标准，RFC1425相应ESMTP，RFC1522相应邮件首部的扩充，RFC1521相应邮件正文的扩充，RFC1939相应POP3协议。
[2] http://www.faqs.org/rfcs/，上面有全面的英文RFC文档
[3] http://www.cnpaf.net/，上面有不少实用的协议分析文档，也有中文RFC文档，但质量不是特别高
[4] Stevens, W.R., TCP/IP Illustrated, Vol1. Addision-Wesley, 机械工业出版社，2002