SMTP基本命令集:
命令 描述
------------------------------
HELO 向服务器标识用户身份
发送者能欺骗,说谎,但一般情况下服务器都能检测到。
MAIL 初始化邮件传输
mail from:
RCPT 标识单个的邮件接收人;常在MAIL命令后面
可有多个rcpt to:
DATA 在单个或多个RCPT命令后,表示所有的邮件接收人已标识,并初始化数据传输,以.结束。
VRFY 用于验证指定的用户/邮箱是否存在;由于安全方面的原因,服务器常禁止此命令
EXPN 验证给定的邮箱列表是否存在,扩充邮箱列表,也常被禁用
HELP 查询服务器支持什么命令
NOOP 无操作,服务器应响应OK
QUIT 结束会话
RSET 重置会话,当前传输被取消
1.USER
功能:将你的用户名发送到服务器。
语法:USER <用户名>
返回:+ 正确的用户名;- 错误的用户名
示例:
USER mytar
+OK mytar is welcome on this server.
2.PASS
功能:将你的密码发送给服务器。
语法:PASS <密码>
返回:+ 正确的用户名; - 错误的用户名
示例:
PASS ******
+OK mytar logged in at 19:04
3.STAT
功能:从服务器中获得所有的信息序号和字节数。
语法:STAT
返回:所有的信息(字节)
示例:
STAT
+OK 1 3805
4.LIST
功能:从服务中获得信息列表和大小(字节)。
语法:LIST
返回:列出所有的信息和各自的大小
示例:
LIST
+OK 2 7610
1 3805
2 3805
5.RETR
功能:从服务器中获得一条信息。
语法:RETR <信息的序号>
返回:+ 成功;- 错误
示例:
RETR 1
+OK 1 3805
6.DELE
功能:从服务器中删除一条信息。
语法:DELE <信息的序号>
返回:+ 成功;- 错误
示例:
DELE 1
+OK 1 Deleted
7.QUIT
功能:关闭与服务器的连接。
语法:QUIT
返回:没有
示例:
QUIT
+GOODBYE
AUTH命令
AUTH机制 [初始化响应]
参数:
判别是一个SASL认证机制的字符串。
可选的由base64编码的响应。
约束:
在一个AUTH命令完整结束后,本次会话就不再有其他的AUTH命令涉及了。就是说,在一个成功的AUTH命令后,SMTP服务器用503标识的回应来拒绝任何以后的 AUTH命令。
在一个邮件传输过程中发出的AUTH命令是不被容许的。
讨论:
AUTH命令显示了一种和邮件服务器间的安全认证机制 。如果邮件服务器支持这种认证机制,它就会执行一个认证协议交互来认证并识别邮件用户。作为可选的情况,他也会忽略这以后后协议交互的一个安全层。如果服务器并不支持所需要的认证协议,就会用504的回答来拒绝这个AUTH命令。
认证协议交互过程由一系列由认证机制定义的邮件服务器端的命令和邮件客户端的响应组成。
一个邮件服务器端命令,或者所谓一个准备好响应,是一个334起头的,包含用base64编码的字符串文本。邮件客户端也同样由包含了用base64编码的字符串。如果邮件客户端希望可以取消一个进行中的认证交互过程,它会发出一个仅包含一个字符"*"命令行,邮件服务器端一旦收到这样的一个回答后,必须发一个501标识的回答,而后拒绝AUTH命令。
对AUTH命令来说,可选的初始化响应建议是用来在使用认证机制时保持一个往返的回程,认证机制的定义中此建议不发送任何数据。当初始化响应部分用在这种机制时,开始的空的发起命令不被送到客户端,并且服务器端使用的数据也好象是发送来响应一个空的命令。它发送一个零长度的初始化回答作为一个"="符号。如果客户端在认证机制的AUTH命令响应中使用初始化建议,客户端就在初始化命令中发送响应的数据,服务器端用535回答来拒绝AUTH命令。
如果不能对参数用base64解码,就用501回答来拒绝AUTH命令,如果服务器拒绝认证数据,它应该用535的回答(可以带其他详细的特殊错误代码,比如在第6节所列的代码中的一个)来拒绝AUTH命令。如果客户端成功完成了认证交互,SMTP服务器就应该返回一个235的响应。
本SASL协议梗概中描述的服务名称是SMTP.
如果一个安全层通过了SASL认证交换,随着作为终止客户端认证交换的CRLF(回车换行),这个安全层立即有效。在安全层起作用后,其上的SMTP协议被复位到初试状态(这个SMTP状态是在服务器发出一个220服务准备好的消息后开始的)。接着服务器就会放弃所有来自客户端的知识,例如,不是获得自SASL协商本身的EHLO命令的参数。客户端也会放弃所有来自服务器端的知识,例如,不是获得自SASL协商本身的SMTP扩展服务(这里假设一个客户端可以比较认证前后的建议的SASL机制的列表,从而检测主动down-negotiation攻击)。客户端应该发出一个EHLO命令,此命令作为使一个安全层有效的认证协商成功后的第一个命令。
服务器并不被要求一定支持任何特定的认证机制,同样认证机制要不要求必须支持某种安全层。
一旦一个AUTH命令失败,客户端可以通过发出另外一个AUTH命令来尝试其他一种认证机制。
一旦一个AUTH命令失败,服务器端的行为就好象客户端从没有发出那次AUTH命令一样。
base64编码的字符串一般可以有任意长度。客户端和服务器端都应该可以支持那些由认证机制产生的合法的任意长的请求和响应字符串,而不依赖于服务器或者客户端的、可能存在于协议实现的某些方面的行长度的限制。
AUTH的认证方式有LOGIN,CRAM-MD5,PLAIN等几种。不过目前国内的仅仅支持LOGIN一种,这也是简单的一种。
SMTP 认证功能介绍
SMTP的认证功能主要是增加了AUTH命令。AUTH命令有多种用法,而且有多种认证机制。AUTH支持的认证机制主要有LOGIN,CRAM-MD5等。LOGIN应该是大多数免费邮件服务器都支持的,263与新浪都支持。而新浪还支持CRAM-MD5机制。认证机制一般只在真正发送邮件之前进行,而且只需要执行一次。当认证成功后,即可按原来正常的处理发送邮件。原理是口令-应答(Challenge-Response),即由服务器发送命令要求客户端回答,客户端根据服务器发送信息进行回答,如果应答通过了,则认证成功,即可继续处理。下面对这两种制作一个简单介绍。S:表示服务器返回,C:表示客户端发送。
LOGIN
它应该比较简单。口令-应答过程如下:
1 C: AUTH LOGIN
2 S: 334 dXNlcm5hbWU6
3 C: dXNlcm5hbWU6
4 S: 334 cGFzc3dvcmQ6
5 C: cGFzc3dvcmQ6
6 S: 235 Authentication successful.
1 为客户端向服务器发送认证指令。
2 服务端返回base64编码串,成功码为334。编码字符串解码后为“username:”,说明要求客户端发送用户名。
3 客户端发送用base64编码的用户名,此处为“username:”。
4 服务端返回base64编码串,成功码为334。编码字符串解码后为“password:”,说明要求客户端发送用户口令。
5 客户端发送用base64编码的口令,此处为“password:”。
6 成功后,服务端返回码为235,表示认证成功可以发送邮件了。
对于LOGIN方式认证,其实就是将用户名与口令用base64进行编码,根据服务器的要求,分别发出即可。