Haraka 3.3.5 介绍与选型指南

目标：面向正在评估 SMTP 服务器选型的运维与后端工程师，讲清 Haraka 是什么、架构与插件机制如何运作、适合承担哪些邮件角色，并与 Postfix、Exim、OpenSMTPD 等同类 MTA 做量化对比，给出可落地的选型建议。本篇为认知篇，全部数据来自官方与权威渠道的联网溯源（数据标注来源与查询日期），未做本地性能测试。

一、环境信息

本篇为纯联网溯源的认知篇，不依赖特定实验环境。信息来源与查询日期如下：

二、软件概述

2.1 一句话定位

Haraka 官方自我定位为「A modern, high performance, flexible SMTP server」——一个用 Node.js 编写、以插件系统为核心扩展手段的高性能 SMTP 服务器。官网首页原文（来源：haraka.github.io，查询日期 2026-10-21）：

Haraka is an open source SMTP server written in Node.js which provides extremely high performance coupled with a flexible plugin system allowing JavaScript programmers full access to change the behaviour of the server. It is used heavily in some high traffic sites.

即：Haraka 把「高性能」与「用 JavaScript 全程定制邮件收发行为」作为两大卖点，官网还特别强调它被一些高流量站点重度使用（Known Users 页面，本篇不转述具体用户名单，读者可自行查阅官网）。

2.2 项目身份与治理

2.3 版本与活跃度（量化）

GitHub 社区数据（来源：shields.io 徽章，查询日期 2026-10-21）：

• Stars：5.6k；Forks：719。

npm 下载量（来源：api.npmjs.org，查询日期 2026-10-21）：

版本发布节奏（来源：GitHub Releases / releases.atom，查询日期 2026-10-21）：

解读：3.x 系列在 2026 年保持约每月一个补丁版本的节奏（3.1 → 3.2 → 3.3），属于活跃维护期；当前大版本线为 3.3.x，另有 2.5.0-alpha 预发布标签挂在 alpha dist-tag 上（npm registry，查询日期 2026-10-21）。对生产使用者的含义是：补丁跟进频繁、需要把「升级 Haraka」纳入常规运维（配合 npm 版本锁定）。

三、核心架构

3.1 插件钩子模型

Haraka 的架构核心是「精简内核 + 插件管线」。SMTP 会话的每个阶段都被抽象为钩子（hook），插件在钩子上注册处理函数并按序执行：

钩子的返回值决定会话走向：OK（直接通过，短路后续插件）、CONT（继续）、DENY / DENYSOFT（拒绝 / 临时拒绝）。这一模型与 Postfix 的「内置参数 + 外部内容过滤接口」不同：Haraka 允许用 JavaScript 在任意阶段改写行为，扩展粒度细到单条 SMTP 命令。（来源：Haraka 官方文档 Plugins.md 注册表与插件文档体系，查询日期 2026-10-21。）

💡 技术拓展：MTA 的扩展机制业界主要有四类——

机制	代表	特点	适用
进程内插件钩子	Haraka	语言级扩展，粒度最细，随主进程生效	需要深度定制策略
内置参数 + 外部过滤接口	Postfix	内核稳定，策略外移给独立进程（如 amavis）	通用生产环境
专有配置 DSL	Exim	一套配置语言覆盖全部逻辑，能力极强但曲线陡峭	复杂路由规则
内置过滤器管道	OpenSMTPD	配置极简，过滤器以独立进程对接	轻量场景

Haraka 选择的是第一种：把「策略」全部让位给 JavaScript 插件，内核只做事件调度与 SMTP 状态机。

3.2 进程模型与性能设计

Haraka 采用「主进程监听 + 多 worker」的 cluster 模型：config/smtp.ini 中 nodes=cpus 可让 worker 数量等于 CPU 核数，主进程负责 accept 与分发。官方 wiki 提供了专门的 Performance-Tuning 页面讨论该参数（来源：config/smtp.ini 官方默认配置内注释引用的 wiki 链接，查询日期 2026-10-21）。

其他性能相关设计点（来源：官方默认配置文件注释与 outbound.ini 样例，查询日期 2026-10-21）：

• 大信腾出内存：connection.ini 的 spool_after 阈值可将大邮件转磁盘 spool，避免大附件长期占用内存；
• 出站并发：outbound.ini 的 concurrency_max（默认 100）限制出站投递并发；
• 优雅退出：force_shutdown_timeout（默认 30 秒）控制关闭时等待出站连接收尾的上限。

官网明确宣称 Haraka 在高流量站点被重度使用；但官方未随版本发布标准化的基准测试报告，选型时应以自身流量模型压测为准（这一点同样适用于本平台的《Postfix》类传统 MTA——公开可比、可复现的横向基准极少）。

3.3 出站队列与 MX 路由

Haraka 内建独立的 Outbound 投递层：消息进入队列后按收件域做 DNS MX 解析投递，支持机会主义 TLS（对端支持 STARTTLS 即升级加密）；queue/smtp_forward 插件还能接管出站路由，在 smtp_forward.ini 中按「收件域」配置下一跳（per-domain 路由），实现类似「按域名分流转发」的边缘网关形态。（来源：Haraka 3.3.5 包内 outbound.ini 样例与 queue/smtp_forward 插件 README，查询日期 2026-10-21。）

四、功能特性

依据官方插件注册表（仓库内 Plugins.md）与默认配置启用集，Haraka 的功能版图如下：

默认安装即启用的插件集合为：mail_from.is_resolvable、rcpt_to.in_host_list、queue/smtp_forward（默认配置文件 config/plugins 中的未注释项，来源：Haraka 3.3.5 默认生成配置，查询日期 2026-10-21）。

能力边界（同样重要）：Haraka 是 SMTP 服务器（MTA），不含 IMAP/POP3 收信、不含 Webmail、不含用户邮箱存储。它擅长的是「收信—过滤—转发/投递」链路，而不是「邮箱系统」。需要完整邮箱套件时，应选 Stalwart、Mailu、docker-mailserver 这类一体化方案（见第八节站内互链）。

五、快速开始（官方路径）

以下为官方 Getting Started 文档给出的最小可用路径（来源：haraka.github.io/getting_started 与官网首页安装命令，查询日期 2026-10-21；在本平台《Ubuntu 22.04 安装 Haraka 3.3.5 指南》中已按该路径完成安装验证，此处仅引用官方命令形态）：

# 官方推荐安装命令（来源：haraka.github.io 首页）
npm install Haraka -g

# 生成服务目录（含 config/ 配置骨架）
haraka -i /path/to/haraka_test

# 前台启动（-c 指向服务目录）
haraka -c /path/to/haraka_test

启动后默认监听 [::0]:25（IPv6 与 IPv4 全地址，25 端口），可用 telnet 或 swaks 连上去看到形如 220 <主机名> ESMTP Haraka/x.y.z ready 的横幅。完整的从零安装（含 Node.js 20 前置、systemd 托管、降权运行）见本平台 《Ubuntu 22.04 安装 Haraka 3.3.5 指南》。

💡 说明：Haraka 官方同时提供 Docker 化的运行形态（官方仓库内含 Dockerfile，官方镜像发布于 Docker Hub 的 haraka 组织下）。需要以封装形态快速拉起时可在官方仓库与 Docker Hub 核对当前标签；本文后续篇章以 npm 全局安装 + systemd 托管为主线。

六、适用场景与限制

6.1 适合的场景

1. 边缘收信 + 反垃圾前置：Haraka 在 25 端口接收外部来信，跑完 SPF/DNSBL/Rspamd/ClamAV 等插件链后，把干净邮件转发给后端真正的邮箱系统（smtp_forward 到内部 MTA/邮箱套件）；
2. 灵活策略中继/网关：按收件域分流（smtp_forward per-domain 路由）、按发件人/收件人黑白名单过滤（access）、出站中继与别名改写（aliases）；
3. 需要深度定制的邮件管线：团队具备 JavaScript 能力、需要在 SMTP 会话任意阶段插入业务逻辑（例如动态限流、自定义评分、对接内部风控 API）；
4. 高吞吐转发链路：Node.js 事件模型 + cluster 多 worker，适合纯转发型（不落邮箱）的大流量边缘节点。

6.2 不适合的场景与限制

七、同类选型对比

7.1 同代 MTA 量化对比

选取三个最具代表性的传统 MTA 与 Haraka 对比。表格数据来源：各自官方发布页与发行版仓库（查询日期 2026-10-21）；Haraka 版本节奏来自 GitHub Releases（本篇第二节），Postfix/Exim/OpenSMTPD 版本号取自其官方发布页当前主线。

关键差异解读：Postfix/Exim/OpenSMTPD 的共同点是「内核把协议与队列做重、策略尽量外移」；Haraka 反其道而行——内核只做事件调度，策略与投递逻辑全部插件化。这意味着：

• 要「快速得到一台标准邮件服务器」→ Postfix 仍是默认答案（发行版直装、文档与运维生态最厚）；
• 要「复杂路由规则一步到位写进配置」→ Exim 的 DSL 表达力最强；
• 要「极简配置的安全小服务器」→ OpenSMTPD 最省心；
• 要「策略随业务频繁变、团队用 JavaScript、流量偏转发」→ Haraka 的插件模型优势明显。

7.2 与邮箱一体化套件的关系（站内互链）

Haraka 常与「一体化邮箱套件」形成前后端组合而非竞争关系。本平台已有专栏可直接参考：

7.3 选型建议（如果…则…）

• 如果只是给一台服务器配「能收能发的标准邮件服务」→ 选 Postfix（或直接上 Mailu/Stalwart 一体化套件），Haraka 无邮箱存储能力，不适合；
• 如果要做「互联网入口的反垃圾前置 + 内部邮箱系统后端」→ Haraka（25 端口收信过滤）+ Stalwart/Mailu（后端邮箱），组合分工清晰；
• 如果策略要频繁迭代（黑白名单、限流、风控联动、A/B 实验）→ Haraka 的 JS 插件管线迭代成本最低；
• 如果团队是 Python/Go 背景、没有 JavaScript 维护意愿 → Postfix + rspamd 组合的长期维护成本更低；
• 如果追求「单二进制、极简运维」的小规模自托管 → OpenSMTPD 或 Maddy 更合适。

八、参考链接

1. Haraka 官网：https://haraka.github.io （查询日期 2026-10-21）
2. GitHub 仓库：https://github.com/haraka/Haraka （查询日期 2026-10-21）
3. 官方插件注册表 Plugins.md：https://github.com/haraka/Haraka/blob/master/Plugins.md （查询日期 2026-10-21）
4. npm 包页（版本与 engines）：https://www.npmjs.com/package/Haraka （查询日期 2026-10-21）
5. npm 下载量统计 API：https://api.npmjs.org/downloads/point/last-month/Haraka （查询日期 2026-10-21）
6. GitHub 社区数据徽章：https://img.shields.io/github/stars/haraka/Haraka （查询日期 2026-10-21）
7. 官方性能调优 wiki：https://github.com/haraka/Haraka/wiki/Performance-Tuning （查询日期 2026-10-21）
8. 站内后续阅读：《Ubuntu 22.04 安装 Haraka 3.3.5 指南》、《Haraka 3.3.5 配置参数详解》、《Haraka 3.3.5 常用 CLI 命令详解》