zoukankan      html  css  js  c++  java
  • SMTP协议分析

    SMTP协议分析

    第1章.     SMTP概述

    1.1.  SMTP在邮件通信中的位置

    SMTP,即简单邮件传送协议,所相应RFC文档为RFC821。同http等多数应用层协议一样,它工作在C/S模式下,用来实现因特网上的邮件传送。SMTP在整个电子邮件通信中所处的位置如 1所看到的。

    ddddddd

    1电子邮件的通信过程

    能够看出,SMTP是用来将客户机上的邮件传送到server上。这里的客户机是指某次连接中的发送方,server是指对应的接收方。在解说发送邮件的整个通信过程前,先解释一以下几个术语。

    1.2.  几个术语

    1.2.1.  邮件

    邮件是一种消息的格式,由信封、首部和正文组成。

    信封上最重要的是收信人的地址。邮件server用这个地址将邮件发送到收信人所在的邮件server上。

    首部是由用户代理或邮件server加入的一些信息。包含ReceivedMessage-IDFromDataReply-ToX-PhoneX-MailerToSubject等字段。

    正文是是发送用户发给接收用户报文的内容。RFC 822 规定正文为NVT ASCII文字行。

    更为具体的说明,请參考RFC821RFC822等协议。

    1.2.2.  用户代理

    用户代理UAUser Agent)是用户与电子邮件系统的交互接口,一般来说它就是我们PC机上的一个程序。Windows上常见的用户代理是FoxmailOutlook 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>。当中COMMANDASCII形式的命令名,Parameter是对应的命令參数,<CRLF>是回车换行符(0DH, 0AH)

    SMTP的响应也不复杂,它的一般形式是:XXX  Readable IllustrationXXX是三位十进制数;Readable Illustration是可读的解释说明,用来表明命令是否成功等。XXX具有例如以下的规律:以2开头的表示成功,以45开头的表示失败,以3开头的表示未完毕(进行中)。

    2.2.2.  一个样例

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

    Ctelnet smtp.126.com 25   /* 以telnet方式连接126邮件server */

    S220 126.com Anti-spam GT for Coremail System (126com[071018]) /* 220为响应数字,其后的为欢迎信息,会应server不同而不同*/

    CHELO smtp.126.com /* HELO 后用来填写返回域名(详细含义请參阅RFC821),但该命令并不检查后面的參数 */

    S:250 OK

    C: MAIL FROM: bripengandre@126.com /* 发送者邮箱 */

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

    CRCPT TO: bripengandre@smail.hust.edu.cn /* 接收者邮箱 */

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

    CDATA  /* 请求发送数据 */

    S354 Enter mail, end with "." on a line by itself

    CEnjoy Protocol Studing

    C.

    S250 Message sent

    CQUIT /* 退出连接 */

    S221 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帮助信息

    220domain>服务就绪

    221domain>服务关闭

    421domain>服务未就绪,关闭传输信道

    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的前提下,提出了传送非7ASCII码的方法,相应的RFC文档有两个:邮件首部的扩充相应于RFC1522,邮件正文的扩充相应与RFC1521(即MIME)。

    3.2.  ESMTP

    ESMTP最显著的地方是加入了用户认证功能。假设用户想使用ESMTP提供的新命令,则在初次与server交互时,发送的命令应该是EHLO而不是HELO。先来看一个样例。

    Ctelnet smtp.126.com 25   /* 以telnet方式连接126邮件server */

    S220 126.com Anti-spam GT for Coremail System (126com[071018]) /* 220为响应数字,其后的为欢迎信息,会应server不同而不同*/

    CEHLO smtp.126.com /* 除了HELO所具有的功能外,EHLO主要用来查询server支持的扩充功能 */

    S250-mail

    S250-AUTH LOGIN PLAIN

    S250-AUTH=LOGIN PLAIN

    S250 8BITMIME /* 最后一个响应数字应答码之后跟的是一个空格,而不是'-' */

    CAUTH LOGIN /* 请求认证 */

    S334 dxNlcm5hbWU6  /* server的响应——经过base64编码了的“Username */

    CY29zdGFAYW1heGl0Lm5ldA==  /* 发送经过BASE64编码了的username */

    S334 UGFzc3dvcmQ6  /* 经过BASE64编码了的"Password:" */

    CMTk4MjIxNA==  /* client发送的经过BASE64编码了的password */

    S235 auth successfully /* 认证成功 */

    C: MAIL FROM: bripengandre@126.com /* 发送者邮箱 */

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

    CRCPT TO: bripengandre@smail.hust.edu.cn /* 接收者邮箱 */

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

    CDATA  /* 请求发送数据 */

    S354 Enter mail, end with "." on a line by itself

    CEnjoy Protocol Studing

    C.

    S250 Message sent

    CQUIT /* 退出连接 */

    S221 Bye

    对于这个样例有例如以下几点说明。

    1)        仅仅是一个示意性的过程,再输入username、password时需採用base64编码,这须要专门的计算,所以在telnet终端上模拟比較麻烦。

    2)        认证过程有非常多种,有基于明文的认证,也有基于MD5加密的认证,这里给出的仅仅是一个示意性的过程。

    3)        EHLO对于详细server,响应会不同,keyword“8BITMIME”用来说明server是否支持正文中传送8位ASCII码,而以“X”开头的keyword都是指server自己定义的扩充(还没纳入RFC标准)

    更具体的说明,请參看RFC1425

    3.3.  邮件首部的扩充

    首部通过两种编码方式来支持传送非7ASCII码。它首先通过一个例如以下格式的编码字来表明所用的编码方式。

    =?charset?encoding?encoded-text?text

    charset是字符集规范。有效值是两个字符串us-asciiiso-8859-x,当中x 是一个单个数字,比如iso-8859-1中的数字为“ 1

    encoding是一个单个字符用来指定编码方法,支持两个值。

    Q代表quoted-printable(可打印)编码。不论什么要发送的字符若其第8比特置1则被作为3个字符发送:第1个是字符是“=”,后面的两个字符相应于字符的十六进制表示。比如对于二进制码11111111,其相应的十六进制表示为“FF”,所以相应的编码位“=FF”。为了可以传输“=”,“=”的编码方式与第8比特置1的字符同样,由于其二进制代码为00111101,所以相应的编码为“=3D”。可以看出这样的编码方式的开销达200%,所以仅仅适合传送仅仅含有少量非7ASCII码的文本。

    B代表base64编码。它的编码方法是先将二进制代码划分为一个24bit长的单元,然后将这24 bit单元划分为46 bit组。每一个组按 2所看到的的方法转换成ASCII码。

    fffffff

    2 base64映射表

    能够看出这种映射方法是这种:0-25依次映射成A-Z26-51依次映射成a-z,52-61依次映射成数字0-9,然后62映射成+63映射成/

    对于二进制代码01001001 00110001 01111001,先将其划分成46 bit组,即010010 0100011 000101 111001。接着按 2所看到的的映射表,可得到base64编码为:STF5。能够看出,这样的编码方式的开销是25%,相对quoted-printable编码来说,它更适合用来传送含大量非7ASCII码的二进制文件。

    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.  浏览器发送邮件用的什么协议

    浏览器如IEMaxthon可通过登陆用户邮箱,来收发邮件,这是如何实现的?比如bripengandre@126.com可通过登陆www.126.com来收发邮件。

    这个过程是这种:bripengandre@126.comwww.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相应ESMTPRFC1522相应邮件首部的扩充,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

  • 相关阅读:
    48. Rotate Image
    83. Remove Duplicates from Sorted List
    46. Permutations
    HTML5笔记
    18. 4Sum
    24. Swap Nodes in Pairs
    42. Trapping Rain Water
    Python modf() 函数
    Python min() 函数
    Python max() 函数
  • 原文地址:https://www.cnblogs.com/gcczhongduan/p/4218153.html
Copyright © 2011-2022 走看看