当你的实验指导书过时了但你恰好有一台 VPS，且你还大发善心想给老师点面子-阿晓的日记小站

本文使用ChatGPT-5.5 mini总结完成
考完试之后会好好重新写一下

期末周，本来只是想完成一个《电子邮件协议分析》的实验。

实验指导书上的方案很简单：

下载 Foxmail，配置网易邮箱，关闭 SSL，用 Wireshark 抓 SMTP/POP3 明文报文。

看起来像是五分钟就能结束的任务。

但现实很快告诉你：公共邮箱早就不是教材里那个“可以随便关 SSL 的年代”了。

网易、QQ、Gmail 这类主流邮箱服务，基本都默认启用 TLS/STARTTLS，甚至很多客户端会自动协商加密连接。你在 Foxmail 里把“SSL”勾选取消，并不代表它真的会老老实实走明文；它可能仍然会在 EHLO 阶段看到服务器返回的 250-STARTTLS，然后自动升级到 TLS。

于是 Wireshark 里看到的不是：

220 mail.example.com ESMTP Postfix
EHLO ...
MAIL FROM:<...>
RCPT TO:<...>
DATA
QUIT

而是：

Client Hello
Server Hello
Encrypted Application Data

实验要求分析 SMTP/POP3，现实直接给你 TLS。

第一阶段：怀疑人生

一开始你会很自然地怀疑是不是自己哪里配错了。

于是开始尝试：

在 Foxmail 里关闭 SSL/TLS；
修改账户高级设置；
换成普通 POP3/SMTP 端口；
用 Wireshark 抓包；
用 tcpdump 看服务器有没有收到连接；
用 ncat/telnet 手工连服务器测试。

结果发现：

客户端一连上去，马上就进入 TLS；
Wireshark 里看不到 EHLO、MAIL FROM、RCPT TO 这些明文 SMTP 命令；
POP3 也一样，抓到的不是 USER、PASS，而是加密后的 TLS 流量。

这时候你才意识到一个问题：

实验指导书描述的是一个已经不存在的网络环境。

它假设你还能像十几年前那样，直接连到一个允许明文 SMTP/POP3 的公共邮箱服务器，然后在抓包里看到完整的协议交互。

但现在的现实是：公共邮箱服务默认就是加密优先，甚至强制加密。

第二阶段：既然公共邮箱不配合，那就自己造一个

正好手里有一台 VPS。

于是思路就变成了：自己搭一个可控的邮件服务器环境。

系统选的是 Ubuntu 22.04，邮件服务组件分别是：

Postfix：负责 SMTP 服务；
Dovecot：负责 POP3 服务。

这样做的好处是：

服务器完全由自己控制；
可以决定是否启用 TLS/STARTTLS；
可以决定监听哪些端口；
可以决定是否允许明文认证；
可以直接抓到完整的协议交互过程。

为了满足实验“分析明文 SMTP/POP3”的要求，最关键的一点就是：

关闭 SMTP 的 STARTTLS

在 Postfix 的 main.cf 中执行如下操作：

先用 sudo nano /etc/postfix/main.cf 打开配置文件，将 smtpd_tls_security_level = may 修改为 smtpd_tls_security_level = none，

并将 smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem、smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key 等 TLS 相关配置行删除或在行首加 # 注释掉；

保存后执行 sudo systemctl restart postfix 重启服务，

再用 ncat 服务器IP 2525 连接并输入 EHLO test 验证，此时服务器返回的能力列表中应不再出现 250-STARTTLS。

关闭 POP3 的加密连接

在 Dovecot 的配置中主要修改了三个文件：

/etc/dovecot/conf.d/10-ssl.conf 中将 ssl = no，关闭 TLS/SSL；

/etc/dovecot/conf.d/10-master.conf 中将普通 POP3 监听端口改为 1110，并关闭 POP3S 监听端口（如 995）；

/etc/dovecot/conf.d/10-auth.conf 中将 disable_plaintext_auth = plain login ，允许明文认证。

完成后重启 Dovecot，确保客户端连接时不会自动升级为 TLS。

让客户端和服务器之间保持明文通信

在邮件客户端中取消 SSL/TLS 和 STARTTLS 选项，使用普通 SMTP/POP3 端口进行收发邮件，这样 Wireshark/TShark 就能直接解析 EHLO、MAIL FROM、RCPT TO、DATA、USER、PASS 等协议内容。

这样 Wireshark 才能直接看到协议层内容，而不是只看到 TLS 握手和加密数据。

第三阶段：现实继续教育你

以为装完 Postfix 和 Dovecot 就结束了？

不存在。

问题接踵而来，而且每一个都很现实。

1. 25 端口：标准 SMTP 端口，但云平台不一定让你用

SMTP 的标准端口是：

TCP 25

但很多 VPS/云平台会对 25 端口做限制，原因很简单：

防止垃圾邮件；
防止滥发；
防止新机器直接对外发信；
防止被滥用成开放中继。

所以你会遇到一种很典型的情况：

本机服务明明启动了；
ss -tlnp 也能看到监听；
但外网就是连不上；
或者 SYN 发出去了，SYN/ACK 回来了，但客户端始终收不到完整会话。

这时候最直接的办法就是换端口。

于是 SMTP 改成：

这是邮件实验里非常常见的替代端口，很多测试环境都会这么做。

2. 110 端口：标准 POP3 端口，但同样可能被限制

POP3 的标准端口是：

TCP 110

但现实里，110 端口也经常遇到类似问题：

云平台安全组没放行；
上游网络对邮件端口有限制；
客户端能发 SYN，但收不到服务器返回；
或者服务端明明发了 SYN/ACK，客户端却一直重传 SYN。

所以 POP3 也改成：

或者类似的非标准测试端口。

这样做的本质不是“改协议”，而是换一个不容易被网络策略拦截的监听端口，协议本身仍然是标准 SMTP/POP3。

3. Wireshark 不认识 2525 / 1100

端口一改，新的问题又来了。

Wireshark 默认只会把：

25 识别为 SMTP；
110 识别为 POP3；
465/587/993/995 识别为对应的加密邮件协议或 TLS 相关流量。

但你现在用的是：

SMTP：2525
POP3：1100

于是 Wireshark 可能只把它们当成普通 TCP 流量。

这时候就需要手动告诉它：

2525 其实是 SMTP
1100 其实是 POP3

可以在 Wireshark 里用：

Analyze → Decode As...

把对应的 TCP 端口指定为 SMTP 或 POP3。

如果是 TShark，则可以直接用 -d 参数：

tshark \
  -r mail.pcapng \
  -d tcp.port==2525,smtp \
  -d tcp.port==1110,pop

这样即使端口不是标准端口，TShark 也会按 SMTP/POP3 协议去解析。

第四阶段：把 TLS 从服务器上彻底拿掉

你后来抓包时发现一个很关键的现象：

250-STARTTLS

这说明 Postfix 仍然在告诉客户端：

“我支持 STARTTLS，你可以升级成 TLS。”

而 Foxmail 一旦看到这个响应，通常就会自动发起 TLS 升级，后面的流量自然全部变成加密数据。

所以真正要做的不是“客户端勾不勾 SSL”，而是让服务器根本不要提供 STARTTLS。

在 Postfix 里，相关配置通常会出现在 main.cf 中，例如：

smtpd_tls_security_level = may
smtp_tls_security_level = may
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key

其中：

may 表示“支持 TLS，但不强制”；
只要服务器返回了 250-STARTTLS，客户端就可能升级；
一旦升级，Wireshark 看到的就是 TLS，而不是 SMTP 明文。

为了实验，需要把它改成：

smtpd_tls_security_level = none
smtp_tls_security_level = none

并移除或禁用相关证书配置，让 Postfix 不再向客户端宣告 STARTTLS 能力。

这样客户端在 EHLO 后看到的响应里就不会再出现：

250-STARTTLS

而是只剩下：

250-PIPELINING
250-SIZE ...
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-SMTPUTF8
250 CHUNKING

这时 Foxmail 才会老老实实走明文 SMTP。

第五阶段：终于抓到了真正的明文 SMTP

当你把 SMTP 服务改到 2525，并关闭 STARTTLS 后，终于可以看到完整的明文会话了。

例如抓包里会出现这样的内容：

220 mail.icydaybreak.cn ESMTP Postfix (Ubuntu)
EHLO Daybreak-chan-s-Laptop
250-mail.icydaybreak.cn
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-SMTPUTF8
250 CHUNKING
MAIL FROM:<akira@icydaybreak.cn>
250 2.1.0 Ok
RCPT TO:<daybreak@icydaybreak.cn>
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>

然后就是邮件头和正文：

Date: Tue, 7 Jul 2026 15:24:03 +0800
From: akira <akira@icydaybreak.cn>
To: daybreak <daybreak@icydaybreak.cn>
Subject: 2222
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.2.25.558[cn]
Mime-Version: 1.0
Message-ID: <202607071524030329203@icydaybreak.cn>
Content-Type: multipart/alternative;
        boundary="----=_001_NextPart702127264808_=----"

正文部分则会看到 MIME 多段结构：

------=_001_NextPart702127264808_=----
Content-Type: text/plain;
        charset="us-ascii"
Content-Transfer-Encoding: base64

DQoNCjIyMjIyDQoNCmFraXJhDQo=

这里的 Content-Transfer-Encoding: base64 很关键。

它说明邮件正文并不是“加密”，而是编码。
Base64 的作用是把二进制或非 ASCII 内容转换成适合邮件传输的文本格式，方便在 7-bit 兼容的邮件系统中传递。

例如：

DQoNCjIyMjIyDQoNCmFraXJhDQo=

解码后就是类似：

22222

akira

这正好对应实验里常见的“邮件内容编码分析”部分。

第六阶段：POP3 也要同样处理

SMTP 搞定之后，POP3 也要走同样的路线。

标准 POP3 端口是：

TCP 110

但由于网络限制和实验环境原因，POP3 也改成了：

然后在 Dovecot 中配置对应的监听端口，并确保它提供的是明文 POP3，而不是 POP3S 或 STARTTLS 升级后的加密连接。

这样抓包时就能看到完整的 POP3 命令序列，例如：

+OK Dovecot ready.
USER akira
+OK
PASS ********
+OK Logged in.
STAT
+OK 1 1024
LIST
+OK 1 messages:
1 1024
RETR 1
+OK 1024 octets
QUIT
+OK Logging out.

这些命令对应的就是实验里最经典的 POP3 交互过程：

USER
PASS
STAT
LIST
RETR
QUIT

如果启用了 TLS，那么这些命令就会被加密，Wireshark 只能看到 TLS 流量；
但在明文模式下，它们会完整暴露出来，正好满足实验分析要求。

最终成果

SMTP 抓包成功：

220 mail.xxx ESMTP Postfix

EHLO

MAIL FROM:<xxx>

RCPT TO:<xxx>

DATA

Subject: test

Hello

.

QUIT

邮件正文中的 MIME 编码也成功分析：

Content-Transfer-Encoding: base64

POP3 也可以抓到完整的认证和取信过程：

USER
PASS
STAT
LIST
RETR
QUIT

实验要求全部满足。

虽然监听端口不是标准的 25/110，而是 2525/1100，但应用层协议本身仍然是标准 SMTP/POP3，抓到的命令、响应、邮件头、正文编码过程都没有变化。

如果需要用 TShark 做后续分析，只要加上：

-d tcp.port==2525,smtp
-d tcp.port==1110,pop

就可以把这些非标准端口正确解析成 SMTP 和 POP3。

总结经验

如果你遇到一个网络实验，不要第一时间怀疑自己。

先问三个问题：

1. 实验环境是不是已经过时？

很多教材里的网络实验，默认的是一个“明文协议还很常见”的时代，例如：

明文 FTP；
明文 HTTP；
明文 SMTP；
明文 POP3；
Telnet 登录。

但现实公网环境里，这些协议早就被 TLS、STARTTLS、认证策略和安全策略层层包裹起来了。

教材里写的是“抓明文协议”，现实里给你的是“默认加密”。

2. 公共服务是不是已经不适合实验？

大型公共服务为了安全和反滥用，会做很多限制：

强制 TLS；
禁止明文认证；
限制标准邮件端口；
自动升级到加密连接；
隐藏底层协议细节。

这对普通用户是好事，但对协议分析实验来说就很不友好。

因为实验需要的是：

可控；
可重复；
可观察；
可抓到完整明文。

所以很多时候，最好的办法不是“想办法让公共服务配合你”，而是自己搭一个可控环境。

3. 你有没有一台 VPS？

如果有：

很多问题会从：

“为什么这个服务不给我看协议？”

变成：

“我自己搭一个服务看。”

这就是 VPS 的价值。

它让你可以自己决定：

用什么系统；
装什么服务；
开不开 TLS；
监听什么端口；
允许谁访问；
抓什么包；
怎么解析。

对于网络实验来说，这种可控性非常重要。

最后：

为了一个实验搭了一套邮件服务器。

严格来说，有点杀鸡用牛刀。

但下次再遇到：

“为什么抓不到明文协议？”

你就不用再搜索半天了。

因为你已经知道答案：

现代互联网默认就是加密的。
想研究协议细节，有时候只能自己创造一个可控环境。

实验指导书赢了理论。
现实网络赢了实践。
而 VPS 负责让两者重新连接起来。