Mailez 1.0.1 没有把重点放在扩展邮件功能，而是集中解决系统上线后的实际问题：怎样快速定位出站网络故障、怎样减少重复健康告警、怎样阻断恶意 IP，以及怎样定时保存加密备份。与此同时，新版本加入 Delta Chat 扫码登录，提升大信箱批量操作性能，并修复 15 处涉及邮件收发、排序、部署和权限边界的问题。
这类版本看似偏运维，实际上直接影响邮件系统是否能长期稳定运行。一次出站端口被云平台拦截、一个没有正确识别代理来源地址的封禁规则，或者一份从未验证过的备份，都可能比缺少某个新功能更棘手。
管理台新增的四项能力解决了什么
出站网络体检：把“邮件发不出去”拆成可诊断步骤
邮件无法发出不一定是应用自身故障。DNS 解析、出站端口、TLS 握手、上游服务和网络策略中的任何一环都可能出问题。v1.0.1 在健康页加入出站网络体检，价值在于把原本需要登录服务器逐项排查的工作前移到管理台。
升级后，建议重点验证以下场景：
- 域名能否从 Mailez 实际运行环境中解析；
- SMTP 目标端口能否建立 TCP 连接；
- TLS 握手和证书链是否正常；
- 容器网络、宿主机防火墙及云平台安全策略是否存在差异；
- 失败结果是否给出足够明确的定位信息。
管理台检查之外，还可以在部署节点运行一个独立脚本进行交叉验证。下面的示例适用于常见 Linux 环境，需要安装 openssl、netcat、getent 和 timeout。运行前将 SMTP_HOST 改成实际目标，端口可使用 465 或 587：
#!/usr/bin/env bash
set -euo pipefail
: "${SMTP_HOST:?请设置 SMTP_HOST，例如 smtp.example.com}"
SMTP_PORT="${SMTP_PORT:-587}"
TIMEOUT_SECONDS="${TIMEOUT_SECONDS:-10}"
echo "[1/3] 检查 DNS：${SMTP_HOST}"
getent ahosts "${SMTP_HOST}" | head
echo "[2/3] 检查 TCP：${SMTP_HOST}:${SMTP_PORT}"
timeout "${TIMEOUT_SECONDS}" nc -zvw3 "${SMTP_HOST}" "${SMTP_PORT}"
echo "[3/3] 检查 TLS 证书"
if [ "${SMTP_PORT}" = "465" ]; then
TLS_ARGS=(-connect "${SMTP_HOST}:${SMTP_PORT}" -servername "${SMTP_HOST}")
else
TLS_ARGS=(-starttls smtp -connect "${SMTP_HOST}:${SMTP_PORT}" -servername "${SMTP_HOST}")
fi
timeout "${TIMEOUT_SECONDS}" openssl s_client "${TLS_ARGS[@]}" </dev/null 2>/dev/null \
| grep "Verify return code"
echo "出站网络基础检查完成"
这个脚本不是 Mailez 官方接口调用，而是一种可配合管理台体检使用的实践方法。如果管理台和脚本结果不同，应优先确认两者是否运行在同一个网络命名空间中。例如，在宿主机执行成功，并不代表容器内也能访问相同目标。
变更式健康告警：关注状态变化，而不是重复报错
持续重复发送同一种告警，很容易让值班人员产生告警疲劳。变更式健康告警更适合表达“正常变异常”和“异常恢复正常”这样的状态迁移。
实际接入时，不应只验证故障告警，还应检查完整闭环：
- 主动制造一个可控故障，例如临时阻断测试环境的出站连接；
- 确认系统只在状态发生变化时通知；
- 恢复连接，确认能够收到恢复消息；
- 重启服务，确认健康状态不会被无条件重置并产生大量重复通知；
- 检查告警中是否包含实例、时间和故障项等定位信息。
变更式告警可以减少噪声，但也存在边界：如果系统没有定期发送汇总或心跳，通知通道自身失效后可能难以及时发现。因此，可以在状态变更告警之外保留每日健康摘要或外部监控探针。
IP 封禁引擎：安全能力依赖正确的来源地址
IP 封禁对抗暴力登录、接口扫描和异常请求很有效，但前提是 Mailez 获取到真实客户端地址。若系统部署在 Nginx、Ingress 或云负载均衡器后面，而可信代理配置不正确，封禁引擎可能只看到代理 IP，甚至误封整个入口。
启用前应确认：
- 哪些代理节点可以写入
X-Forwarded-For或同类头部； - 应用是否只信任明确配置的代理，而不是接受任意客户端提交的转发头；
- 管理员出口、监控节点和内部自动化任务是否需要加入白名单；
- 是否提供封禁期限、原因记录和紧急解封路径；
- IPv6、共享 NAT 和动态办公网络是否会扩大误封影响。
不要在生产环境中直接用管理员当前公网 IP 测试封禁。更安全的做法是在测试实例中使用独立客户端，并提前准备不经过同一路径的解封方式。
定时加密备份：完成备份不等于具备恢复能力
定时和加密解决的是备份自动执行及静态数据泄露问题，但真正的验收标准仍然是能否恢复。密钥也不应只保存在被备份的同一台服务器上，否则主机故障或勒索攻击可能同时摧毁数据和解密能力。
可以为备份流程增加以下检查：
- 将加密密钥与备份文件分开保存，并限制密钥访问权限；
- 将备份复制到独立存储或不同账号下的对象存储；
- 设置保留周期，避免磁盘被历史备份占满；
- 定期在隔离环境中执行恢复演练；
- 恢复后验证账号、邮件、附件、权限和关键配置，而不是只检查压缩包能否解开。
如果导出的备份是经 age 加密的压缩归档，可以用下面的方式做非破坏性完整性检查。请把文件名和私钥路径替换为实际值：
set -euo pipefail
BACKUP_FILE="mailez-backup.tar.gz.age"
IDENTITY_FILE="/secure/path/backup-key.txt"
age --decrypt --identity "${IDENTITY_FILE}" "${BACKUP_FILE}" \
| gzip --test
echo "备份可以解密，gzip 数据流完整"
这只是通用验收示例，并不代表 Mailez 固定使用 age 或特定归档格式。应根据管理台实际生成的备份格式替换解密与校验命令。
客户端接入和大信箱性能改进
v1.0.1 新增 Delta Chat 扫码登录，降低了手工录入服务器地址、端口和凭据的成本。对团队部署而言，二维码不应被当作普通静态配置长期传播。上线前建议确认二维码是否具有有效期、能否重复使用，以及设备丢失后如何撤销会话或凭据。
另一个更直接的改善是大信箱中的批量标记、移动和删除操作提速。这类优化对拥有多年历史邮件、自动归档账号或共享信箱的用户尤其重要。升级验证时不要只打开收件箱观察页面速度，可以准备一个接近生产规模的测试信箱，分别记录：
- 批量选择数百或数千封邮件后的响应时间；
- 跨文件夹移动是否完整，排序是否保持正确；
- 操作过程中是否出现超时、重复执行或部分成功；
- 任务完成后未读数、文件夹计数和搜索结果是否一致。
性能变快不能替代一致性检查。尤其是删除和移动操作，最好先用可恢复的测试数据验证。
15 处修复意味着升级后仍要做回归测试
本次修复覆盖邮件收发、排序、部署及权限边界。这些区域都属于高风险路径：收发问题可能造成消息延迟或丢失，排序错误会影响用户判断，部署缺陷会妨碍升级，而权限边界问题则可能导致越权访问。
由于摘要没有列出每个缺陷的具体触发条件，不能简单假设升级后所有相关行为都无需验证。可以按以下清单执行一次最小回归：
- 给内部和外部地址各发送一封纯文本邮件及一封带附件邮件；
- 分别验证收件、回复、转发和失败退信；
- 按日期、发件人和主题切换排序，并检查翻页后的稳定性；
- 使用普通用户尝试访问管理员功能和其他用户资源；
- 重启服务或容器，确认配置、数据和后台任务能够恢复；
- 在大信箱中执行批量标记、移动和删除，再核对计数；
- 测试 Delta Chat 扫码接入、设备撤销和凭据失效流程；
- 触发一次健康状态变化，确认故障与恢复通知都能送达。
是否应该立即升级
如果生产环境正在受到出站网络定位困难、告警噪声、大信箱操作缓慢或备份依赖人工执行等问题影响，v1.0.1 值得优先评估。涉及权限边界的修复也意味着不宜长期停留在旧版本。
稳妥的升级方式是：先生成并验证备份，再在测试环境复现当前部署拓扑，使用项目提供的正式升级方式完成迁移，随后执行邮件收发、权限、批量操作和恢复演练。IP 封禁和扫码登录等新能力则应分阶段开启，避免把版本升级与安全策略切换叠加成一次难以回滚的大变更。
这次更新的核心价值，不是多了四个管理台入口，而是让邮件系统的故障发现、攻击处置和数据恢复更接近一套可重复执行的运维流程。