开源邮件网关e2a：让AI代理像调用API一样收发邮件

e2a是一个开源的身份验证邮件网关，专门为AI代理设计。开发者不用自己搭建或管理邮件服务器，通过HTTP API发送邮件，通过webhook或WebSocket接收邮件。入站邮件自动完成SPF/DKIM验证，出站邮件带有HMAC签名的身份头。

项目团队在FAQ里解释了为什么选择邮件，而不是webhook或gRPC：邮件是唯一一个人类已经有地址和客户端的协议。AI代理用邮件与人交互，对方不需要安装任何新东西。

安全是核心设计起点。入站邮件经过SPF/DKIM检查，确认域名没有被伪造。然后系统为邮件打上一组签名的X-E2A-Auth-*头，覆盖验证状态、发送者身份、实体类型、域名检查结果、委托信息、时间戳、消息ID和正文哈希，每个字段通过HMAC-SHA256绑定。

SDK默认在访问字段之前验证签名。如果一个webhook负载还没有通过验证，直接访问email.sender或email.subject会抛出UnverifiedEmailError。这样一来，即使邮件在传输过程中被截获，伪造的头部也会被识别出来。

出站方向同样有防伪造机制。中继会剥离任何入站邮件中可能存在的X-E2A-Auth-*头，然后重新签名。签名绑定了发送者、验证状态、正文哈希和消息ID，攻击者无法通过中继外部注入假的身份头来冒充代理。

除了安全，e2a还做了两件事：对话线程化和人工审核。

对话线程化让AI代理的邮件往来像人类对话一样连贯。系统通过X-E2A-Conversation-Id头或In-Reply-To/References字段追踪回复的上下文。每个投递的消息都会携带conversation_id，代理收到后可以直接知道它属于哪个对话，不需要自己维护映射。

人工审核（HITL）是可选的出站门控。当代理启用HITL后，发送或回复的请求不会立即投递。消息进入pending_approval状态，审核人可以通过仪表盘、魔法链接邮件或CLI批准或拒绝。系统还支持可配置的TTL过期动作——超过时限后，消息会自动发送或丢弃。这个功能在金融、医疗等场景中很有价值，AI输出需要人工确认才能到达收件人。

部署方式灵活。开发者可以直接使用托管版本e2a.dev，注册后获得一个agents.e2a.dev域名的slug，不用设置DNS就能开始收发邮件，同时有仪表盘和管理能力。如果对数据控制要求更高，也可以自托管。自托管需要Docker和Postgres 14+，命令只有git clone和docker compose up -d。托管实例和自托管运行的是同一个镜像。

API覆盖了域名注册与验证、代理CRUD、消息收发、HITL审批、GDPR数据导出和删除、WebSocket通道。CLI命令包括agents register、listen、inbox、read、reply、send、pending。SDK现在支持Python和TypeScript，分别通过pip install e2a和npm install @e2a/sdk安装。WebSocket模式需要额外安装Python的ws扩展。

数据隐私方面，消息信封和正文在Postgres中默认保留30天。出站正文在HITL进入终态时自动清除。API密钥存储为哈希值，附件放在JSONB行里，没有使用S3或GCS。用户可以自行导出和删除数据，符合GDPR第15、17条和CCPA的要求。

安全措施还包括SSRF保护：生产环境下的webhook URL必须使用HTTPS和域名，不能使用原始IP地址，也不能指向私有或回环地址。OAuth CSRF通过一次性的、带时间限制的nonce在state参数中保护。

e2a在FAQ里详细说明了它与直接用SendGrid/Resend/Postmark的区别。邮件发送服务本身不直接提供四个关键能力：本地模式代理不需要公网URL、自动对话线程化、共享域名下的slug配置、内置的HITL审批和过期逻辑。与自建Postfix或Postal相比，e2a的价值不在SMTP传输层，而是传输层之上的认证模型、代理抽象、签名投递合约、重试策略和开发工具。

项目选择开源，许可证是Apache 2.0。团队给出的理由是：可审计性和自托管作为真实选项。托管版本未来会启用定价，目前还没有生效。定价会通过环境变量选择加入，开源的代码路径不会改变。任何人现在就可以拉取ghcr.io/mnexa-ai/e2a镜像并运行。

e2a没有内置AI模型，也不打算替代Gmail或Outlook。它的定位是一个中间层——让AI代理获得一个可信、可审计的邮件入口，同时保留人类现有的客户端和对话习惯。