简介：这份资源是一套基于MFC与C++实现的邮件收发程序源码，面向正在做课程设计或需要理解SMTP、POP3协议编程的学生与初学者。发送端支持发送带附件的邮件，附件大小实测可达5M；接收端按编号列出邮件，单击即可查看内容，并附带黑名单过滤功能，黑名单文件默认放在C盘，可按需修改路径。资源包共34个文件，约3.53MB，以cpp、h源码文件为核心，配合rc资源脚本、dsp与dsw工程文件及exe可执行程序，另含obj、pdb等编译中间文件，可直接用VC6打开运行调试。目前已有482人学习下载。读者可借此获得一套可运行的课设级邮件客户端实现，理解SMTP发信与POP3收信的代码组织方式，并在此基础上自行完善报文头与正文分离、附件base64解码等未完成功能，适合作为协议学习与二次开发的起点。

1. 一个 MFC 邮件收发器：SMTP 与 POP3 的 C++ 落地样本

接手一个老工控上位机项目时，客户提了个很朴素的需求：设备报警要能自动发邮件，值班人员用 Outlook 收就行，别整什么云平台。翻了一圈现成方案，要么是命令行工具不好嵌进 MFC 界面，要么是第三方库授权麻烦。最后我翻出这份基于 MFC 的邮件收发器源码，SMTP 发信、POP3 收信全用 C++ 原生 socket 实现，没有额外依赖，直接编进工程就能跑。它解决的就是「在 Windows 桌面程序里塞一个能发能收的邮件模块」这件事，适合手里有 MFC 项目、需要把告警通知或简单邮件客户端做进界面的 C++ 开发者。下面按我拆包复现的顺序，把 SMTP 命令流、POP3 取信、编码坑和调试方法一条条摊开。

2. SMTP 发信链路：从 socket 握手到 DATA 结束

2.1 为什么不用现成库而自己撸 socket

这份源码最值得看的地方，是它把 SMTP 协议当成一条明文命令流来对待，而不是套一层封装。MFC 本身提供了CAsyncSocket和CSocket两个类，源码里用的是阻塞式的CSocket，配合工作线程跑，界面不卡。选这个路子有三个现实理由：一是老项目往往锁死在 VC6 或 VS2010 工具集，引入现代网络库会带来运行时依赖；二是 SMTP 协议本身足够简单，一条连接就是「服务器问候 → 客户端 EHLO → 认证 → MAIL FROM → RCPT TO → DATA → 正文 → 点号结束 → QUIT」这条固定流水线，自己写反而看得清每一步；三是出问题时能直接抓包对命令，不用猜库内部干了什么。

代价也很明显：TLS 加密、附件 MIME 分段、多收件人这些都得自己补。源码里对 SSL 的支持是缺失的，所以它只能连 25 端口或服务商开放的明文端口。这一点在选型时要想清楚——如果目标邮箱强制 SSL，这份代码需要你自行接 OpenSSL，工作量不小。

2.2 一次完整发信的代码骨架

下面是我从源码里抽出来的核心流程，去掉界面耦合后整理成可直接调用的形式。命令之间的等待用Receive读服务器响应码，判断2xx或3xx才继续。

// 简化后的 SMTP 发信流程，基于 CSocket BOOL SendMail(LPCTSTR server, int port, LPCTSTR user, LPCTSTR pass, LPCTSTR from, LPCTSTR to, LPCTSTR subject, LPCTSTR body) { CSocket sock; if (!sock.Create()) return FALSE; if (!sock.Connect(server, port)) return FALSE; // 建立 TCP 连接 CString resp; RecvLine(sock, resp); // 读 220 问候 if (resp[0] != _T('2')) return FALSE; SendCmd(sock, _T("EHLO localhost\r\n"), resp); // 扩展握手，拿能力列表 SendCmd(sock, _T("AUTH LOGIN\r\n"), resp); // 进入认证 SendCmd(sock, Base64Encode(user) + _T("\r\n"), resp); // 用户名 base64 SendCmd(sock, Base64Encode(pass) + _T("\r\n"), resp); // 密码 base64 if (resp[0] != _T('2')) return FALSE; // 235 认证成功 SendCmd(sock, _T("MAIL FROM:<") + CString(from) + _T(">\r\n"), resp); SendCmd(sock, _T("RCPT TO:<") + CString(to) + _T(">\r\n"), resp); SendCmd(sock, _T("DATA\r\n"), resp); // 354 开始传正文 CString mail; mail.Format(_T("From: %s\r\nTo: %s\r\nSubject: %s\r\n") _T("MIME-Version: 1.0\r\n") _T("Content-Type: text/plain; charset=UTF-8\r\n\r\n%s\r\n.\r\n"), from, to, subject, body); sock.Send(mail, mail.GetLength() * sizeof(TCHAR)); RecvLine(sock, resp); // 250 投递成功 SendCmd(sock, _T("QUIT\r\n"), resp); sock.Close(); return resp[0] == _T('2'); }

逻辑上要盯住三个点。第一，EHLO之后服务器会回多行能力列表，源码里的RecvLine只读一行，遇到多行响应（以250-开头）会漏读，导致后续命令错位——这是最常见的翻车点，正确做法是循环读到250带空格的那一行为止。第二，AUTH LOGIN的用户名和密码必须各自单独 base64 编码后分行发送，不能拼在一起。第三，正文结束的\r\n.\r\n是协议规定的结束标记，少一个点服务器就一直等，连接挂死。

参数上，server填服务商 SMTP 地址，port常见 25 或 587（587 通常要求 STARTTLS，这份代码不支持，会认证失败）。from建议和认证账号一致，否则部分服务器会以「发件人不匹配」拒收。

2.3 多收件人与抄送的拼接方式

源码里RCPT TO只发了一次，实际项目里告警往往要同时发给几个人。改法很简单，把收件人列表拆开，每个地址发一条RCPT TO，服务器对每个地址单独回250，全部成功后再进DATA。抄送在协议层没有单独命令，靠正文头部的Cc:字段实现，收件人能看到。密送则是在RCPT TO里加上地址但头部不写Bcc:，这样收件人互相看不见。这里有个细节：RCPT TO的地址必须用尖括号包住，写成RCPT TO:<a@b.com>，漏了尖括号部分服务器直接回501语法错误。

3. POP3 收信：把邮件从服务器拽回本地

3.1 POP3 的状态机与命令序列

POP3 比 SMTP 更简单，整个会话就是「授权 → 事务 → 更新」三个状态。连上后服务器回+OK，然后USER和PASS认证，进入事务态后可以STAT看邮件总数和总大小、LIST列每封大小、RETR n取第 n 封、DELE n标记删除，最后QUIT才真正执行删除。源码里把RETR的响应按行读，遇到单独一个.行表示邮件结束，这点和 SMTP 的 DATA 结束标记是同一个套路。

// POP3 取信核心：LIST 拿数量，RETR 逐封读取 int FetchMails(CSocket& sock, CStringArray& mails) { CString resp; SendCmd(sock, _T("STAT\r\n"), resp); // +OK 3 1024 表示 3 封共 1024 字节 int total = ParseCount(resp); // 从响应里解析邮件数 for (int i = 1; i <= total; ++i) { CString cmd; cmd.Format(_T("RETR %d\r\n"), i); SendCmd(sock, cmd, resp); if (resp.Left(3) != _T("+OK")) continue; CString mail, line; while (RecvLine(sock, line)) { if (line == _T(".")) break; // 单独点号 = 邮件结束 if (line.Left(2) == _T("..")) // 行首双点还原为单点 line = line.Mid(1); mail += line + _T("\r\n"); } mails.Add(mail); } return total; }

这里有个协议层的「转义」规则容易被忽略：邮件正文里如果某行以.开头，服务器发送时会多加一个点变成..，客户端收到后要还原。源码里做了这个处理，但只在行首判断，如果正文里有..开头的行会误还原，属于边界瑕疵。另外STAT返回的字节数是估算值，不能用来预分配缓冲区，老老实实按行读最稳。

3.2 邮件头解析与正文解码

取回来的原始邮件是一堆头部字段加正文，头部和正文之间空一行分隔。源码里用Find("\r\n\r\n")定位分界，前半段按行拆Key: Value。真正麻烦的是编码：中文主题常见=?UTF-8?B?xxxx?=或=?GB2312?B?xxxx?=这种 RFC 2047 编码，正文则可能是Content-Transfer-Encoding: base64或quoted-printable。源码对 base64 有解码函数，quoted-printable 只做了部分处理，遇到=E4=B8=AD这种连续十六进制转义会解错。

我的处理习惯是：先看Content-Type里的charset，再按Content-Transfer-Encoding选解码器，最后用MultiByteToWideChar转成宽字符显示。GB2312 和 UTF-8 要分开处理，混用会出乱码。附件在multipart分段里，源码没有解析附件，只取了第一段纯文本，如果项目需要存附件，得按boundary切段再逐段判断Content-Disposition。

3.3 连接超时与断线重连

阻塞 socket 最大的坑是没有超时，服务器不响应时线程就卡死。源码里没设SO_RCVTIMEO，我复现时补上了：

int timeout = 10000; // 10 秒 sock.SetSockOpt(SO_RCVTIMEO, &timeout, sizeof(timeout)); sock.SetSockOpt(SO_SNDTIMEO, &timeout, sizeof(timeout));

超时后Receive返回SOCKET_ERROR，此时不能直接重连，要先Close再Create，否则句柄泄漏。重连策略我一般做成三次退避，间隔 2 秒、5 秒、10 秒，超过就上报界面提示。POP3 服务器通常限制单账号并发连接数，重连太频繁会被临时封禁，这点在告警场景里要特别注意——设备频繁报警时别让每次报警都新建连接，复用一个长连接更稳。

4. 编码与字符集：中文邮件不乱码的四个关键点

4.1 主题与发件人的 RFC 2047 编码

发中文主题时，直接往Subject:后面塞 GBK 字节，Outlook 能认，但 Gmail 和部分企业邮箱会显示乱码。规范做法是按 RFC 2047 编码成=?UTF-8?B?base64?=形式。源码里有个EncodeHeader函数做这件事，但它固定用 GB2312，跨平台收件时会翻车。我改成 UTF-8：

CString EncodeHeader(const CString& text) { // 先转 UTF-8 字节，再 base64，最后套 RFC 2047 外壳 int len = WideCharToMultiByte(CP_UTF8, 0, text, -1, NULL, 0, NULL, NULL); char* buf = new char[len]; WideCharToMultiByte(CP_UTF8, 0, text, -1, buf, len, NULL, NULL); CString b64 = Base64Encode((BYTE*)buf, len - 1); delete[] buf; return _T("=?UTF-8?B?") + b64 + _T("?="); }

注意len - 1是去掉结尾的\0，否则 base64 里会多编进一个空字节，解码端多出一个乱码字符。这是血泪经验，我第一次调的时候主题末尾总多个方块，查了半天才发现是这个。

4.2 正文 charset 与传输编码的匹配

正文头部的Content-Type: text/plain; charset=UTF-8和Content-Transfer-Encoding: base64必须匹配。如果声明 UTF-8 却按 GBK 编码字节，收件端按 UTF-8 解就是乱码。源码默认走 8bit 明文传输，中文在部分老服务器上会被截断，稳妥做法是正文也 base64 编码，虽然体积涨三分之一，但兼容性最好。表格对比一下几种组合的实际表现：

4.3 收信端解码的顺序问题

收信解码的顺序不能反：先按传输编码（base64/QP）还原字节流，再按 charset 转字符集。源码里有一处先转字符集再解 base64，导致中文全乱，这是典型的顺序错误。正确链路是「原始字节 → 传输解码 → 字符集转换 → 界面显示」。另外头部字段可能跨行（续行以空格或 Tab 开头），解析时要先做续行合并，否则长主题会被截断。

5. 避坑与排查：五条复现时真踩过的坑

5.1 认证失败但密码明明是对的

现象：AUTH LOGIN后服务器回535，换 Foxmail 同账号能发。原因多半是端口选错——587 端口要求先发STARTTLS再认证，这份代码直接明文认证会被拒。解决：改用 25 端口，或确认服务商是否开放了明文认证；若必须 587，得补 TLS 握手，工作量另算。还有一种情况是账号开启了独立授权码，密码栏要填授权码而不是登录密码。

5.2 邮件发出去了但正文是空的

现象：服务器回250投递成功，收件端正文空白。原因通常是DATA之后正文和结束点号之间少了空行，或者Content-Type头后面没跟空行就接正文。协议要求头部和正文之间必须有一个空行（\r\n\r\n）。解决：拼邮件时严格保证...charset=UTF-8\r\n\r\n这个双换行存在，用十六进制查看器确认一下最稳。

5.3 收信卡死在某封邮件上

现象：RETR某封邮件后线程不返回，界面假死。原因是那封邮件正文里有一行恰好是单个.，客户端误判为结束标记提前退出，剩余数据堵在缓冲区。解决：按协议只认「行首单独点号且后面紧跟 CRLF」为结束，同时处理..还原；更稳的做法是设接收超时，超时后主动QUIT重连。

5.4 中文附件名变成一串问号

现象：附件能下但文件名乱码。原因是文件名用了 RFC 2231 的filename*=UTF-8''...形式，源码只认filename="..."。解决：解析Content-Disposition时同时匹配两种写法，优先取filename*，按''后的编码声明解码。这个坑在跨邮件客户端时特别常见。

5.5 多线程下 CSocket 崩溃

现象：发信线程和收信线程同时操作同一个CSocket对象，偶发断言失败。原因是CSocket不是线程安全的，MFC 的 socket 窗口消息机制要求在同一线程内创建和使用。解决：每个工作线程各自Create自己的 socket，不要跨线程共享；或者改用原始SOCKETAPI 加WSAEventSelect，绕开 MFC 的消息泵依赖。

6. 进阶：把收发器做成可复用的邮件模块

源码跑通之后，我一般不会停在「能发能收」，而是把它抽成一个独立类，界面只负责调接口。具体做法是把 SMTP 和 POP3 各自封装成CMailSender和CMailReceiver，构造时传服务器参数，方法返回错误码而不是弹框，这样告警模块、日志模块都能复用。验证模块是否可靠，我有个笨但有效的办法：搭一个本地测试环境，用 Python 起两个极简的 SMTP/POP3 服务端，把各种边界响应（多行 250、535 认证失败、超时无响应）都模拟一遍，让客户端逐个跑过。

# 极简 SMTP 测试桩，只回固定响应，用来验证客户端命令顺序 import socket s = socket.socket(); s.bind(('127.0.0.1', 2525)); s.listen(1) conn, _ = s.accept() conn.send(b'220 test\r\n') while True: data = conn.recv(1024) if not data: break cmd = data.decode(errors='ignore').strip().upper() if cmd.startswith('EHLO'): conn.send(b'250-test\r\n250 AUTH LOGIN\r\n') elif cmd.startswith('AUTH'): conn.send(b'334 VXNlcm5hbWU6\r\n') elif cmd.startswith('MAIL'): conn.send(b'250 OK\r\n') elif cmd.startswith('DATA'): conn.send(b'354 go\r\n') elif cmd == '.': conn.send(b'250 queued\r\n') elif cmd.startswith('QUIT'): conn.send(b'221 bye\r\n'); break else: conn.send(b'235 OK\r\n')

这个桩的价值在于把「服务器行为」变成可控变量，客户端哪一步命令发错、哪个响应没读全，日志里一目了然。比连真实邮箱调试快得多，也不会因为频繁测试被服务商限流。参数上把端口改成 2525 避开系统占用，响应码按 RFC 5321 的真实取值来写，测出来的行为才可信。

从那以后我每次接邮件相关需求，都强制先用测试桩把命令流跑一遍再连真实服务器，省下的排查时间远超搭桩的半小时。希望这份拆解帮到你，少走几个我踩过的弯路。

本文还有配套的精品资源，点击获取