BillionMail：8分钟自建开源邮件服务器与营销平台

先梳理一下，为什么一个开源邮件服务器值得我们在 2024 年重新关注。

• 第一座山是成本与数据主权。主流 SaaS 邮件营销平台按联系人数量阶梯计费，名单越大账单越吓人。更关键的是，你的订阅者名单、打开行为、点击数据，本质上都托管在别人家的数据库里。一旦账号被封或服务涨价，多年积累的客户资产说没就没。
• 第二座山是自建的工程复杂度。自己搭 Postfix + Dovecot + RoundCube 只是入门，真正难的是：SPF/DKIM/DMARC 三条记录的配置、Let‘s Encrypt 证书的自动签发与续期、DNS 记录校验、IP 被拉黑后的处理、日志审计、多进程守护。一个环节出错，邮件就进垃圾箱，而且你还不知道是哪一步出的问题。
• 第三座山是营销侧的效率。运维搭好了，运营同学要设计一封 HTML 邮件，还得懂表格布局、内联样式、深色模式兼容……很多小团队干脆放弃，退化成纯文本群发，转化率自然惨淡。

BillionMail 的野心，就是把这三座山一次性铲平。它不是一个单纯的 Mail Server，也不是一个单纯的群发工具，而是一个「服务器 + 设计器 + 数据分析 + AI」的一体化平台。

一句话定位：BillionMail 是一个基于 Go(GGoFrame v2) + Vue3 自研的全栈开源邮件服务器与邮件营销平台，将 MTA 运维、DNS/SSL 自动化、可视化邮件编辑、AI 模板生成与投递数据分析打包成可 Docker 一键部署的一体化方案。

它和常见方案的区别在于：

项目采用 MIT 许可证，目前已有 1240 个文件，主要语言是 Go、Shell、YAML、SQL 与配置，从前端模板到后端 API、再到容器镜像构建，覆盖了完整的技术栈。

• 输入层：发件域名（DNS 记录）、联系人名单（带标签分组）、邮件内容（手写、可视化编辑或 AI 生成）、投递策略（即时/定时/人群圈选）。
• 处理层：ACME 自动签发证书 → 域名 DKIM/SPF 校验 → 模板渲染 → 队列调度 → MTA 投递 → 结果回写。
• 输出层：送达/打开/点击/退信指标、按服务商维度的统计图表、失败投递明细（含 DSN、relay、延迟字段），以及内置 RoundCube 网页邮箱。

下面这几项核心功能都是真实实现的，不是 README 里的口号：

AITemplate 控制器调用后端 /askai 创建 chat，并据此生成模板，还能获取 AI 模型列表与聊天详情。它支持停止会话、Shift+Enter 换行，并用 Map 记录对话内容与 token 用量。后端直接依赖 go-openai 与 tiktoken-go。用户只需用自然语言描述需求，AI 就能直接产出营销邮件，同时实时跟踪 token 消耗，把创意与排版门槛降到最低。

ai-model 设置页控制器封装了 /askai/supplier/* 系列接口，支持供应商与模型的列表拉取、新增、配置读取与切换、启停（带失败回滚）以及 API 配置检查。这让用户可以在界面上接入并随时切换 OpenAI 等多家大模型供应商，掌握自己的 API 成本与可用性，避免被单一厂商绑定。

overview 页面对发送、送达、打开、点击、退信等核心指标做聚合，提供按邮件服务商维度的统计，以及发送量/打开率/点击率/退信率图表数据，甚至还包含失败投递记录的结构（含 DSN、relay、延迟字段）。营销人员能直观看到送达率与互动率，定位是哪家服务商或哪个环节导致退信与延迟，从而优化发送策略。

contacts/tags 服务层封装了 /tags 接口的列表、全量查询、创建、更新、删除，以及按 group 批量给联系人打标签。所有写操作统一带 i18n loading 文案与成功提示。用户可以按标签做人群圈选，为不同人群发送差异化内容，提升营销精准度。

通用 settings Store 负责拉取并映射系统配置，管理安全、网络、SSL 证书过期时间与剩余天数、IP 白名单、API、反向代理、端口、时区等。它会按长度以及大小写、数字、符号五项规则计算密码强度。管理员可在一个界面完成安全与网络合规配置，并即时看到密码强度和证书到期提醒，降低被入侵与掉线风险。

独立的 core/cmd/acme CLI 入口剥离参数后，委托 service/acme 执行 RunCLI，底层依赖 go-acme/lego，并间接引入 AWS、Azure、阿里云等 DNS 厂商 SDK。发送域名可以自动完成 DNS 记录校验并免费签发/续期 SSL 证书，免去手工操作与证书过期导致的投递失败。

前端 axios 封装会注入 Bearer Token，以 method/url/params/data 生成请求 key，并用 AbortController 取消重复请求。遇到 401 会重置登录并跳转，octet-stream 响应自动下载文件，超时设置为 600s。重复提交不会造成脏数据，登录态失效能自动引导重新登录，报表/附件可一键下载。

BillionMail 采用的是前后端一体化的架构，但开发上是分离的：

这套选型有几个明显的取舍值得说：

• 取舍一：为什么要自研而不是套壳开源组件？市面上其实有 Mailcow、Mailu 这类成熟的邮件服务器套件，但它们偏向「运维型」，缺少现代的营销侧界面。BillionMail 选择从零自研前后端，是为了让「服务器」和「营销」在数据模型层面天然打通——比如一封邮件的投递记录，可以直接关联到某个标签人群和某次活动，这是拼装方案很难做到的。
• 取舍二：为什么把 AI 做进后端而不是外挂？因为 token 用量、会话记录、供应商切换这些状态需要和模板绑定。后端直接依赖 go-openai 与 tiktoken-go，前端有独立的 AI 模板控制器与模型供应商设置页，形成一个可管理的 AI 能力层，而不是一个孤立的「调 OpenAI」按钮。
• 取舍三：容器里塞 supervisor + fail2ban 值不值？从「一个容器跑一切」的角度看略显笨重，但对目标用户（中小团队、DevOps）来说，能省掉大量运维文档，这种「把复杂度封装在产品里」的思路是合理的。

服务端的入口是 core/main.go，它是整个 Go 二进制的启动点，负责初始化配置、数据库连接、Redis 以及 HTTP 服务的挂载。紧接着是领域化的 API 组织，比如域名管理模块：

core/api/domains/domains.go

core/api/domains/v1/domain_blocklist.go

证书自动化被单独抽成了一个 CLI 入口 core/cmd/acme。它的逻辑很清晰：入口先剥离命令行参数，然后委托给 service/acme 的 RunCLI 去真正执行。真正干活的 service/acme 依赖 go-acme/lego，而 lego 又间接引入了 AWS/Azure/阿里云等厂商的 DNS SDK，从而支持在多云环境下完成 DNS-01 挑战的验证。

这里的设计意图值得学习：ACME 是一个「有状态、要联网、可能阻塞」的耗时操作，把它独立成 CLI，可以由 supervisor 或定时任务单独调度，不和主 HTTP 服务抢资源，失败也容易重试和排查。这比塞进 Web 请求里优雅得多。

前端有两个 Store 是理解业务的关键：

配合 Pinia 持久化插件与路由守卫，实现了鉴权白名单与语言（en/zh/ja）初始化。这是一个相当成熟的工程化前端基建。

前端对 axios 的封装实现了三件事：

// 概念示意

1. 注入 Bearer Token

2. key = method + url + params + data，用 AbortController 取消重复请求

3. 401 -> 重置登录态并跳转；octet-stream -> 自动下载文件

从项目定位来看，它的增长曲线反映了市场对「自托管 + 营销一体化」这类方案的真实需求。

整个链路里，前端 store、后端 API、CLI、容器守护进程各司其职，职责边界相当清晰。

# 方式一：Docker Compose

# 拉取镜像并启动，镜像按 TARGETARCH 自动选择二进制

# 方式二：使用内置 bm 管理脚本

bm install

bm update

# 启动后通过 /roundcube/ 访问内置网页邮箱

建议的首次运行顺序是：先配置发件域名并等待 ACME 证书签发成功，再导入联系人并打标签，然后用 AI 或编辑器生成第一封模板邮件，发给测试人群看投递结果。

客观来说，这类「大而全」的方案天然有取舍：

BillionMail 给我们最大的启发，可能不在于它实现了多少功能，而在于它选择了一个被 SaaS 和传统自建方案夹击的中间地带，用一体化的产品思维去重新组织复杂度。

它把「邮件服务器」这个传统上属于运维领域的硬骨头，和「营销增长」这个属于业务领域的软需求缝合在一起：Go(GGoFrame v2) 保证了后端的企业级可维护性，Vue3 + Pinia 撑起了现代交互，容器化 + supervisor + fail2ban 把运维封装进黑盒，而 AI 和 ACME 自动化则把两端的门槛同时拉低。

对于正在做开源项目的开发者，它的三点经验值得借鉴：

如果你正好被第三方邮件服务的账单和黑箱数据困扰，或者想给团队搭一套真正握在自己手里的邮件基础设施，BillionMail 值得放进你的候选清单里，花 8 分钟跑一个试试看。 ✨