简介：Foxmail Server For Windows v2.0 公测版面向需要在 Windows 环境体验和验证邮件服务器部署的个人用户、小型运维人员及邮件系统学习者，提供 SMTP、POP3、LDAP 等基础邮件服务，并支持通过 Foxmail、Outlook Express 等客户端或全中文 Web 界面收发与管理邮件，便于在测试环境中了解邮件系统的基本运行流程和管理方式。压缩包共 2 个文件，主要为 1 个 exe 安装程序和 1 个 htm 说明文档，整体约 7.9MB，安装包用于部署服务端，说明文档可用于辅助查阅版本信息与使用限制。已有 286 人学习。需要留意该版本标注为公测测试用途，附带产品号、8 用户数和序列号，官方不予注册且不承诺技术支持与升级，因此更适合功能试用、环境验证和邮件服务入门研究，不宜直接用于正式生产。读者可据此搭建小型测试环境，观察客户端收发、Web 登录处理邮件及基于网页的管理维护流程，并理解多线程、异步 Socket、队列等机制所对应的邮件投递场景。

1. 一台闲置的 Windows 机器加一个 rar：先把预期摆正

上周有人给我发了个压缩包，文件名是Foxmail Server For Windows v2.0 公测版.rar，问能不能把它装起来当公司内网的邮件服务器用。我的回答是：能装，但你先想清楚要它干什么。这套东西是 Windows 平台上早期的一体化邮件服务器软件，一个安装包把 SMTP、POP3、Webmail、域与账号管理控制台全塞进去了，装完就有图形界面可以点，不用自己拼 Postfix 那一套。它的价值不在性能，而在于“可控、可离线、可讲清楚每一封邮件去了哪”——内网通知、老设备告警邮件、协议教学、遗留系统对接，这些场景它够用。但反直觉的是，真正决定它能不能跑起来的从来不是软件本身，而是 DNS 记录、25 端口和目录权限。下面按我实际拆装的顺序走一遍。

2. 拆包与环境准备：v2.0 公测版在什么系统上还能起来

先说结论：想少踩坑，别在宿主机的新系统上硬刚，开一台虚拟机装老 Windows 更省事。v2.0 是 32 位时代的产物，它的服务进程、依赖库、注册表写法都按 NT 内核那套来，放在 64 位新系统上跑不是完全不行，但你会花大量时间在兼容模式、UAC 和权限继承上，收益极低。我给自己的规矩是：任何一次拆包都在虚拟机里做，装完打快照，配置改坏了三十秒回滚，这比事后翻日志找原因便宜太多。

2.1 安装包里都有什么，先看一眼再双击

rar 解出来的目录结构大同小异，别急着点 setup，先把文件过一遍。老安装包最容易出问题的地方是解压路径里有中文或空格，某些 cab 解压时会截断路径导致安装到一半报“找不到文件”。我一般直接解到D:\pkg\mail20\这种纯英文短路径下再执行。

这张表不是让你背，而是让你在装之前心里有数：看到webmail目录，就知道后面一定要处理 HTTP 服务和虚拟目录权限；看到tools，就知道账号批量导入有官方路子，不用自己写脚本怼数据库。

2.2 系统的选择：虚拟机里跑老系统比在新系统上硬刚更省事

我的常规组合是虚拟机 + Windows 2000 Server 或 Windows 2003，内存给 1GB、磁盘给 20GB 就够跑几十个账号的测试环境。选这两个版本的原因是它们自带 IIS 的 SMTP 虚拟服务器组件，而这套邮件服务器在部分部署方式下会复用系统自带的 SMTP 服务做投递队列，两者版本对得上，行为才可预期。

如果你非要在新系统上试，至少要提前确认三件事：一是安装程序能不能以兼容模式启动，二是它注册的系统服务能不能被 SCM 接受，三是它写入的目录是不是落在Program Files下面。第三点最坑，老程序往往往自己的安装目录里写运行时数据，而新系统的 UAC 会把这类写入重定向到VirtualStore，结果就是你在配置里改了参数，重启后它读的还是旧值，那种“改了不生效”的玄学问题多半出在这。

# 确认系统版本与位数，决定走虚拟机方案还是直接装 systeminfo | Select-String "OS 名称","OS 版本","系统类型" # 输出里 "x86-based PC" 说明是 32 位系统，兼容性最好

这段不是走过场。我见过有人在一台 64 位系统上折腾了一下午，最后发现是某个 16 位的老安装引导程序直接被系统拒绝执行，早点看清位数能省掉半天。

2.3 端口、目录与权限的前置检查

邮件服务器的端口冲突是最高频的启动失败原因，而且报错信息通常只有一句“服务启动失败”，不看端口根本猜不到。装之前先把 25（SMTP）、110（POP3）、143（IMAP）、80（Webmail）、以及管理控制台用的高位端口全部查一遍。

# 查看关键端口是否已被占用；最后一列是进程 PID netstat -ano | findstr ":25 " netstat -ano | findstr ":110 " netstat -ano | findstr ":143 " netstat -ano | findstr ":80 " # 根据 PID 反查是谁占的 Get-Process -Id <PID> | Select-Object ProcessName, Path

如果占着 25 端口的是系统自带的SMTPSVC，处理方式取决于你的部署模式：单纯用这套软件自己的投递引擎，就把系统 SMTP 停掉并禁用；如果要用它接管系统 SMTP 的队列，就保留，但要把两者的域配置对齐。我的习惯是先停掉自带服务，排除一个变量。

:: 停掉并禁用系统自带 SMTP，避免和邮件服务器抢 25 端口 net stop SMTPSVC sc config SMTPSVC start= disabled :: 顺带确认服务状态，SERVICE_STOPPED 才算干净 sc query SMTPSVC

目录规划我一般分三块：store放邮件正文与附件，log放收发日志，backup放导出文件。三块分开的理由很实在——日志和邮件混在一个目录里，磁盘写满时你连删什么都不知道。建目录之后必须授权，邮件服务进程通常以低权限账户或系统账户运行，如果存储目录的 ACL 只给了管理员，服务能启动但一收信就报“写入失败”。

# 建三个独立目录，避免日志把邮件分区撑爆 New-Item -ItemType Directory -Path D:\MailSrv\store, D:\MailSrv\log, D:\MailSrv\backup -Force # 给 IIS 匿名账户和 NETWORK SERVICE 授读写权限（OI/CI 表示继承到子项） icacls D:\MailSrv /grant "IIS_IUSRS:(OI)(CI)M" icacls D:\MailSrv /grant "NETWORK SERVICE:(OI)(CI)M" # 复核授权结果 icacls D:\MailSrv

这里容易忽略(OI)(CI)两个继承标志。只给目录本身授权限，新建的用户邮件子目录不会继承，结果是第一个账号能用、第二个账号收信就失败，现象极其迷惑。

2.4 安装顺序与首次启动的检查点

顺序上我固定按“停冲突服务 → 装主程序 → 装 Webmail → 配服务账户 → 启动并验证监听”走。安装向导里如果有“自定义”选项，务必选它，把安装目录改到短路径（例如D:\MailSrv\app），把数据目录指到刚才建好的store。默认装进带空格的路径，后面写脚本做备份时每一处路径都要加引号，漏一处就断。

启动之后别急着建账号，先按四个检查点过一遍：服务列表里有没有新增服务且状态为 Running；netstat里 25/110 是否处于 LISTENING；管理控制台能不能用浏览器打开；日志目录里有没有新生成的文件。

# 检查点：服务是否真的起来了 Get-Service | Where-Object { $_.DisplayName -match "mail|smtp|pop" } | Format-Table Name, Status, StartType # 检查点：端口是否在监听 netstat -ano | findstr "LISTENING" | findstr ":25 :110 :143"

四个检查点里任意一个不过，就不要往下走。老软件的错误往往在启动阶段就埋下了，你带着一个半死的服务去配域名和账号，后面所有现象都是叠加的，排查成本翻倍。

3. 域名、账号与投递链路：把一封内网邮件送完整

软件装起来了，接下来才是真正决定它“能不能用”的部分。邮件系统的配置逻辑和 Web 应用不一样，它不是点一下保存就完事，而是要把域名、账号、投递路由、客户端协议四条线同时打通，缺一条就会出现“能发不能收”或者“收得到但客户端连不上”的怪现象。这一章按最小可用路径来，先让一封内网邮件从 A 账号走到 B 账号，再考虑往外发。

3.1 管理控制台入口与第一件事：改口令、限来源

管理控制台一般通过浏览器访问，地址形如http://<服务器IP>:<管理端口>/，首次登录用安装时设的或文档里写的默认管理员账号。进去之后第一件事不是建域，而是改管理员口令并把访问来源限制到内网网段。这类早期控制台的默认口令在公开文档里到处都是，暴露在可访问网段上等于把整台服务器的收发权限交出去。

访问控制通常有两层可做：一是控制台自身配置里的“允许管理的 IP 段”，二是在服务器防火墙上只放行内网到管理端口。两层都做，别只做一层，因为配置文件被改回去的概率不低。

# 只允许内网网段访问管理端口（示例端口 8383，按实际改） New-NetFirewallRule -DisplayName "MailAdmin-InternalOnly" -Direction Inbound ` -Protocol TCP -LocalPort 8383 -RemoteAddress 10.10.20.0/24 -Action Allow # 其余来源一律阻断 New-NetFirewallRule -DisplayName "MailAdmin-BlockAll" -Direction Inbound ` -Protocol TCP -LocalPort 8383 -RemoteAddress Any -Action Block

规则顺序上，允许规则要排在阻断之前，否则内网也进不来。用命令行建规则的好处是可复现——换台机器重装时把这段贴过去就行，不用回忆当初点的是哪个勾。

3.2 建域名与账号：主域、别名、群组、配额

域名这一步决定了邮件的地址后缀。内网环境我一般用一个不可能和公网撞车的域名，比如mail.demo-lab.local，好处是永远不会误投到真实互联网上，测试时也不会不小心给外部地址发信。域建好之后才开始建账号。

账号相关的字段不多，但每一个都影响行为：

配额这一项别设成“无限制”。早期版本的存储是按用户目录下的单文件增长的，一旦某个账号被大量告警邮件灌满，磁盘满了以后是整个服务假死，不是单个账号不可用。给每个账号设上限，等于给自己留了后悔药。

批量建账号时用安装包tools目录里的导入程序，通常吃一个固定格式的文本文件，一行一个账号。手工在界面上点五十个账号是纯粹的浪费，而且一定会漏。

# accounts.txt 示例：账号,密码,配额MB,显示名 ops-alert,P@ssw0rd-2024,100,告警邮箱 dev-a,Tmp#8341kL,200,开发A dev-b,Tmp#8342mN,200,开发B

导入前先拿两行试一遍，确认分隔符和编码对得上。这类老工具的编码坑很固定：文件必须是 ANSI 或 GBK，用 UTF-8 保存的中文显示名会变成乱码，而且它不报错，只是存进去就是乱码。

3.3 SMTP 参数：中继开关、大小限制、HELO 标识

SMTP 侧的配置项看着多，真正影响可用性的就四个：监听地址、最大邮件大小、单连接最大收件人数、以及中继（Relay）策略。

中继策略是这套系统里最危险的一个开关。它的语义是“允许哪些客户端通过我向非本地域投递邮件”。如果设成允许所有客户端，这台服务器就变成了开放中继，只要它能被外网访问，几天之内就会被扫到并用来发垃圾邮件，然后你的 IP 进各种黑名单。内网部署正确做法是：只允许本机网段，或者只允许通过认证的用户中继。

; SMTP 段配置示例（字段名以实际配置文件为准） [SMTP] ListenAddr=0.0.0.0 Port=25 MaxMessageSize=20971520 ; 单封邮件上限 20MB，按需下调 MaxRecipients=50 ; 单次投递最大收件人数 HeloDomain=mail.demo-lab.local ; HELO/EHLO 里报的域名，必须和 A 记录一致 RequireAuthForRelay=1 ; 中继必须认证，别关 RelayAllowList=10.10.20.0/24 ; 仅内网网段可免认证中继 QueueRetryInterval=15 ; 队列重试间隔（分钟） QueueRetryMax=48 ; 重试次数上限，超了退信

HeloDomain这一项容易被随手填成机器名。填机器名的后果是外发邮件在对方服务器上做 HELO 校验时对不上，被判为可疑，退信理由还写得很含糊。把它写成与邮件域一致的域名，是成本最低的一步修正。

MaxMessageSize和MaxRecipients的取值要和客户端习惯匹配。附件上限设 20MB，实际能传的附件大概 14MB 左右（Base64 编码膨胀约 33%），跟用户解释清楚，能省掉很多“为什么 18MB 的附件发不出去”的工单。

3.4 POP3 与客户端参数对照：把账号真的连上

服务端配完，要用客户端实测。早期版本基本只提供 POP3 和 SMTP，IMAP 支持视版本而定，SSL/TLS 通常没有。客户端填的参数就那么几项，但填错一项就是连不上：

“账号格式填不填 @域名”这一条我踩过。同一个版本，Webmail 登录只要账号名，POP3 客户端要完整地址，配置界面上没有任何提示。判断方法是看服务端日志里的认证失败记录，它会打印出实际收到的用户名字符串，一眼就能看出差在哪。

3.5 用 telnet 手工走一遍 SMTP 会话

图形客户端会隐藏太多细节，验证投递链路我习惯直接用 telnet 说 SMTP 协议。它能把“到底是认证失败、还是收件人被拒、还是投递超时”三类问题区分开，比看客户端弹窗快得多。

# 连接服务器的 25 端口，逐行输入下面的命令（EHLO/MAIL/RCPT/DATA 为协议关键字） telnet mail.demo-lab.local 25 EHLO demo-lab.local MAIL FROM:<ops-alert@mail.demo-lab.local> RCPT TO:<dev-a@mail.demo-lab.local> DATA Subject: test-001 From: ops-alert@mail.demo-lab.local To: dev-a@mail.demo-lab.local hello from telnet . QUIT

几个关键回应码要认得住：220是服务就绪，250是命令被接受，354表示可以开始输入正文，451/452是临时失败（多为队列或磁盘问题），550是收件人不存在或被策略拒绝。如果RCPT TO阶段就返回550，问题一定在账号或域配置上，跟网络无关；如果DATA之后卡住几十秒再超时，那是投递侧的问题，去看队列目录和日志。

投递成功后到D:\MailSrv\store下找对应用户目录，能看到新生成的邮件文件，文件头里包含完整的 Received 链。这条链是后面排查所有投递问题的基础，每一跳都会留一行记录，谁转的、什么时候转的、用的什么协议，全在里面。

4. DNS 四条记录与过滤规则：外发不被拒的关键

内网自娱自乐怎么都能通，一旦要往外发信，问题就全冒出来了。外发被拒的原因九成不在软件，而在域名侧的身份信息不完整。这套公测版本身不具备现代邮件认证能力（SPF 校验、DKIM 签名基本没有），所以能做的只有把外部条件准备到位，让它至少看起来像个正常的发信方。

4.1 A、MX、PTR 三者的对应关系

这三条记录的关系必须自洽，任何一条对不上都会导致退信或进垃圾箱。

自建环境里最常缺的是 PTR。A 记录你能在内部 DNS 上随便加，PTR 却要 IP 归属方配合，很多内网地址段根本没有反向解析区。没有 PTR 的直接后果是对方服务器做正反查一致性校验时对不上，邮件被降权甚至直接拒收，退信理由往往是“反向解析不存在”或“HELO 域不匹配”。

# 逐条验证，输出为空或 NXDOMAIN 就说明记录缺失 nslookup -type=mx demo-lab.local nslookup mail.demo-lab.local nslookup x.x.x.x # 反查，结果应等于 mail.demo-lab.local nslookup -type=txt demo-lab.local

四条都验证通过再谈外发。少一条就开始发，你会在接下来的几天里反复收到零散的退信，而每次退信来自不同服务商、理由措辞还不一样，排查起来非常折磨。

4.2 SPF 与 HELO 一致性：公测版最容易露馅的地方

SPF 记录本身只是一条 TXT，写起来简单，难的是和服务器实际行为对上。这套软件在HeloDomain里报的域名、MAIL FROM里的 envelope 域名、以及 SPF 记录覆盖的域名，三者最好一致。假设 SPF 写的是v=spf1 ip4:203.0.113.10 -all，但服务器实际出口 IP 是另一个地址（比如经过了一层 NAT 或前置网关），那 SPF 校验必然失败，-all的硬失败会直接导致拒收。

排查方法很直接：从服务器上往外发一封测试信到自己的外部邮箱，看邮件头里Received链上记录的来源 IP 到底是什么，再拿这个 IP 去比对 SPF 里的 ip4 值。不要相信配置文件里写的监听地址，那是本机视角，不是对端视角。

# 在服务器上确认真正出口 IP，避免 SPF 写错地址 curl -s https://ifconfig.me # 拿到的地址必须与 SPF 记录里的 ip4 完全一致

公测版还有个隐性限制：它不会自动添加Message-ID或规范的Date头，部分严格的反垃圾网关会因此扣分。这种属于软件能力边界，改不了，只能靠“只往信任的内外部域发信”来规避。

4.3 黑白名单与附件过滤的落地配置

过滤规则分三层：连接层（按 IP 拒绝）、发信人层（黑白名单）、内容层（关键词、附件类型、大小）。三层里性价比最高的是连接层，因为它在建立会话阶段就断开，不消耗存储。

; 过滤相关配置示例 [Filter] BlackIPList=198.51.100.0/24,203.0.113.66 ; 明确拒绝的来源网段 WhiteIPList=10.10.20.0/24 ; 内网设备全部放行，避免误杀告警邮件 MaxAttachSize=15728640 ; 附件上限 15MB，与 SMTP 限制联动 BlockExtList=exe,bat,cmd,scr,vbs ; 危险附件后缀，逗号分隔 KeywordFilter=测试关键词1,测试关键词2 ; 关键词命中后打标或隔离

白名单必须配。内网监控系统每天定时发告警邮件，一旦被关键词规则误判进隔离区，故障告警就彻底失联了，这种事故比垃圾邮件本身严重得多。我的做法是先把内网网段整体加白，再对白名单之外的流量启用全部规则。

关键词过滤在中文环境下要留意编码问题。老版本对 UTF-8 正文的解码能力有限，中文关键词可能匹配不上，实际生效的往往只有英文和数字关键词。需要拦中文内容时，改成按附件类型和发件域做策略更可靠。

4.4 队列与日志：出问题时先看这三处

邮件系统的可观测性就三块：队列目录、收发日志、服务事件日志。任何“发了没到”“收到了重复”的问题，按这个顺序看，基本三轮内能定位。

队列目录里堆着的就是待投递的邮件，每个文件通常带一个状态后缀或状态行。文件数量持续增长说明出口不通或对端拒收，这时去看日志里的连接错误；文件数量正常但个别文件长期不消失，说明是死信，需要手工重投或清理。

# 看队列积压情况：文件数量与最老文件的时间 $q = "D:\MailSrv\queue" (Get-ChildItem $q -File -ErrorAction SilentlyContinue).Count Get-ChildItem $q -File -ErrorAction SilentlyContinue | Sort-Object LastWriteTime | Select-Object -First 5 Name, Length, LastWriteTime # 实时跟踪日志里的投递结果，重点看 550/451 两类返回码 Get-Content "D:\MailSrv\log\smtp.log" -Tail 50 -Wait

日志里我最关注的是返回码和对应的收件域。同样是550，550 5.1.1是收件人不存在，550 5.7.1是被策略拒收，前者要改账号，后者要改 IP 声誉或认证配置，方向完全相反。分不清这两个，就容易在错误的方向上改半天配置。

5. 避坑：5 条真实环境里的翻车记录

这一章是我自己在这套东西上花过时间的部分。下面五条都按“现象 → 原因 → 解决”写，能对号入座就不用重复交学费。

5.1 管理页面打不开，但服务明明在跑

现象：服务列表里几个服务状态都是 Running，netstat也能看到端口在监听，浏览器打开管理地址却一直转圈直到超时。

原因：管理端口被系统防火墙拦在外部，而本机自测时用的127.0.0.1是回环流量，防火墙默认放行，所以“本机能开、别人打不开”。另一种情况是管理服务只绑定了回环地址，配置文件里ListenAddr=127.0.0.1，远程当然连不上。

解决：先用netstat -ano | findstr :<端口>看绑定的是0.0.0.0还是127.0.0.1，前者是防火墙问题，后者是配置问题。防火墙侧放行对应网段即可，配置侧把监听地址改成0.0.0.0并重启服务。

5.2 内网能发不能收，外部投递全部超时

现象：从内网账号往外发信正常，外部发进来的邮件一律Connection timed out，日志里连一次入站会话都没有。

原因：25 端口的入站被上游链路拦了，或者 MX 记录指向的地址和实际入口不是同一个。还有一种是服务器有公网 IP 但网关没做端口映射，MX 解析到公网地址，包到不了内网主机。

解决：从外部网络telnet <MX指向的地址> 25，通不了就说明链路层就断了，跟软件无关。再逐段确认映射关系，最后用nslookup -type=mx复核解析结果，别凭记忆。

5.3 开放中继被当跳板，队列一夜涨到几万封

现象：第二天早上发现磁盘告警，队列目录里堆了几万个文件，日志里全是陌生的外部收件域，发件人是随机字符串。

原因：中继策略设成了允许所有客户端，服务器又恰好能被外网访问。扫描器找到开放中继只需要几分钟，之后就是持续投递。

解决：立刻把中继策略改成“仅认证用户 + 内网网段”，清空队列（直接停服务后删队列目录里的文件，重启），然后检查是否有账号口令被爆破成功。事后补一条防火墙规则，25 端口只对需要收信的来源开放。这条我现在的习惯是——任何邮件服务上线前，先从中继策略这一项开始查，而不是最后查。

5.4 磁盘写满之后服务假死，重启也没用

现象：某个账号收了几万封告警邮件，分区写满，之后所有账号都收不到信，服务重启后几秒内又变成不可用状态。

原因：存储目录和日志目录在同一个分区，写满之后服务无法写日志、也无法写队列状态，进程卡在写操作上。重启时它尝试恢复队列，同样因为没空间而失败。

解决：先把日志目录整体挪到另一个分区或临时挂载盘，腾出空间让服务能启动；再给账号设配额、给存储分区设监控阈值。根治办法是分区规划阶段就把store、log、backup分开放，这也是我在第 2 章强调目录分离的原因。

5.5 重装之后账号全丢，邮件目录还在

现象：升级或重装程序后，登录控制台发现域和账号列表是空的，但store目录下的用户邮件文件都还在。

原因：账号信息存在安装目录下的一个数据文件里（或一个轻量数据库文件），重装时选了默认路径，新目录覆盖了旧目录，账号数据被清掉。邮件正文在独立的store目录，所以反而幸存。

解决：重装前先停服务，把安装目录和store目录各拷一份出来；重装后在服务停止状态下把数据文件还原回去，再启动。这类“配置和内容分离存储”的老软件，备份必须两份都备，只备邮件目录等于没备。

6. 进阶用法：把它降级成内网中继，再用三条命令验证

这套公测版最实用的定位不是“对外邮箱”，而是内网中继。思路是把所有内网设备、老系统、打印机、监控平台的发信地址统一指向它，由它负责排队、重试、归档，再按域名路由转发到真正的出口服务器。好处是出口只暴露一个地址，内网设备的 SMTP 能力差异被这一层抹平，出了问题只看一个队列。

6.1 中继模式的路由配置

路由规则按“目标域 → 下一跳”来写，本地域直接投本地，其余全部转发到上游。关键是把“未知域”这条兜底规则显式写出来，别依赖默认行为。

; 中继路由：本域直投，其余转发到上游 SMTP [Route] LocalDomain=demo-lab.local LocalDelivery=1 DefaultRelayHost=10.10.20.5 DefaultRelayPort=25 ; 上游要求认证时填这一组，不需要就留空 RelayAuthUser= RelayAuthPass= ; 转发失败时的退信行为，1 表示给发件人回退信 BounceOnFailure=1

配好之后用三条命令验证，分别覆盖“本地投递”“中继转发”“失败退信”三种路径。第一条发给自己域内的账号，验证本地投递；第二条发给上游域内的账号，验证中继；第三条故意发给一个不存在的域，验证它在重试耗尽后确实会回退信而不是静默丢弃。三条都符合预期，这层中继才算真正可用。

6.2 备份与恢复的验证方法

备份最怕的是“备了但恢复不了”，所以每次做完备份我都做一次恢复演练，而不是等到出事才第一次试。流程是：停服务 → 打包安装目录和存储目录 → 在另一台机器上还原 → 启动服务 → 用 POP3 数一下某个账号的邮件数量是否与源端一致。

# 备份：停服务后整目录打包，避免拷到一半文件被写 Stop-Service -Name "<邮件服务名>" Compress-Archive -Path D:\MailSrv\app, D:\MailSrv\store ` -DestinationPath D:\MailSrv\backup\mail-$(Get-Date -Format yyyyMMdd-HHmm).zip Start-Service -Name "<邮件服务名>" # 恢复后核对：统计某个账号的邮件文件数，与源端对比 (Get-ChildItem "D:\MailSrv\store\dev-a" -Recurse -File).Count

数量对不上就别往下走，先查是不是有子目录没还原、或者权限没继承下来。我在这上面吃过一次亏：恢复后服务能启动、账号能登录，看起来一切正常，但那个账号的近三天邮件全是空的——原因是备份时没有停服务，写入过程中的文件被跳过。从那以后我每次做这套东西的备份，都强制走一遍“停服务、打包、校验数量、启服务”四步，一步都不省。

希望帮到你。

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