简介这份资源是一套基于 MFC 与 C 实现的邮件收发程序源码面向正在做课程设计或需要理解 SMTP、POP3 协议实际编码的学生与初学者。发送端支持发送带附件的邮件附件大小实测约 5MB接收端按编号列出邮件单击即可查看内容并附带黑名单过滤功能黑名单文件默认放在 C 盘可按需修改路径。资源包共 34 个文件约 3.53MB以 cpp、h 源码文件为核心配合 rc 资源脚本、dsp/dsw 工程文件及 exe 可执行程序另含 obj、pdb、sbr 等编译中间文件便于直接打开工程运行与调试。目前已有 482 人学习下载。读者可从中获得一套可运行的邮件客户端原型理解 SMTP 发信与 POP3 收信的代码组织方式并在此基础上自行补充报文头与正文分离、附件 base64 解码等功能适合作为课设参考与协议入门的实践素材。1. 一个把 SMTP 和 POP3 塞进 MFC 对话框的邮件收发器前阵子帮某实验室整理一份老项目需求很朴素在 Windows 上做一个能发邮件、能收邮件的桌面小工具不要浏览器、不要 Electron双击 exe 就能用。翻出来的这份 MFC 邮件收发器正好对上——它用 C 和 MFC 搭界面底层自己实现 SMTP 发信和 POP3 收信两条链路不依赖第三方邮件 SDK。对正在学 C 网络编程、或者要给内部工具加一个「发通知邮件」能力的人来说这东西比看十篇协议科普有用你能看到 socket 怎么连、命令怎么拼、Base64 怎么编码、附件怎么分段。它适合两类人一类是想跑通一个完整 MFC 网络 Demo 的新手一类是想把邮件能力抠出来塞进自己工程的老手。2. 技术选型与工程结构为什么是 MFC 原生 Socket2.1 这套组合在今天的定位先把话说清楚MFC 不是新东西但它在这个场景里有不可替代的性价比。项目要做的是「一个带界面的邮件客户端」界面部分需要列表、编辑框、按钮、进度提示MFC 的对话框模板和控件绑定能把这些活干完而且编译出来是单个 exe拷到没装运行时的机器上装个 VC 运行库就能跑。底层网络部分没有用 CURL、没有用 OpenSSL 封装库而是直接走 Winsock原因也很实际——SMTP 和 POP3 都是纯文本行协议明文端口下就是「连上去、发一行、读一行」用原生 socket 反而最透明出问题能一眼看到收发的原始报文。技术栈可以拆成四层来看层次用的东西承担什么界面层MFC 对话框CDialogEx、CEdit、CListCtrl输入服务器、账号、正文展示收件列表业务层自定义 CMailSender / CMailReceiver 类组装邮件、解析响应、管理状态机协议层SMTP 命令序列、POP3 命令序列EHLO/MAIL FROM/RCPT TO/DATAUSER/PASS/RETR/DELE传输层Winsock2WSAStartup、socket、connect、send、recvTCP 连接与字节流收发这个分层不是摆设。实际改代码时你会发现界面层几乎不用动真正要碰的是业务层和协议层——比如换一个 SMTP 服务器改的是握手命令加附件改的是 MIME 组装。把边界划清楚二次开发才不至于牵一发动全身。2.2 目录结构长什么样这类 MFC 工程的目录结构高度固定基本是向导生成后手工加几个类文件。典型布局如下MailClient/ ├── MailClient.sln ├── MailClient/ │ ├── MailClientDlg.h/.cpp // 主对话框界面逻辑 │ ├── MailClient.rc // 资源脚本对话框模板在这里 │ ├── resource.h // 控件 ID │ ├── MailSender.h/.cpp // SMTP 发信封装 │ ├── MailReceiver.h/.cpp // POP3 收信封装 │ ├── Base64.h/.cpp // 编解码工具 │ ├── MimeBuilder.h/.cpp // 邮件头与正文/附件组装 │ ├── SocketHelper.h/.cpp // connect/send/recv 的薄封装 │ └── stdafx.h / pch.h // 预编译头 └── README.md几个文件的分工值得单独说。SocketHelper是最底层负责把「连接某个 host:port」和「读一行直到 CRLF」这两件事封装成函数上层不直接碰 socket 句柄。Base64独立出来是因为 SMTP 的认证AUTH LOGIN和邮件正文编码都要用单独一个文件方便复用和单测。MimeBuilder是很多人容易忽略的部分——邮件不是「标题 正文」这么简单它有头部字段、有 Content-Type、有 boundary 分隔的多段结构把这部分抽出来发信逻辑才不会变成一坨字符串拼接。2.3 工程配置里两个必须改的地方新建或打开工程后有两处配置不改编译能过但运行必挂。第一处是字符集。MFC 默认可能是 Unicode而 SMTP 协议本身是 ASCII 行协议中文主题和正文必须经过编码Base64 或 quoted-printable再发。工程属性里把「字符集」设成「使用 Unicode 字符集」代码里统一用CStringW处理界面文本发出去之前再转 UTF-8 或 GBK 编码这个转换点要卡死否则收件人看到的就是乱码。第二处是链接库。Winsock 需要显式链接ws2_32.lib在「链接器 → 输入 → 附加依赖项」里加上或者在代码里用#pragma comment(lib, ws2_32.lib)。后者更省事跟着源文件走换台机器也不会漏。// pch.h 或任意公共头文件里加这一行 #pragma comment(lib, ws2_32.lib) // 程序启动时初始化 Winsock退出时清理 WSADATA wsaData; if (WSAStartup(MAKEWORD(2, 2), wsaData) ! 0) { AfxMessageBox(_T(Winsock 初始化失败)); return FALSE; } // ... 主对话框 DoModal ... WSACleanup();WSAStartup的版本参数用MAKEWORD(2, 2)表示请求 Winsock 2.2这是目前 Windows 上的通用版本。WSACleanup必须和它配对放在InitInstance的退出路径上。血泪经验是如果只在对话框的OnInitDialog里初始化、忘了在程序退出时清理反复调试时偶尔会遇到端口占用或句柄泄漏虽然不致命但排查起来很烦。3. SMTP 发信链路从点「发送」到服务器返回 2503.1 一次完整会话的命令序列SMTP 是「一问一答」的文本协议客户端发一行命令服务器回一个三位数字状态码加说明。发一封普通文本邮件的完整序列是这样的S: 220 smtp.example.com ESMTP C: EHLO myclient S: 250-smtp.example.com S: 250 AUTH LOGIN PLAIN C: AUTH LOGIN S: 334 VXNlcm5hbWU6 C: base64(用户名) S: 334 UGFzc3dvcmQ6 C: base64(密码) S: 235 Authentication successful C: MAIL FROM:senderexample.com S: 250 OK C: RCPT TO:receiverexample.com S: 250 OK C: DATA S: 354 Start mail input C: 邮件头 空行 正文 . S: 250 Message accepted C: QUIT S: 221 Bye看懂这张表整个发信模块就懂了一半。EHLO是扩展握手服务器会列出支持的能力比如 AUTH 认证方式AUTH LOGIN之后服务器回334并给出 Base64 编码的提示串客户端把用户名、密码分别 Base64 后发过去DATA之后进入「正文模式」直到单独一行.才结束。这里有个经典坑如果正文里本身有一行以.开头必须写成..这叫 dot-stuffing不做的话邮件会被截断。3.2 核心发送函数逐段拆下面这段是发信模块的主干把「连接 → 握手 → 认证 → 投递」串起来。为了聚焦逻辑省略了部分错误分支。bool CMailSender::SendMail(const MailContext ctx) { // 1. 建立 TCP 连接SMTP 默认 25 端口SSL 端口是 465 if (!m_sock.Connect(ctx.server, ctx.port)) { m_lastError _T(连接服务器失败); return false; } // 2. 读欢迎语必须以 220 开头 CString resp m_sock.ReadLine(); if (resp.Left(3) ! _T(220)) { m_lastError _T(服务器未返回 220: ) resp; return false; } // 3. EHLO 握手拿到服务器能力列表 m_sock.SendLine(_T(EHLO myclient)); resp m_sock.ReadMultiLine(); // 250- 开头的多行响应 // 4. 认证AUTH LOGIN 走 Base64 用户名/密码 m_sock.SendLine(_T(AUTH LOGIN)); resp m_sock.ReadLine(); // 期望 334 m_sock.SendLine(CBase64::Encode(ctx.user)); // 用户名 resp m_sock.ReadLine(); // 期望 334 m_sock.SendLine(CBase64::Encode(ctx.password)); // 密码 resp m_sock.ReadLine(); // 期望 235 if (resp.Left(3) ! _T(235)) { m_lastError _T(认证失败: ) resp; return false; } // 5. 信封发件人、收件人 m_sock.SendLine(_T(MAIL FROM:) ctx.from _T()); if (!Expect(m_sock.ReadLine(), _T(250))) return false; for (const auto rcpt : ctx.toList) { m_sock.SendLine(_T(RCPT TO:) rcpt _T()); if (!Expect(m_sock.ReadLine(), _T(250))) return false; } // 6. DATA 投递正文 m_sock.SendLine(_T(DATA)); if (!Expect(m_sock.ReadLine(), _T(354))) return false; CString body CMimeBuilder::Build(ctx); // 头部 空行 正文 body DotStuff(body); // 处理行首的点 m_sock.SendRaw(body); m_sock.SendLine(_T(.)); // 单独一行点结束投递 if (!Expect(m_sock.ReadLine(), _T(250))) return false; // 7. 礼貌退出 m_sock.SendLine(_T(QUIT)); m_sock.ReadLine(); return true; }逐段说逻辑。第 1 步的Connect内部就是socketconnect超时时间建议设 10 秒太短在弱网下容易误判太长界面会卡死——所以这个函数要么放工作线程要么在连接前把界面按钮置灰。第 2 步读欢迎语ReadLine要一直读到\r\n为止不能假设一次recv就能收全TCP 是字节流半包是常态。第 3 步的ReadMultiLine是专门处理250-这种多行响应的服务器用250-表示「还有下一行」用250空格表示「最后一行」。这个细节不处理后面读认证响应就会错位表现为「认证明明成功却报失败」属于典型翻车点。第 4 步的认证AUTH LOGIN之后服务器返回的334后面跟的是 Base64 的提示语VXNlcm5hbWU6解码就是Username:客户端不需要解析它直接按顺序发用户名、密码即可。注意 Base64 编码的是原始字节中文用户名要先转 UTF-8 再编码。第 5 步的MAIL FROM和RCPT TO是「信封」信息和邮件头里的From/To是两回事——信封决定投递路由头部决定收件人看到什么。多个收件人就多次RCPT TO每次都要检查250。第 6 步的DATA之后服务器回354表示「可以开始发正文了」然后客户端把整封邮件头部 空行 正文发过去最后单独发一行.。DotStuff的作用前面提过把正文里行首的.变成..服务器收到后再还原。3.3 邮件头与 MIME 组装CMimeBuilder::Build负责拼出符合 RFC 5322 的邮件。最小可用的头部包含From、To、Subject、Date、MIME-Version、Content-Type。中文主题不能直接写要用?UTF-8?B?base64?的形式编码CString CMimeBuilder::EncodeHeader(const CString text) { // 中文主题按 RFC 2047 编码?charset?B?base64? CStringA utf8 CT2A(text, CP_UTF8); CStringA b64 CBase64::Encode(utf8); CString result; result.Format(_T(?UTF-8?B?%s?), CString(b64)); return result; } CString CMimeBuilder::Build(const MailContext ctx) { CString mail; mail _T(From: ) ctx.from _T(\r\n); mail _T(To: ) JoinAddress(ctx.toList) _T(\r\n); mail _T(Subject: ) EncodeHeader(ctx.subject) _T(\r\n); mail _T(Date: ) RfcDate(CTime::GetCurrentTime()) _T(\r\n); mail _T(MIME-Version: 1.0\r\n); mail _T(Content-Type: text/plain; charsetUTF-8\r\n); mail _T(Content-Transfer-Encoding: base64\r\n); mail _T(\r\n); // 头与正文的分隔空行 mail CBase64::Encode(CT2A(ctx.body, CP_UTF8)); return mail; }EncodeHeader里CT2A(text, CP_UTF8)把宽字符转成 UTF-8 字节再 Base64最后套上?UTF-8?B?...?的壳。Build里每一行都以\r\n结尾这是协议硬要求用\n单独结尾在某些服务器上会被判为格式错误。头与正文之间必须有一个空行即连续两个\r\n少了这个空行服务器会把正文当成头部字段解析收件人看到的是一堆乱码。正文用 Base64 编码是最省事的做法避免了 8bit 传输和行长度限制的问题。代价是体积膨胀约 33%对纯文本邮件无所谓。如果要加附件就得升级成multipart/mixed用 boundary 分隔正文段和附件段每段有自己的Content-Type和Content-Transfer-Encoding——这是二次开发里最常见的扩展点后面第 5 章会展开。4. POP3 收信链路把邮件从服务器拉回列表4.1 收信和发信的本质差别发信是「我推给服务器」收信是「我从服务器拉」。POP3 的会话模型更简单连接、认证、列清单、逐封取、删或留、退出。它没有 SMTP 那么多扩展命令状态码也只有OK和-ERR两种解析起来反而轻松。但收信的复杂度在「取回来之后怎么解析」——一封原始邮件是一大段文本头部、正文、编码、多段结构全混在一起得自己拆。4.2 会话流程与核心代码一个典型的 POP3 会话S: OK POP3 server ready C: USER alice S: OK C: PASS **** S: OK Logged in C: STAT S: OK 3 10240 C: LIST S: OK 3 messages S: 1 3200 S: 2 3500 S: 3 3540 S: . C: RETR 1 S: OK 3200 octets S: 原始邮件内容 S: . C: QUIT S: OK ByeSTAT返回邮件数量和总字节数LIST返回每封的编号和大小RETR n取第 n 封内容以单独一行.结束。注意LIST和RETR的响应都是多行读到.为止这个「点结尾」规则和 SMTP 的 DATA 一致。bool CMailReceiver::FetchAll(std::vectorMailItem outList) { if (!m_sock.Connect(m_server, m_port)) return false; // 欢迎语 OK if (!IsOk(m_sock.ReadLine())) return false; // 认证 m_sock.SendLine(_T(USER ) m_user); if (!IsOk(m_sock.ReadLine())) return false; m_sock.SendLine(_T(PASS ) m_password); if (!IsOk(m_sock.ReadLine())) return false; // 先拿总数 m_sock.SendLine(_T(STAT)); CString stat m_sock.ReadLine(); // OK 3 10240 int total ParseCount(stat); // 逐封取回 for (int i 1; i total; i) { CString cmd; cmd.Format(_T(RETR %d), i); m_sock.SendLine(cmd); if (!IsOk(m_sock.ReadLine())) continue; CString raw m_sock.ReadUntilDot(); // 读到单独一行 . 为止 MailItem item; if (ParseMail(raw, item)) { // 解析头部与正文 outList.push_back(item); } } m_sock.SendLine(_T(QUIT)); m_sock.ReadLine(); return true; }ReadUntilDot是关键工具函数内部循环recv并按行判断遇到内容恰为.的行就停。这里同样有 dot-stuffing 的反向处理服务器发来的..要还原成.。ParseMail负责把原始文本拆成头部字段和正文头部按Key: Value逐行解析遇到空行就切到正文正文再根据Content-Transfer-Encoding决定是否 Base64 解码。4.3 头部解析与编码还原收信侧最容易出问题的是编码还原。发信时主题用 RFC 2047 编码收信时得反向解回来否则列表里显示的就是?UTF-8?B?5rWL6KV?这种东西。CString CMailReceiver::DecodeHeader(const CString raw) { // 匹配 ?charset?B?base64? 形式 int p1 raw.Find(_T(?)); int p2 raw.Find(_T(?), p1); if (p1 0 || p2 0) return raw; CString inner raw.Mid(p1 2, p2 - p1 - 2); // UTF-8?B?xxxx int q1 inner.Find(_T(?)); int q2 inner.Find(_T(?), q1 1); CString charset inner.Left(q1); CString enc inner.Mid(q1 1, q2 - q1 - 1); CString payload inner.Mid(q2 1); if (enc.CompareNoCase(_T(B)) 0) { CStringA bytes CBase64::Decode(payload); return CString(CA2T(bytes, CP_UTF8)); } return raw; // Q 编码或未知编码按原样返回 }这段先定位?和?取出中间的charset?encoding?payload三段B表示 Base64解码后按 UTF-8 转回宽字符。实际邮件里可能有多个编码片段拼接长主题会被拆成多段完整实现要循环处理这里给的是单段版本够覆盖大多数场景。Q编码quoted-printable在中文邮件里也常见特征是E4BDA0这种形式需要另写一个解码函数把XX还原成字节。5. 避坑与排查那些让邮件发不出去、收不回来的细节5.1 认证成功但发信被拒现象日志里235 Authentication successful明明出现了紧接着MAIL FROM却返回550或553。原因通常不是认证而是发件人地址和认证账号不匹配。很多 SMTP 服务器要求MAIL FROM的域名与登录账号一致防止冒名发信。解决方法是把发件人地址固定成登录账号本身或者在服务器侧把该账号加入白名单。排查时把完整的命令与响应打日志一眼就能看出是哪一步被拒。5.2 中文正文变乱码现象收件人收到的正文是一串看不懂的字符或者显示成5L2g5aW9。原因有两个层面一是发送前没做 Base64 或没声明charsetUTF-8二是做了 Base64 但源字节是 GBK 而不是 UTF-8收件端按 UTF-8 解就错。解决方法是统一在「转字节」这一步用CP_UTF8并且头部Content-Type里明确写charsetUTF-8。改完拿自己邮箱发一封给自己用「显示原始邮件」功能核对编码声明和实际字节是否一致。5.3 连接超时或卡在欢迎语现象点发送后界面无响应十几秒后报连接失败。原因多半是端口或加密方式不对。25 端口是明文 SMTP很多服务器已经关闭或只对内网开放465 是隐式 SSL需要先做 TLS 握手再走 SMTP直接明文连会一直等不到220。这份工程默认走明文如果目标服务器强制加密就得引入 TLS 层比如用 Windows 自带的 SChannel这不是改几行能解决的属于架构级改动。排查时先用telnet 服务器 端口看能不能收到欢迎语能收到说明网络通问题在协议层。5.4 多行响应解析错位现象EHLO 之后读到的内容不完整后续认证步骤全部对不上。原因是ReadLine只读了一行而 EHLO 的响应是多行250-开头若干行最后一行250空格开头。解决方法是实现ReadMultiLine循环读直到遇到「三位码 空格」的行。这个坑在换服务器时特别容易触发因为不同服务器返回的能力列表行数不一样本地测试用的服务器可能只回两行换个服务器回八行就崩了。5.5 附件收下来打不开现象带附件的邮件能收到但附件文件损坏或大小为 0。原因通常是 Base64 解码时把换行符也当数据算了或者 boundary 切分时把结尾的--也算进内容。解决方法是解码前先剔除所有\r\n切分 multipart 时严格按--boundary和--boundary--定位段落边界每段去掉首尾空行再解码。这类问题没有捷径只能拿一封真实的多段邮件当样本把中间结果打出来逐段比对。6. 二次开发把邮件能力抠出来复用的几个改法6.1 先做「可替换的传输层」如果打算长期维护第一件事是把SocketHelper抽象成接口让明文 socket 和 TLS socket 实现同一个接口。这样以后要支持 465 端口只需要加一个TlsSocket实现上层CMailSender一行不用改。接口大致是Connect / Send / ReadLine / ReadUntilDot / Close五个方法现有代码里的调用点全部改成面向接口。这个重构花不了半天但能省掉后面无数次「换个服务器就要改一遍」的麻烦。6.2 加附件从 text/plain 升级到 multipart/mixed附件是最高频的扩展需求。改法是在CMimeBuilder里加一个分支当ctx.attachments非空时头部Content-Type改成multipart/mixed; boundary----_Boundary_001正文部分先输出一段--boundary加文本段再对每个附件输出--boundary加附件段含Content-Disposition: attachment; filename...和 Base64 内容最后以--boundary--收尾。文件名同样要做 RFC 2047 编码否则中文文件名在部分客户端会丢。改完务必用「自己发给自己 主流客户端打开」验证别只在一家客户端上测。6.3 收信侧加「只取头部」的优化现在FetchAll是每封都RETR全量拉回邮件多了会很慢。POP3 有个TOP n 0命令只取第 n 封的头部和 0 行正文用来填充列表足够。改法是列表阶段用TOP用户点开某封时再RETR全量。这个优化对体验提升明显尤其是收件箱有几百封的时候。改造点改动文件验证方式传输层抽象SocketHelper.h/.cpp明文与 TLS 各跑一遍发信附件支持MimeBuilder.cpp发带附件邮件客户端能打开列表懒加载MailReceiver.cpp百封邮件下列表秒出6.4 一个我踩过的验证习惯最后说个教训。早期我改完编码逻辑只拿英文主题测一切正常上线后中文主题全乱。后来养成一个死规矩任何涉及编码的改动必须用「中文主题 中文正文 中文附件名」三件套各发一封并且用两个不同客户端打开核对。从那以后我每次动MimeBuilder或Base64都强制走一遍这个三件套再没在编码上翻过车。这份工程的骨架不复杂真正值钱的是这些协议细节和踩坑记录拿去改改就能变成自己项目里的邮件模块。希望帮到你。本文还有配套的精品资源点击获取