Post Office Protocol - Version 3html
pop3协议是离线邮件协议,是客户端取邮件用的。安全
默认监听在TCP:110端口.服务器
POP3会话有3个状态AUTHORIZATION、TRANSACTION和UPDATE不一样状态能用的命令不一样。dom
等待链接 身份确认 quit命令测试
—— |AUTHORIZATION|————— |TRANSACTION|——————|UPDATE|ui
|________________________________________________________|编码
重返承认状态加密
POP3命令码以下:spa
命令(ascII字符) | 参数 | 状态 | 描述 |
---|---|---|---|
USER | username | AUTHORIZATION | 用户名 |
PASS | password | AUTHORIZATION | 密码,若成功,将致使状态转换 |
APOP | username Digest(加密后密码) | AUTHORIZATION | Digest是MD5消息摘要 |
STAT | none | TRANSACTION | 请求服务器发回关于邮箱的统计资料,如邮件总数和总字节数 |
UIDL(unique-id listing) | [message] | TRANSACTION | 返回邮件的惟一标识符,POP3会话的每一个标识符都将是惟一的 |
LIST | [message] | TRANSACTION | 返回邮件数量和每一个邮件的大小 |
RETR(retrieve) | [message] | TRANSACTION | 返回由参数标识的邮件的所有文本 |
DELE | [message] | TRANSACTION | 服务器将由参数标识的邮件标记为删除,会话进入UPDATE后删除 |
RSET | [message] | TRANSACTION | 服务器将重置全部标记为删除的邮件,用于撤消DELE命令 |
TOP | [message] | TRANSACTION | 服务器将返回由参数标识的邮件前n行内容,n必须是正整数 |
NOOP | [message] | TRANSACTION | 服务器返回一个确定的响应 |
QUIT | none | UPDATE | pop3服务器删除标记为deleted的邮件,不管错误与否,释放独占锁、关闭TCP链接 |
wireshark抓包:第一张为开始,第二章为结束.net
SMTP工做在两种状况下
smtp是个请求/响应协议,命令和响应都是基于ascii文本,并以cr和lf符结束。响应包括一个表示返回状态的三位数字代码。
网图,来自https://blog.csdn.net/bripengandre/article/details/2191048
------------------------------------------------------------- +----------+ +----------+ +------+ | | | | | User |<-->| | SMTP | | +------+ | Sender- |Commands/Replies| Receiver-| +------+ | SMTP |<-------------->| SMTP | +------+ | File |<-->| | and Mail | |<-->| File | |System| | | | | |System| +------+ +----------+ +----------+ +------+ Sender-SMTP Receiver-SMTP -------------------------------------------------------------
COMMAND [Parameter]
XXX Readable Illustration。XXX是三位十进制数;Readable Illustration是可读的解释说明,用来代表命令是否成功等。XXX具备以下的规律:以2开头的表示成功,以4和5开头的表示失败,以3开头的表示未完成(进行中)。
命令 | 描述 |
---|---|
HELO
|
向服务器标识用户身份 |
MAIL FROM:
|
|
RCPT TO:
|
|
DATA
|
将以后的数据做为数据发送,以
|
REST
|
重置会话,当前传输被取消 |
NOOP
|
要求服务器返回OK应答,通常用做测试 |
QUIT
|
结束会话 |
VRFY
|
验证指定的邮箱是否存在,因为安全方面的缘由,服务器大多禁止此命令 |
EXPN
|
验证给定的邮箱列表是否存在,因为安全方面的缘由,服务器大多禁止此命令 |
HELP
|
查询服务器支持什么命令 |
AUTH LOGIN | 认证请求 |
EHLO | 除了HELO所具备的功能外,EHLO主要用来查询服务器支持的扩充功能 |
250 8BITMIME /* 最后一个响应数字应答码以后跟的是一个空格,而不是'-' */
用户名、密码需采用base64编码(Base64就是一种基于64个可打印字符来表示二进制数据的表示方法。)
以“X”开头的关键字都是指服务器自定义的扩充(还没归入RFC标准)
还有一些重要字段
Received: from DM6NAM11HT080.eop-nam11.prod.protection.outlook.com (2603:1096:201:20::24) by HK0PR06MB3714.apcprd06.prod.outlook.com with HTTPS via HK2PR02CA0212.APCPRD02.PROD.OUTLOOK.COM; Sat, 12 Oct 2019 02:04:31 +0000 Received: from DM6NAM11FT041.eop-nam11.prod.protection.outlook.com (10.13.172.57) by DM6NAM11HT080.eop-nam11.prod.protection.outlook.com (10.13.172.248) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2347.16; Sat, 12 Oct 2019 02:04:30 +0000 Authentication-Results: spf=pass (sender IP is 120.26.244.201) smtp.mailfrom=smail.kzedu.cc; hotmail.com; dkim=none (message not signed) header.d=none;hotmail.com; dmarc=bestguesspass action=none header.from=smail.kzedu.cc; Received-SPF: Pass (protection.outlook.com: domain of smail.kzedu.cc designates 120.26.244.201 as permitted sender) receiver=protection.outlook.com; client-ip=120.26.244.201; helo=smtp552.submail.cn; Received: from smtp552.submail.cn (120.26.244.201) by DM6NAM11FT041.mail.protection.outlook.com (10.13.172.98) with Microsoft SMTP Server id 15.20.2347.16 via Frontend Transport; Sat, 12 Oct 2019 02:04:29 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:24B3073D37E1488647AB6D33914E56311671421DA99AC9F3ACCE5038C61D9AED;UpperCasedChecksum:4E628F444082EA3506FF7B7B728D6469D42940820A842E95A6AF817CE7359561;SizeAsReceived:633;Count:10 Date: Sat, 12 Oct 2019 2:4:28 +0000
Received是smtp服务器记录的从哪里收到的邮件。从上往下就是SMTP中继的各个节点。最下面的是发件服务器IP。
Received-SPF是防止假邮件的mail from能够伪造from更不用说,可是SPF记录该域名的邮件服务器的发件IP地址,能够验证真伪(要发假的垃圾邮件要模仿的是SMTP服务器行为,除非黑客控制了一个域名的邮件服务器)。
MIME消息由消息头和消息体两大部分组成,邮件头与邮件体之间以空行进行分隔
邮件头包含了发件人、收件人、主题、时间、MIME版本、邮件内容的类型等重要信息。每条信息称为一个域,由域名后加“: ”和信息内容构成,能够是一行,较长的也能够占用多行。域的首行必须“顶头”写,即左边不能有空白字符(空格和制表符);续行则必须以空白字符打头,且第一个空白字符不是信息自己固有的,解码时要过滤掉。
邮件体包含邮件的内容,它的类型由邮件头的“Content-Type”域指出。常见的简单类型有text/plain(纯文本)和text/html(超文本),multipart/mixed, multipart/related和multipart/alternative。
multipart类型,是MIME邮件的精髓。邮件体被分为多个段,每一个段又包含段头和段体两部分,这两部分之间也以空行分隔。常见的multipart类型有三种:multipart/mixed, multipart/related和multipart/alternative。
+------------------------- multipart/mixed ----------------------------+ | | | +----------------- multipart/related ------------------+ | | | | | | | +----- multipart/alternative ------+ +----------+ | +------+ | | | | | | 内嵌资源 | | | 附件 | | | | | +------------+ +------------+ | +----------+ | +------+ | | | | | 纯文本正文 | | 超文本正文 | | | | | | | +------------+ +------------+ | +----------+ | +------+ | | | | | | 内嵌资源 | | | 附件 | | | | +----------------------------------+ +----------+ | +------+ | | | | | | +------------------------------------------------------+ | | | +----------------------------------------------------------------------+
能够看出,若是在邮件中要添加附件,必须定义multipart/mixed段;若是存在内嵌资源,至少要定义multipart/related段;若是纯文本与超文本共存,至少要定义multipart/alternative段。什么是“至少”?举个例子说,若是只有纯文本与超文本正文,那么在邮件头中将类型扩大化,定义为multipart/related,甚至multipart/mixed,都是容许的。
multipart诸类型的共同特征是,在段头指定“boundary”参数字符串,段体内的每一个子段以此串定界。全部的子段都以“--”+boundary行开始,父段则以“--”+boundary+“--”行结束。段与段之间也以空行分隔。在邮件体是multipart类型的状况下,邮件体的开始部分(第一个“--”+boundary行以前)能够有一些附加的文本行,至关于注释,解码时应忽略。
能够观察一下边界00一、00二、003等
提取pcapng中流量能够从wireshark中直接将邮件正文部分复制出来保存到文件中后缀改成.eml拿客户端打开。反正我以为本身解析邮件中的文件太难了,取个巧。
Base64的索引表,字符选用了"A-Z、a-z、0-九、+、/"
64个可打印字符。数值表明字符的索引,这个是标准Base64协议规定的,不能更改。64个字符用6个bit位就能够所有表示,一个字节有8个bit位,剩下两个bit就浪费掉了,这样就不得不牺牲一部分空间了。这里须要弄明白的就是一个Base64字符是8个bit,可是有效部分只有右边的6个bit,左边两个永远是0。
那么怎么用6个有效bit来表示传统字符的8个bit呢?8和6的最小公倍数是24,也就是说3个传统字节能够由4个Base64字符来表示,保证有效位数是同样的,这样就多了1/3的字节数来弥补Base64只有6个有效bit的不足。
个人邮件当中有那么一段
先用base64解码,而后用GB2312解码
须要注意的是根据RFC 822规定,每76个字符,还须要加上一个回车换行。因此字符串要手动去除回车换行。
参考:
https://zh.wikipedia.org/wiki/Base64