简介：这份资源是一套基于 MFC 与 C++ 实现的邮件收发程序源码，面向正在学习网络编程、准备课程设计或需要理解 SMTP 与 POP3 协议交互流程的学生与开发者。发送端支持发送带附件的邮件，附件大小实测可达 5MB；接收端按编号列出邮件，单击即可查看内容，并附带黑名单过滤功能，黑名单文件默认放在 C 盘，可按需修改路径。资源包共 34 个文件，约 3.53MB，包含 cpp 与 h 源文件、rc 资源脚本、dsp 与 dsw 工程文件以及 exe 可执行程序，另附 ReadMe 说明，工程可直接用 VC6 打开编译运行。已有 482 人学习下载。读者可据此理解 MFC 对话框程序结构、套接字通信与邮件协议命令的收发过程，并在此基础上补充报文头与正文分离、附件 base64 解码等功能，适合作为课设参考与二次开发起点。

1. 邮件收发器：为什么一个“能发能收”的客户端，难点根本不在界面

很多人第一次接触 MFC 邮件收发器，直觉是“拖几个控件、连上服务器、点按钮就完事”。真正动手才会发现，界面反而是最省事的部分，真正让人翻车的是协议层：SMTP 的对话状态机、POP3 的会话生命周期、Base64 编码的边界、多行响应的解析、附件与正文的 MIME 分层。这些机制藏在“发送成功”四个字背后，任何一处理解偏差都会表现为“邮件发出去了但对方收到乱码”或者“收信卡在 USER 命令之后不动”。SMTP、MFC、C++ 三者凑在一起，本质是把一套文本协议的状态机塞进 Windows 的消息驱动模型里，难点在于协议是同步阻塞的、界面是不能卡的、编码是多层的。搞懂这套底层机制，你再看任何邮件客户端都不会觉得它是黑匣子，而是一串可推演的请求响应序列。这份资源值得深挖的地方，正是它把协议对话和 MFC 封装之间的接缝暴露了出来。

2. SMTP 会话：一封邮件到底经历了多少次请求响应

2.1 从 TCP 连接到 DATA 结束的完整状态迁移

SMTP 是一个纯文本、行导向、请求响应严格交替的协议。客户端连上服务器的 25 或 587 端口后，服务器先发一个220问候，之后每一轮都是客户端发一条命令、服务器回一条或多行响应。一封普通文本邮件的发送，最少要经历这些阶段：EHLO扩展握手、AUTH认证（如果服务器要求）、MAIL FROM声明信封发件人、RCPT TO声明收件人（可多次）、DATA进入正文传输、以单独一行.结束正文、最后QUIT断开。关键在于DATA阶段：它不是一个请求响应，而是一段“流”，服务器回354之后客户端才开始灌正文，直到遇到行首的.才认为正文结束。

常见的实现思路是把这套流程写成一个显式的状态枚举，而不是一串顺序调用。因为服务器随时可能返回4xx临时错误或5xx永久错误，顺序调用一旦某步失败，后面的命令就不该再发。用状态机表达，每个状态只接受特定响应码，非法响应直接终止会话，逻辑才可控。

// 简化的 SMTP 会话状态枚举，每个状态对应一条待发命令或一段等待 enum class SmtpState { Greeting, // 等待 220 Ehlo, // 发送 EHLO，等待 250 多行 Auth, // 可选：AUTH LOGIN，等待 334 挑战 MailFrom, // 发送 MAIL FROM，等待 250 RcptTo, // 发送 RCPT TO，等待 250 Data, // 发送 DATA，等待 354 Body, // 灌正文，等待 250 Quit // 发送 QUIT，等待 221 }; // 每次收到一行响应后，根据响应码决定是否推进状态 bool Advance(SmtpState& st, int code) { switch (st) { case SmtpState::Greeting: return code == 220 ? (st = SmtpState::Ehlo, true) : false; case SmtpState::Ehlo: return code == 250 ? (st = SmtpState::MailFrom, true) : false; case SmtpState::MailFrom: return code == 250 ? (st = SmtpState::RcptTo, true) : false; case SmtpState::RcptTo: return code == 250 ? (st = SmtpState::Data, true) : false; case SmtpState::Data: return code == 354 ? (st = SmtpState::Body, true) : false; case SmtpState::Body: return code == 250 ? (st = SmtpState::Quit, true) : false; default: return false; } }

这段代码的价值不在语法，而在它把“协议合法性”显式化了。Advance的每个分支只认一个成功码，其余一律返回 false，调用方据此决定是重试、报错还是断开。参数code是服务器响应行的前三位数字，SMTP 规定响应行格式为三位数字加空格或连字符再接文本，连字符表示“还有后续行”，空格表示“本响应结束”。多行响应的处理是新手最容易忽略的点：EHLO的回复通常是多行，每行都以250-开头，最后一行才是250，如果只读一行就往下走，后面的扩展信息会被当成下一条命令的响应，整个会话就此错位。

2.2 点填充与行结束符：正文传输的两个隐形陷阱

DATA阶段有两个几乎必踩的坑。第一是行结束符：SMTP 规定正文的每一行必须以 CRLF（\r\n）结尾，而 Windows 上文本框里的换行往往是单独的\n或\r\n混用，直接原样发送会导致服务器按行解析时错位。第二是点填充（dot-stuffing）：正文中任何以.开头的行，发送前必须在行首再加一个.，否则服务器会把这一行误判为正文结束标志。接收端则做反向操作，把行首的..还原成.。

// 发送正文前做 CRLF 规范化和点填充 std::string PrepareBody(const std::string& raw) { std::string out; size_t i = 0; while (i < raw.size()) { // 统一换行：把孤立的 \n 或 \r 都规整成 \r\n if (raw[i] == '\r' && i + 1 < raw.size() && raw[i + 1] == '\n') { out += "\r\n"; i += 2; } else if (raw[i] == '\n' || raw[i] == '\r') { out += "\r\n"; i += 1; } else { out += raw[i]; i += 1; } } // 点填充：行首的 '.' 变成 '..' std::string stuffed; bool atLineStart = true; for (char c : out) { if (atLineStart && c == '.') stuffed += '.'; stuffed += c; atLineStart = (c == '\n'); } return stuffed; }

PrepareBody做了两件事：先把所有换行统一成 CRLF，再逐字符扫描，在每行行首遇到.时补一个点。atLineStart标志在遇到\n后置真，保证判断的是“行首”而不是“任意位置的句点”。这段逻辑看起来琐碎，但它是“邮件正文显示正常”和“对方收到一堆多余空行或截断”之间的分水岭。我一般会这么理解：SMTP 的正文传输层根本不认识“文本”，它只认识“以 CRLF 分隔、以单独一个点结束的行序列”，所有编码和格式问题都要在这一层之上解决。

3. POP3 收信：为什么“收下来”比“发出去”更容易出问题

3.1 USER/PASS 到 RETR 的会话生命周期

POP3 的会话比 SMTP 更简单，但状态约束更死。连接建立后服务器回+OK，进入授权状态，此时只允许USER、PASS、QUIT等少数命令；认证通过后进入事务状态，才能用STAT、LIST、RETR、DELE；最后QUIT进入更新状态，服务器才真正执行删除。这个三状态划分是 POP3 的设计核心，很多实现失败是因为在授权状态就发了RETR，服务器直接回-ERR然后断开。

// POP3 命令发送与响应读取的最小封装 bool Pop3Session::Command(const std::string& cmd, std::string& resp) { std::string line = cmd + "\r\n"; if (send(sock_, line.c_str(), (int)line.size(), 0) <= 0) return false; resp.clear(); char buf[1024]; // 先读第一行，判断是 +OK 还是 -ERR int n = recv(sock_, buf, sizeof(buf) - 1, 0); if (n <= 0) return false; buf[n] = '\0'; resp = buf; // 多行响应（如 RETR 的正文）以单独一行 "." 结束 if (resp.rfind("+OK", 0) == 0 && NeedsMultiline(cmd)) { while (true) { n = recv(sock_, buf, sizeof(buf) - 1, 0); if (n <= 0) return false; buf[n] = '\0'; std::string chunk(buf); if (chunk == ".\r\n" || chunk == ".\n") break; resp += chunk; } } return resp.rfind("+OK", 0) == 0; }

Command的关键在于区分单行响应和多行响应。STAT、LIST（不带参数时其实是多行）、RETR、TOP都可能返回多行，多行响应的结束标志是单独一行.，和 SMTP 的DATA结束标志同源。NeedsMultiline根据命令名判断是否需要继续读，这个判断如果写错，要么把后续响应吞掉，要么把正文当成下一条命令的回复。参数sock_是已连接的套接字，resp累积完整响应供上层解析。注意recv不保证一次读到完整行，真实实现里需要一个按行缓冲的读取器，这里为了突出状态逻辑做了简化。

3.2 邮件头与正文的分离：MIME 分层的第一道门

RETR拿回来的是整封邮件的原始文本，头部和正文之间用一个空行分隔。头部里Content-Type决定正文是纯文本、HTML 还是 multipart，Content-Transfer-Encoding决定正文是 7bit、8bit、base64 还是 quoted-printable。如果头部声明multipart/mixed，正文里会出现boundary分隔符，每一段又是一个独立的头部加正文结构，附件就藏在其中一段里。解析顺序必须是：先按空行切头体，再解析头部字段，再根据Content-Type决定是否递归切分。

这张表里每一行都对应一个真实的解析分支。Subject的 RFC 2047 编码是另一个高频翻车点：形如=?UTF-8?B?5L2g5aW9?=的主题需要先识别编码标记，再对中间部分做 base64 解码，最后按声明的字符集转成宽字符显示。MFC 里通常用CString配合MultiByteToWideChar完成最后一步，但字符集参数必须来自头部声明，写死成 UTF-8 遇到 GBK 编码的旧邮件就会乱码。

4. MFC 封装：同步协议怎么塞进消息驱动的界面

4.1 阻塞套接字与界面卡死的根因

SMTP 和 POP3 都是同步请求响应，最直白的实现是用阻塞套接字，发一条命令就recv等回复。问题在于 MFC 的界面线程同时负责消息泵，一旦在按钮响应函数里阻塞等待网络，消息泵停转，窗口就“未响应”。这不是 MFC 的缺陷，而是把同步 IO 放在 UI 线程的必然结果。常见的两条出路：一是把整个会话放到工作线程，通过PostMessage把进度回传 UI；二是用CAsyncSocket或重叠 IO 做非阻塞，把状态机拆成“发送后立即返回、收到FD_READ再推进”。

工作线程方案更贴近这份资源的实现风格，因为它保留了协议代码的顺序可读性。线程函数里照常写send/recv的顺序逻辑，每完成一个阶段就PostMessage(hWnd, WM_MAIL_PROGRESS, stage, 0)，UI 线程在消息处理里更新进度条或日志框。这样协议层不需要知道界面的存在，界面也不阻塞，两边通过自定义消息解耦。参数stage用枚举值表示当前处于EHLO、AUTH、DATA等哪个阶段，日志框据此显示“正在认证”“正在传输正文”之类的提示。

4.2 Base64 与附件：编码层的责任边界

附件在 SMTP 里不是“文件”，而是被 base64 编码后嵌进 MIME 段落的一段文本。编码的责任边界要划清：协议层只负责把已经编码好的正文按行发送，编码层负责把二进制文件转成 base64 并按 76 字符换行。如果把编码逻辑混进发送循环，一旦附件较大，边读边编码边发送会让状态判断变得极其复杂。更清晰的做法是先构造完整的 MIME 消息体到内存或临时文件，再交给 SMTP 的DATA阶段统一发送。

// 把二进制附件编码为 base64，并按 MIME 要求每 76 字符换行 std::string EncodeBase64(const std::vector<unsigned char>& data) { static const char* tbl = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"; std::string out; int lineLen = 0; for (size_t i = 0; i < data.size(); i += 3) { unsigned int v = data[i] << 16; if (i + 1 < data.size()) v |= data[i + 1] << 8; if (i + 2 < data.size()) v |= data[i + 2]; out += tbl[(v >> 18) & 0x3F]; out += tbl[(v >> 12) & 0x3F]; out += (i + 1 < data.size()) ? tbl[(v >> 6) & 0x3F] : '='; out += (i + 2 < data.size()) ? tbl[v & 0x3F] : '='; lineLen += 4; if (lineLen >= 76) { out += "\r\n"; lineLen = 0; } } if (lineLen != 0) out += "\r\n"; return out; }

EncodeBase64每三个字节拼成一个 24 位整数，再按 6 位一组查表输出四个字符，不足三字节时用=补齐。lineLen控制每 76 字符插入 CRLF，这是 MIME 对 base64 行的建议长度，超过会导致部分老服务器拒收或截断。参数data是原始二进制，输出是纯 ASCII 文本，可以直接拼进 MIME 段落。这里没有做流式处理，是因为附件通常不会大到内存放不下；如果确实要处理超大附件，应该改成按块编码并保持 3 字节对齐，否则跨块的补齐会出错。

5. 避坑与排查：那些让会话莫名中断的细节

5.1 认证阶段卡住不动

现象：日志停在“已发送 AUTH LOGIN”，之后没有任何响应。原因：AUTH LOGIN之后服务器会回334并附带一段 base64 的“Username:”提示，客户端需要先回 base64 编码的用户名，再等一个334，再回 base64 密码。很多实现只发了一次就等最终结果，服务器在等第二段输入，双方互相等待。解决：把认证拆成两个往返，每次收到334才发下一段，且用户名和密码都要单独 base64 编码，不能带换行。

5.2 中文主题变乱码

现象：发出的邮件主题在收件端显示为=?UTF-8?B?5L2g5aW9?=原文。原因：只做了 base64 编码，忘了套 RFC 2047 的=?charset?B?…?=外壳，或者外壳里的字符集写错。解决：编码前先确定源字符串的实际字符集，转成 UTF-8 字节后再 base64，外壳固定写=?UTF-8?B?加?=，且整个编码串长度不宜超过 75 字符，超长要拆成多个编码字。

5.3 收信正文多出空行或点号

现象：RETR下来的正文每行之间多一个空行，或以.开头的行少了一个点。原因：接收端没有做点解填充（把行首..还原为.），或者把 CRLF 又转了一次。解决：解析正文时逐行检查，行首为..的去掉一个点，行首为单个.的视为结束标志；换行统一按 CRLF 处理，不要再用文本模式转换。

5.4 大附件发送到一半连接被重置

现象：附件超过几 MB 时，DATA阶段中途send返回错误或连接被服务器关闭。原因：一次性把整个 base64 正文拼成大字符串再send，单次写入量超过服务器或中间设备的缓冲上限，或者发送超时设置过短。解决：分块发送，每块控制在几十 KB，块与块之间检查send返回值；同时把套接字发送超时调大，并在DATA结束后确认收到250再发QUIT。

5.5 多行响应只读了一行

现象：EHLO之后下一条命令的响应和预期完全对不上。原因：EHLO返回多行250-响应，代码只读了一行就继续发下一条命令，剩余的扩展行被当成新命令的回复。解决：读取响应时判断行内第四位字符，是-就继续读，是空格才停止；POP3 的多行响应则以单独一行.为界，两套规则不能混用。

6. 设计取舍：把协议状态机和界面解耦到什么程度

写到这里，最值得停下来想的是一个取舍：协议层要不要知道 MFC 的存在。一种做法是把 SMTP/POP3 会话写成纯 C++ 类，只依赖套接字和字符串，MFC 只负责调用和展示；另一种是把CAsyncSocket直接继承进会话类，让消息映射驱动状态推进。前者可测试、可移植，但需要自己管理线程和回调；后者与 MFC 贴合紧密，但协议逻辑和窗口句柄纠缠在一起，换个界面框架就得重写。

我倾向于前者，因为邮件协议的复杂度全在状态和编码上，这部分越纯粹越好验证。验证方法也很直接：本地起一个只回固定响应的假服务器，把220、250、354、334这些码按脚本回放，看状态机是否在正确的位置推进、错误码是否被正确终止。这比连真实服务器调试快得多，也不会因为反复登录被临时限制。血泪经验是，很多“服务器抽风”其实是自己多发或少发了一条命令，用假服务器一回放就原形毕露。

从那以后我每次写这类协议客户端，都强制先把会话状态和响应码的对应关系列成一张表，再动手写一行网络代码，表对不上就说明理解还有缺口。这份资源里把 SMTP 和 POP3 两条链路都摆出来的价值，也正在于它们共享同一套“行导向、状态约束、编码分层”的骨架，看懂一条，另一条就是换命令名的事。希望帮到你。

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