不寄一封信，也能揪出僵尸邮箱：reacherhq/check-if-email-exists 上手与避坑

Rust 自托管邮箱校验，不发信探活；AGPL-3.0 与 SMTP 25 端口才是真门槛。

维护邮件列表、跑注册漏斗时，最怕两件事：发出去被退信、拉低发信域名信誉，或者每月为 hunter.io、ZeroBounce 这类 SaaS 续费。check-if-email-exists 给了第三条路——一份 Rust 写、可自托管的开源校验器，直接对着收件方 SMTP 服务器探活，全程不真正发信。但它不是免费午餐：开源协议是 AGPL-3.0，做闭源商业产品要买商业许可；而 SMTP 出方向 25 端口、各大邮箱服务商的针对性封禁，才是真正拦人的门槛。

一、它到底做什么

它的核心思路是「不发信也能判断邮箱是否可达」。工具不会真的往目标地址投递邮件，而是依次做四件事：先校验地址语法，再查域名 MX 记录确认能收信，然后与收件方 SMTP 服务器建立连接试探（不发送正文），最后结合 disposable（一次性邮箱）、role 账号、catch-all（通配收信）、HIBP 泄露库等维度综合打分，给出 is_reachable 的四档结论：safe、risky、invalid、unknown。

相比只查语法或只查 MX 的库，它离「真实可达性」更近一步，因为它真的去敲了对方邮件服务器的大门。覆盖的维度包括语法、DNS/MX、SMTP 连通性、可投递性、邮箱是否禁用、是否爆仓、是否 catch-all、是否 role 账号，以及 HIBP 泄露比对。

二、怎么用（命令取自项目 README）

官方给出三种自托管方式，最常用的是 Docker 后端：

docker run -p 8080:8080 reacherhq/backend:latest

启动后向本地接口发一个 POST 请求：

POST http://localhost:8080/v0/check_email

{
    "to_email": "someone@gmail.com",
    "proxy": {
        "host": "my-proxy.io",
        "port": 1080,
        "username": "me",
        "password": "pass"
    }
}

或者直接用 CLI 二进制（从 releases 页面下载）：

check_if_email_exists --help

也可以在 Rust 项目里当库调用：

[dependencies]
check-if-email-exists = "0.9"

use check_if_email_exists::{check_email, CheckEmailInput};

async fn check() {
    let input = CheckEmailInput::new(vec!["someone@gmail.com".into()]);
    let result = check_email(&input).await;
    println!("{:?}", result);
}

注意：HTTP 后端要求出方向 25 端口放通。多数云 VPS 与家庭宽带默认封掉这个端口，这正是后面「坑」里大量连接失败的根因。

三、优点和缺点

优点

真·不发信探活，比纯语法 / MX 校验更接近真实可达性；
Rust 单产物，CLI / HTTP 后端 / 库三种形态任选，数据全程不出网；
校验维度全（11 项，含 catch-all、role、HIBP 泄露比对）。

缺点与坑（均有公开 issue 为证）

协议是 AGPL-3.0：做闭源商业产品必须购买商业许可，否则整个应用要按 AGPL 开源。「开源」只覆盖代码，不覆盖你的商用权利。
25 端口是头号拦路虎：云 VPS 与家庭宽带常封掉出方向 25，结果就是 Connection refused (os error 111)（issue #1641）、在 VPS 上根本跑不动（#1566）；要跑量必须购买 SMTP 代理（如 proxy25.com）。
准确率有硬伤：aol.com 永远被判 safe（#1470）、icloud 直接跳过不校验（#1468）、gmx.de 响应解析错误（#1464）、is_deliverable 恒为 false（#1443）；catch-all 域名基本只能拿到 risky / unknown。
厂商针对性失效：Yahoo 无头校验崩溃且 SMTP 回退会假阳性（#1643）、Gmail API 已不可用（#1431 / #1412）、icloud 报 HELO/EHLO 错误（#1410）。
HIBP 泄露比对需要单独的 API key。

四、最终能达到什么效果

适合谁：自有服务器、需要定期清洗邮件列表、做开源或内部工具、且能接受 AGPL 义务的团队。

不适合谁：想白嫖闭源上线的产品（要算许可成本）、没有 25 端口又不愿买代理的个人、需要 100% 准确率的金融或合规场景。

一句话总结：它是 hunter.io 的靠谱开源替代，但「开源」只覆盖代码，不覆盖商用许可与 SMTP 通道——这两处才是真正的成本。

下期预告

当你要在一台机器上并发跑多个 AI Agent，隔离怎么做才不互相污染？下期做一期 Agent 沙箱横向对比——本机微虚机（ArcBox）/ Kubernetes 原生（agent-sandbox）/ 云厂商容器沙箱（CubeSandbox）。

本文安装命令与用法均取自项目 README（main 分支）；文中所引 #1641、#1566、#1470、#1468、#1464、#1443、#1643、#1431、#1412、#1410 均为项目公开 issue 编号。