Mailez 1.0.0 正式发布，目标不是再拼接一套邮件组件，而是把邮件收发、用户管理和协作能力放进一个可以自行掌控的系统中。它通过 Go 编写的 Mailezine 单二进制引擎，逐协议实现 SMTP、IMAP、POP3 和 ManageSieve，并同时提供 Webmail、管理控制台、反垃圾、日历、通讯录与云盘能力。
对于希望把邮件数据留在自己的服务器、又不想长期维护 Postfix、Dovecot、Webmail 和一堆外围服务的团队来说，这种交付方式值得关注。Mailez 社区版采用 AGPL-3.0 开源许可证，1.0.0 则意味着项目开始从“可以尝试”进入“可以评估并规划上线”的阶段。
单二进制引擎意味着什么
传统自托管邮件系统通常由多个成熟组件组合而成：SMTP 负责投递，IMAP 或 POP3 负责客户端访问，Sieve 负责过滤，Webmail 再通过协议或内部接口连接邮箱。这样的架构并非不可用，但运维边界分散，配置文件、日志、认证方式和版本兼容性都需要单独管理。
Mailezine 的路线相反：SMTP、IMAP、POP3 和 ManageSieve 都由同一个 Go 引擎实现。这里的价值不只是“少装几个软件”，还包括几个更直接的工程收益：
- 协议服务可以共享认证、邮箱存储、权限和日志模型。
- 部署、升级和回滚的对象更少，适合单机或小规模团队。
- 问题定位时，可以围绕一个服务的配置、日志和健康状态展开。
- 资源限制、进程管理和备份策略更容易统一。
代价也很明确。成熟邮件组件经过多年生产验证，自研协议实现必须面对兼容性、边界条件、安全修复和客户端差异。正式采用前，应使用实际客户端验证 TLS、认证、文件夹同步、邮件过滤、附件处理和异常投递场景，而不能只看服务是否成功启动。
从邮箱扩展到协作入口
Mailez 交付的不只是 SMTP 接收器或 IMAP 服务。Webmail 和管理控制台覆盖日常使用与管理员操作；反垃圾能力处理邮件系统最棘手的输入质量问题；日历、通讯录和云盘则把邮件账户延伸为一个轻量协作入口。
这种一体化的优势是账号体系和部署边界统一。管理员不需要分别维护多个应用的用户、域名、存储和权限。对中小团队而言，统一入口也能减少服务数量，降低新员工开通账号和离职账号回收的操作成本。
不过，一体化不等于所有场景都自动满足。上线时仍要单独确认：
- 外发邮件是否需要配置 SPF、DKIM 和 DMARC。
- 服务器公网 IP 的反向 DNS 是否正确，且是否具备稳定信誉。
- 邮箱和云盘的存储配额、备份周期与恢复流程是否明确。
- 反垃圾规则是否支持观察模式，避免误杀业务邮件。
- 日历和通讯录是否需要额外的客户端兼容性测试。
可以这样做一次上线前自检
下面是一组与具体安装器无关的基础检查命令。把 mail.example.com、example.com 和服务器地址替换成实际值后，可以在部署前或 DNS 切换前运行。它们不是 Mailez 专属命令，而是验证邮件系统外围条件的最小工具集。
#!/usr/bin/env bash
set -euo pipefail
DOMAIN="example.com"
MAIL_HOST="mail.example.com"
printf '%s\n' '== DNS records =='
dig +short A "$MAIL_HOST"
dig +short MX "$DOMAIN"
dig +short TXT "$DOMAIN"
dig +short TXT "_dmarc.$DOMAIN"
printf '%s\n' '== Listening ports =='
ss -ltnp | grep -E ':(25|465|587|110|995|143|993|4190)\\b' || true
printf '%s\n' '== SMTP TLS handshake =='
timeout 10 openssl s_client \\
-connect "$MAIL_HOST:25" \\
-starttls smtp \\
-servername "$MAIL_HOST" \\
</dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates || true
printf '%s\n' '== IMAP TLS handshake =='
timeout 10 openssl s_client \\
-connect "$MAIL_HOST:993" \\
-servername "$MAIL_HOST" \\
</dev/null 2>/dev/null | head -n 8 || true
如果发行版提供一条命令安装器，可以把安装步骤固定为类似下面的流程。命令名和参数只是示例，实际使用时应以 Mailez 1.0.0 发布包的安装文档为准：
# 示例：请替换为发行版实际提供的安装命令
sudo mailez install \\
--hostname mail.example.com \\
--domain example.com \\
--admin-email admin@example.com
# 安装完成后，执行发行版提供的健康检查
sudo mailez doctor
sudo systemctl status mailez --no-pager
sudo journalctl -u mailez -n 100 --no-pager
部署完成后，不要只检查 Webmail 能否打开。至少应覆盖以下路径：外部邮件进入本地邮箱、本地邮件发往外部地址、IMAP 客户端读取邮件、POP3 客户端拉取邮件、ManageSieve 创建过滤规则，以及管理员创建域和用户。每条路径都应记录响应时间、日志位置和失败后的恢复动作。
AGPL-3.0 下的采用边界
Mailez 社区版以 AGPL-3.0 开源。工程团队在引入前应让维护者、法务和安全团队共同确认使用方式，尤其是修改程序后通过网络向用户提供服务时的源码提供义务。是否保留修改、如何发布构建产物、如何向用户提供对应源码，都应在上线前形成清晰记录。
许可证之外，还要评估邮件系统本身的风险：邮箱内容通常包含高敏感数据，备份需要加密，管理员账号需要强认证，日志不能无意记录邮件正文或认证凭据，升级需要先在测试域验证并准备回滚方案。
适合怎样开始
Mailez 1.0.0 更适合从一个边界清晰的试点开始：选择测试域或内部域，导入少量账号，验证常用客户端与外发信誉，再决定是否迁移主域。单二进制部署可以显著减少组件数量，但并不能替代 DNS、TLS、反垃圾、备份和监控等邮件基础设施工作。
上线前可以用这份清单收尾：
- [ ] SMTP、IMAP、POP3、ManageSieve 均完成客户端验证。
- [ ] SPF、DKIM、DMARC 和反向 DNS 已配置并可查询。
- [ ] 管理员账号启用强密码和可用的额外保护措施。
- [ ] 邮箱、附件和云盘均设置存储配额。
- [ ] 备份已执行过一次恢复演练。
- [ ] 反垃圾策略有误杀观察和人工放行流程。
- [ ] 升级、日志排查和故障回滚步骤已写入运维文档。
如果团队的首要目标是掌控数据、减少邮件组件的运维数量，并接受对自研协议实现进行充分兼容性测试，那么 Mailez 1.0.0 已经具备进入技术评估清单的理由。