转贴地址:http://blog.youkuaiyun.com/bripengandre/archive/2008/03/17/2192111.aspx
POP3 协议分析
第1 章. POP3 概述
POP3 全称为 Post Office Protocol version3 ,即邮局协议第 3 版。它被用户代理用来邮件服务器取得邮 件。 POP3 采用 的也是 C/S 通信 模型,对应的 RFC 文 档为 RFC1939 。 该协议非常简单,所以我们只重点介绍其通信过程,而相关的一些概念和术语请参考 RFC 文档或另外一篇文章《 SMTP 协议分析》
第2 章. POP3 详解
2.1. 通信过程
用户从邮件服务器上接收邮件的典型通信过 程如下。
1) 用户运行用户代理(如 Foxmail, Outlook Express )。
2) 用户代理(以下简称客户端)与邮件服务器(以下简称服务器端)的 110 端口建立 TCP 连 接。
3) 客户端向服务器端发出各种命令,来请求各种服务(如查询邮箱信息,下载某封邮件等)。
4) 服务端解析用户的命令,做出相应动作并返回给客户端一个响应。
5) 3 )和 4) 交替进行,直到接收完所有邮件转到步骤 6) ,或两者的连接被意外中断而直接退出。
6) 用户代理解析从服务器端获得的邮件,以适当地形式(如可读)的形式呈现给用户。
其中 2) 、 3 )和 4 )用 POP3 协议通信。可以看出命令和响应是 POP3 通信的重点,我们将 予以重点讲述。
2.2. 命令和响应
2.2.1. 格式
POP3 的命令不多,它的一般形式是: COMMAND [Parameter] <CRLF> 。其中 COMMAND 是 ASCII 形式的命令名, Parameter 是相应的命令参数, <CRLF> 是回车换行符 (0DH, 0AH) 。
服务器响应是由一个单独的命令行组成,或 多个命令行组成,响应第一行“ +OK ”或“ -ERR ”开头,然后再加上一些 ASCII 文本。“ +OK ”和“ -ERR ”分别指出相应的操作状态是成功的还是失败的。
2.2.2. 三个状态
POP3 协议中有三种状态,认正状态,处理状态,和更新状态。 命令的执行可以改变协议的状态,而对于具体的某命令,它只能在具体的某状态下使用,这些请参看表 1 和 RFC193 。
客户机与服务器刚与服务器建立连接时,它 的状态为认证状态;一旦客户机提供了自己身份并被成功地确认,即由认可状态转入处理状态; 在完成相应的操作后客户机发出 QUIT 命令(具体说明见后续内容),则进入更新状态,更新之后又重返认可状态;当然在认可状态下执行 QUIT 命令,可释放连接。状态间的转移如 图 1 所示。
---建立连接---|认可|--认证成 功--|处理|--执行QUIT--|更新|
|_______ -QUIT结束_________________|
图 1 POP3 的状态转移图
认可状态 |
处理状态 |
更新状态 |
建立连接 |
执行 QUIT |
QUIT 完毕 |
执行 QUIT ,释放连接 |
认证成功 |
2.2.3. 一个例子
命令和响应的格式是语法,各命令和响应的 意思则是语义,各命令和各响应在时间上的关系则是同步。我们还是通过以个简单的 POP3 通信过程来说明协议的这三个 要素。
C : telnet pop3.126.com 110 /* 以 telnet 方式连接 126 邮件服务器 */
S : +OK Welcome to coremail Mail Pop3 Server (126coms[3adb99eb4207ae5256632eecb8f8b4855]) /* +OK, 代表命令成功,其后的信息则随服务器的不同而不同 */
C : USER bripengandre /* 采用明文认证 */
S : +OK core mail
C : PASS Pop3world /* 发送邮箱密码 */
S : +OK 654 message(s) [30930370 byte(s)] /* 认证成功,转入处理状态 */
C : LIST 1 /* 显示第一封邮件的信息 */
S : +OK 1 5184 ./* 第一封邮件 的大小为 5184 字 节 */
C : UIDL 1 /* 返回第一封邮件的唯一标识符 */
S : +OK 1 1tbisBsHaEX9byI9EQAAsd /* 数字 1 后的长字符串就是第一封邮件的唯一标志符 */
C : RETR 1 /* 下载第一封邮件 */
S : +OK 5184 octets /* 第 一封邮件的大小为 5184 字节 */
S : Receiv e … /* 第 一封邮件的具体内容 */
S :…
C : QUIT /* 转入更新状态,接着再转入认证状态 */
S : +OK
C: QUIT /* 退出连接 */
S : +OK core mail /* 成功地退出了连接 */
对于上述的过程,补充如下几点内容。
1) “ C :”开头的行 ( 不包括 "C : ") 是客户端的输入,而以“ S :”开头的行 ( 不包括 "S : ") 则是服务器的输出。
2) 上述的命令并不一定会一次性成功,服务器会返回错误响应(以“ -ERR ”开头),客户端应该按照协 议规定的时序,来输入后续的命令(或重复执行失败的命令,或重置会话,或退出会话等等)。
3) 上述过程是示意性的,实际过程可能与其有较大不同。例如,实际过程中可能使用加密认证( MD5 摘要认证)。
4) RETR 下载下来的邮件可能会难以看懂,这是 因为其可能使用了 quoted-printable 编码或 base64 编码,我们可用 Foxmail 等用户代理软件来解码它。
2.2.4. 常用命令和响应
SMTP 命令不区分大小写,但参数区分大小写,有关这方面的详细说明请参考 RFC1939 。常用的命令如 表 1 所示。
命 令 | 参 数 | 使 用在何种状态中 | 描 述 |
USER | Username | 认证 | 此命令与下面的 pass 命令若成功,将导致状态转 换 |
PASS | Password | 认证 | 此命令若成功,状态转化为更新 |
APOP | Name,Digest | 认证 | Digest 是 MD5 消息摘要 |
STAT | None | 处理 | 请求服务器发回关于邮箱的统计资料,如邮件总数和总字节数 |
UIDL | [Msg#] (邮件号,下同) | 处理 | 返回邮件的唯一标识符, POP3 会话的每个标识符都将是唯一的 |
LIST | [Msg#] | 处理 | 返回邮件的唯一标识符, POP3 会话的每个标识符都将是唯一的 |
RETR | [Msg#] | 处理 | 返回由参数标识的邮件的全部文本 |
DELE | [Msg#] | 处理 | 服务器将由参数标识的邮件标记为删除,由 QUIT 命 令执行 |
TOP | [Msg#] | 处理 | 服务器将返回由参数标识的邮件的邮件头 + 前 n 行内容, n 必须是正整数 |
NOOP | None | 处理 | 服务器返回一个肯定的响应,用于测试连接是否成功 |
QUIT | None | 处理、认证 | 1) 如果服务器处于“处理”状态,么将进入“更新”状态以删除任何标记为 删除的邮件,并重返“认证”状态。 2) 如果服务器处于“认证”状态,则结束会话,退出连接 |
表 1 POP3 的常用命令
至于响应则如 2.2.1 所述,由“ +OK ”或“ -ERR ”开头,后跟一些可读的说明和一些其它参数(对 RETR ,这个参数就是邮件的内容)。更详细的说明请参考 RFC1939 。
第3 章. POP3 VS IMAP
POP3 相对于因特网报文存取协议 IMAP ( Internet Message Access Protocol )的最大的不足是:它只是一个脱机协议, 客户与服务器的交互性不是特别好。例如不能直接在邮箱中创建文件夹,不太好选择性地下载邮件的某部分(虽然 TOP 命令部分地实现了这个功能,但交互性不 是很好)等。然而,它也有自己的优势,那就是协议简单,容易实现,成本低,这是 POP3 用得很广泛而 IMAP 几近淘汰的最重要的原因。
第4 章. 实现方案
ID | Protocol | Captured contents | ||||||
user name | password | sender | receiver | subject | contents | attachments | ||
5 | POP3 | √ | √ | √ | √ | √ | √ |
|
表 2 POP3 分析要求
表 2 给出了协议分析要求。容易看出,获取各个字段是比较容易的。我们可以抓取客户端与服务器端的交互信 息,然后根据各命令字或响应字来提取出我们想要的字段。例如,要获取 user name ,对于明文验证,我们只需检测到客户端的发送信息中出现 USER 这个时候,然后提取出 USER 命令后的参数即可。 需要说明的是,虽然客户端与服务端交互的信息可能经过了编码或加密,但我们仍能够通过解码或解密来获得所需要的信息。
第5 章. 参考资料
[1] RFC 文档: RFC1939 对应 POP3 协议, RFC821 对应 SMTP 协议, RFC822 对应邮件标准, RFC1425 对应 ESMTP , RFC1522 对应邮件首部的扩充, RFC1521 对应邮件正文的扩充
[2] http://www.faqs.org/rfcs/ ,上面有全面的英文 RFC 文档
[3] http://www.cnpaf.net/ ,上面有不少有用的协议分析文档,也有中文 RFC 文档,但质量不是特别高
[4] Stevens, W.R., TCP/IP Illustrated, Vol1. Addision-Wesley, 机械工业出版社, 2002