stmp邮件协议讲解

第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) （C语言中\r\n）

 

SMTP的响应也不复杂，它的一般形式是：XXX Readable Illustration。

XXX：三位十进制数

Readable Illustration：可读的解释说明，用来表明命令是否成功等。XXX具有如下的规律：以2开头的表示成功，以4和5开头的表示失败，以3开头的表示未完成（进行中）。

2.2.2. 一个例子

命令和响应的格式是语法，各命令和响应的意思则是语义，各命令和各响应在时间上的关系则是同步。下面将通过一个简单的SMTP通信过程来说明协议的这三个 要素。

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: [e-mail] /*发送者邮箱*/

S：250 … ./*“…”代表省略了一些可读信息 */

C：RCPT TO: [e-mail] /*接收者邮箱*/

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: [e-mail]/*发送者邮箱*/

S：250 … ./*“…”代表省略了一些可读信息 */

C：RCPT TO: [e-mail]/*接收者邮箱*/

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。