Show HN: E2a — AI エージェント向けのオープンソースメールゲートウェイ

AI エージェント向けの認証付きメールゲートウェイ。Webhook または WebSocket を通じて受信し、HTTP API を介して送信を実行します。また、人間であるか他の AI エージェントであれ、すべての送信者の身元を正確に検証いたします。

認証された転送

• 着信中（Inbound）で SPF/DKIM の検証を実施。各配信において HMAC 署名付きの

  X-E2A-Auth-*

  ヘッダーを使用します。

配信モード（2 つ）

• Webhook：クラウド系のエージェント向けです。
• WebSocket：ローカル系エージェント向け。パブリック URL の設定不要です。

外部 API（Outbound API）

• エージェント同士へ送信（SMTP リレー）または人間へ送信（上流の SMTP、例：SES、Resend）が可能です。

人間の関与（Human in the loop）

• ダッシュボード、マジックリンク付きメール、または CLI を介してレビューアが承認するまで、出力的なメールを送信するのを一時停止するオプトイン型の承認ゲートです。

CLI および SDK

• TypeScript と Python の SDK、および日常のエージェント運用をサポートする

  e2a

  CLI を提供しています。

e2a-demo-1080p-v2.mp4

ご活用方法 ホストされたインスタンスをご利用いただくか、セルフホスト環境を構築いただけますと幸いです。

ホストサービス（Hosted） e2a.dev で登録ください。DNS 設定不要で即座にスラッグベースのオンボーディング（例：

agents.e2a.dev

セルフホスト（Self-host） クイックスタートおよびデプロイメントガイドをご覧ください。すべての機能が同等に動作いたします。共有ドメインのスラッグの簡略化機能を使用する場合は、メールドメインをリレーにポインティングし、

config.yaml

shared_domain

仕組み概要

人間（Gmail/Outlook）
    │
    ▼ SMTP
┌──────────────┐
│   e2a relay   │  ← あなたのエージェントドメインの MX レコードはこちらを指します
│              │
│  1. 検証      │  ← 着信メッセージに対する SPF/DKIM チェック
│  2. 署名      │  ← HMAC 署名付き X-E2A-Auth-* ヘッダーの追加
│  3. 配信      │
└──────────────┘
    │
    ├──▶ クラウドモードエージェント: HTTPS Webhook POST
    │
    └──▶ ローカルモードエージェント: ストレージ保存＋WebSocket 通知
              │
              ▼
         e2a listen (CLI) または client.listen() (SDK)

着信フロー：SMTP → SPF/DKIM 検証 → エージェント検索 → HMAC 署名による認証ヘッダー付与 → Webhook または WebSocket 配信。
発信フロー：API 呼び出し → （オプション）HITL（人間による関与）一時停止 → SMTP リレー（エージェント間）または上流の SMTP（エージェントから人間へ）。

クイックスタート Docker を必須といたします。

git clone https://github.com/Mnexa-AI/e2a.git
cd e2a
docker compose up -d

Postgres が先に起動し（自動でスキーマ移行が実行されます）、続いて API サーバー、最後にダッシュボードが立ち上がります。以下の 3 つのホストポートをご利用ください：

• :8080

  — HTTP API

• :2525

  — SMTP リレー

• :3000

  — ダッシュボード（Caddy ＋ Next.js、/api/* は API サーバーへプロキシします）

ヘルスチェック:

curl http://localhost:8080/api/health
# {"status":"ok"}

ブラウザで

http://localhost:3000

config.yaml

初回ユーザーおよび API キーの作成（OAuth は不要）:

docker compose exec e2a e2a -config /etc/e2a/config.yaml -bootstrap-email you@example.com
# User:    you@example.com (id=...)
# API key: e2a_...

キーは一度のみ表示されるため、必ず保存してください。エージェントを登録し動作確認を行ってください：

KEY=e2a_...
curl -X POST http://localhost:8080/api/v1/agents \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d '{"slug":"my-bot","agent_mode":"local"}'

curl -H "Authorization: Bearer $KEY" http://localhost:8080/api/v1/agents

実際の着信メールを受信するためには、ドメインの MX レコードをリレーホストへ指す設定が必要です：

• A

  リコード：your-domain.com → サーバー IP アドレス

• MX

  リコード：your-domain.com → your-domain.com（プライオリティ 10）

その後、API を介してドメインを登録し検証してください（詳細は「ドメイン」セクション参照）。DNS 設定を行わなくてもテスト用としては API が動作しますが、外部からのメールはリレーに到達しません。

バージョンアップとマイグレーション。 コンPOSE ファイルでは

migrations/

docker compose exec postgres sh -c \
  'for f in /docker-entrypoint-initdb.d/*.sql; do psql -U e2a -d e2a -f "$f" -v ON_ERROR_STOP=1; done'

移行ファイルは冪等性（idempotent）が保証されています（

CREATE TABLE IF NOT EXISTS

概念解説

エージェントモード 登録時の

agent_mode

ローカルモードでは、接続が切れている間にメッセージを「未読」として蓄積し、再接続時にサーバーから WebSocket 通知として drain されます。どちらのモードでも REST API を介してメッセージをポーリング（取得）することができます。

認証ヘッダー e2a を通じて配信されるすべてのメール（Webhook または WebSocket フェッチ経由）は、以下の署名付きヘッダーを含みます：

true

spf=pass; dkim=none

agent={id};human={id}

署名は、以下の項目を含む文字列全体をカバーします：

verified \n sender \n entity_type \n domain_check \n delegation \n timestamp \n message_id \n body_hash

認証タグ（MAC）は

message_id

署名の検証方法

X-E2A-Auth-Verified

/api/v1/users/me/signing-secrets

SDK はデフォルトで、未検証の Webhook ペイロードにアクセスしようとした場合（例：

email.sender

email.subject

UnverifiedEmailError

from e2a.v1 import E2AClient
client = E2AClient()                          # E2A_API_KEY を読み取る
email = client.parse_webhook(request_body)    # E2A_WEBHOOK_SECRET を読み取り、署名エラー時は例外発生
# 安全に email.sender, email.subject などを使用できます

import { E2AClient } from "@e2a/sdk";
const email = await client.parseWebhook(req.body); // 署名エラー時は例外発生

両方の形式は、デフォルトで

E2A_WEBHOOK_SECRET

client.get_message(...)

verify

/get_messages

listMessages

InboundEmail

会話スレッド処理（Conversation Threading） 発信と返信の両方で、不透明な

conversation_id

payload.conversation_id

1. X-E2A-Conversation-Id ヘッダー — e2a から e2a へのトラフィックにおいて権威があります。SMTP エンベルフの

   MAIL FROM

   がこのリレーより発信された場合のみ有効に認識されます。そのため、外部送信者がこれを偽造することはできません。
2. In-Reply-To / References の検索 — 標準的な RFC 5322 スレッド処理で、宛先エージェント自身のメッセージのスコープ内に限定されます。Gmail/Outlook から返信する人間を含む対象となります。

人間からの最初のコンタクトは

conversation_id: null

人間による関与（HITL） エージェントが HITL 機能を有効化している場合、発信および返信呼び出しは即座にディスパッチされません。メッセージはステータス

pending_approval

hitl_expiration_action

expired_approved

expired_rejected

レビューアは以下のいずれかで承認または拒否を行います：

• ダッシュボード/API —

  POST /api/v1/messages/{id}/approve

  または

  /reject

• マジックリンク付きメール — HITL が作動した際に自動的に送信されます。ワンクリックで

  /api/v1/approve?token=…

  および

  /reject?token=…

  をGET 可能（

  E2A_PUBLIC_URL

  と出力的 SMTP の設定が必要です）。
• CLI —

  e2a pending

  で保持中のメッセージを一覧表示できます。

PUT

/api/v1/agents/{email}

hitl_expiration_action

API すべてのエンドポイントは

/api/v1

Authorization: Bearer <api_key>

/api/health

/api/v1/info

/api/feedback

@

機能範囲には、ドメイン登録および検証、エージェントの CRUD、着信・発信メッセージ、HITL の承認/拒否（API キーまたは署名付きマジックリンクトークンによる）、GDPR 準拠のエクスポートと削除、ローカルモードエージェント向けの WebSocket チャンネルが含まれます。完全なエンドポイント参照は

docs/api.md

web/public/openapi.yaml

CLI

npm install -g @e2a/cli
e2a login

<slug>@<shared-domain>

e2a login

~/.e2a/config.json

listen --forward

--forward-token

e2a listen --forward http://localhost:18789/v1/responses --forward-token <token>

完全な参照は

cli/README.md

SDK Python

pip install e2a            # Webhook モード
pip install 'e2a[ws]'      # WebSocket サポート追加

from e2a.v1 import E2AClient

client = E2AClient()                          # E2A_API_KEY を読み取る
email = client.parse_webhook(request_body)    # 解析 ＋ HMAC 検証（E2A_WEBHOOK_SECRET を読み取る）
print(email.sender, email.subject)
email.reply("Got it!", conversation_id="conv_123")

WebSocket（ローカルエージェント）:

from e2a.v1 import AsyncE2AClient

async with AsyncE2AClient(api_key="e2a_…") as client:
    async for notif in client.listen("bot@your-domain.com"):
        # notif は軽量なメタデータ — 本体は必要な時に取得
        email = await client.get_message(notif.message_id)
        await email.reply("Got it!")

詳細は

sdks/python/README.md

TypeScript 詳細は

sdks/typescript/README.md

デプロイメント 3 つの層（オーディエンス）があり、それぞれ異なる部分を設定します：

config.yaml

Go バイナリは任意のコンテナホストで動作し、ストレージは Postgres 14+ で利用可能です。出力的メールは標準的な SMTP を通じて送られます。ほとんどのワーカーは

SELECT … FOR UPDATE SKIP LOCKED

docs/deployment.md

セキュリティ

• 身元認証 — カスタムドメインの場合、エージェント登録にはドメイン所有権の DNS TXT 検証が必要です。
• ドメイン認証 — 各着信メッセージで SPF と DKIM が確認されます。
• ヘッダー署名 — カノンカルな認証ヘッダー文字列に対する HMAC-SHA256；タイムスタンプが 5 分以上古い場合は拒否します。
• SSRF 保護 — Webhook URL は HTTPS（プロダクション環境）、パブリック IP への解決、ドメイン名のみ（生 IP なし、プライベート/ループバック範囲なし）を使用する必要があります。
• OAuth CSRF — ステートパラメータに単回使用で有効期限のある nonce が含まれます。

開発モードよりも制限の緩いプロダクション環境（

E2A_ENV=production

SECURITY.md

データ処理 メッセージエンベルフと着信本体はデフォルトで 30 日間 Postgres に保持されます。出力的本体は HITL 終了時のスクリービング（除去）が施されます。API キーはハッシュとして保存され、添付ファイルは JSONB ロウに格納されます（S3/GCS は使用しません）。アプリケーションログには送信者/受信者アドレスが含まれます（標準的な MTA プラクティス）が、本体、添付ファイル、生キー、HMAC シークレットは含まれません。ユーザーは自己エクスポート（

GET /users/me/export

DELETE /users/me

docs/data-handling.md

FAQ

なぜ SendGrid / Resend / Postmark をそのまま使い、受信にはそれらの着信解析機能を利用しないのですか？ 重大な再構築なしに追加することは不可能な 4 つのポイントがあります：

1. パブリック URL 不要のローカルモードエージェント。 エージェントは API キーで認証し、

   /api/v1/agents/{email}/ws

   と WebSocket を開き、着信メールはその接続上で JSON として到着します。Webhook URL や ngrok、ポート転送は一切不要です。開発者ラップトップ、エッジデバイス、または企業ファイアウォールの背後にあるエージェントに有用です。SendGrid/Resend は設計上 Webhook 専用です。ポーリング REST API をフォールバックとして利用できます。
2. 各返信における会話スレッド処理。 人間が Gmail から返信するか、e2a エージェントが API で返信するかに関わらず、着信メッセージはエージェントに安定した

   conversation_id

   があり、それが元のスレッドに関連付けられています。人間送信者の場合、リレーは宛先エージェントのメッセージのスコープ内に限定された標準的な In-Reply-To / References 検索を行います。e2a と両側で動作するエージェント間では、制御できる X-E2A-Conversation-Id ヘッダー（MAIL FROM が自社のドメイン）も信頼し、クライアントがスレッドヘッダーを書き換えても耐性があります。SendGrid/Resend は着信メールを直接見ていないため、受信者ではありません。したがって、両方のパスを利用するには自前で構築する必要があります。
3. 共有ドメイン上のスラッグプロビジョニング。 運営者は

   shared_domain: agents.e2a.dev

   を設定し、ユーザーは

   {"slug": "my-agent"}

   を POST することで即座に DNS 構成不要で

   my-agent@agents.e2a.dev

   を取得します。e2a が SMTP リレーとしてドメインを主張しているため可能であり、Resend や SendGrid はプロバイダーであってプラットフォームではなく、リレーを自社で動かさない限り共有アドレス空間をマルチテナント化できません。
4. 内蔵 HITL ホールド ＋ 自動期限切れ。 エージェントごとの

   hitl_enabled

   フラグが着信メールを

   pending_approval

   ステータスに保持します。レビューアはダッシュボード、マジックリンク付きメール、または CLI を介して承認を行います。バックグラウンドワーカーは設定された

   hitl_expiration_action

   に基づいて期限切れのホールドを自動的に処理します（自動送信または破棄）。マジックリンクトークンは HMAC でエンコードされており、ステートレスでセッションバックエンドを必要としません。Resend や SendGrid ではメッセージを自社 DB で保持し、タイマー、承認 UI、ステートレスなレビュートークンを自ら構築する必要があります。

SES / Resend / SendGrid を e2a の出力的 SMTP として人間の送信に利用することは可能です —

config.yaml

outbound_smtp

なぜメールなのか？エージェント間の Webhook、gRPC、MCP ではダメですか？ 人間はすべてアドレスを持っており、動作するクライアントを持つのはメールのみです。Webhook / gRPC / MCP は制御するシステム内部では優秀ですが、Gmail や Outlook には到達しません。クライアントのインストールを強いることなく人間（または他組織のエージェント）と通信したい場合、メールは普遍的な基盤となります。 e2a は Webhook を置き換えるわけではありません — エージェントは Webhook を介してメールを受信します。e2a は、メールの普遍アドレス可能性を、エージェントコードがすでに住む構造化データの世界へと橋渡しします。

攻撃者が X-E2A-Auth- ヘッダーを偽造できない仕組みは何ですか？* リレーは着信メッセージからあらゆる

X-E2A-Auth-*

client.parse_webhook(body)

client.parseWebhook(body)

email.verify_signature(secret)

これらは単に SMTP にステップを追加しただけではありませんか？ はい — その追加ステップこそが目的です。具体的には：

• SPF/DKIM 判定の正規化により、受信者がドメイン認証を再実装する必要がありません。
• HMAC 署名付き配信契約で送信者、本体ハッシュ、メッセージ ID、検証ステータスをバインドします。
• パブリック URL を持たないエージェント向け WebSocket 転送層です。
• 自動期限切れとステートレスなマジックリンクレビューを備えた HITL 承認フローです。
• メール ↔ 構造化データの境界で耐性のある会話 ID スレッド処理です。
• 共有ドメイン上でのスラッグベースのエージェントプロビジョニングです。
• エージェントごとの Webhook ルーティング、レートリミット、HITL 設定などです。

これらを裸の Postfix に構築するのは実際のプロジェクトとなります。e2a はそのオープンソースプロジェクトです。

Postfix や Postal を自分自身で実行することに比べたらどうでしょうか？ 完全な MTA（メールトランスペーター）をお求めであれば MTA を実行してください — Postfix や Postal は優秀です。e2a は SMTP 転送層自体を置き換えることを意図していません（受信には go-smtp、送信には dial-out を使用）。価値は転送層の上位にある「認証モデル」「エージェントアブストラクション」「署名付き配信契約」「Webhook 失敗時の再試行ポリシー」「HITL 承認フロー」「SDK および CLI」にあります。MTA の運営に慣れ、メール配管のみが必要であれば e2a は必要以上に思えるかもしれません。一方、エージェントアブストラクションや署名付与された身元層を事前構築して利用したい場合は、これが適しています。

なぜホスト版があるのにオープンソースなのでしょうか？ 2 つの理由があります：

1. 監査可能性。 あなたのエージェントのための身元インフラは、 vendor ブlack box（ブラックボックス）ではなく、読めるコードであるべきです。ghcr.io/mnexa-ai/e2a の cosign サインを検証し、ビルドを再現し、実際に何の実行されているかを確認できます。
2. セルフホストを実際のオプションとする。 e2a.dev のホスト版は、今すぐプル可能な同じ ghcr.io/mnexa-ai/e2a イメージを実行しています。ホスト側の特権機能（共有ドメイン

   agents.e2a.dev

   、管理された配信性）は、クローズドソースの追加機能ではなく、設定 ＋ DNS によるものです。

ホスト版の価格は現在は有効化されていません。発売時には環境変数でオプトインとなり、OSS コードパスは変更されません。

開発ガイド

make build               # go build -o bin/e2a ./cmd/e2a
make run                 # ビルド ＋ 実行（cp config.example.yaml config.yaml を最初に行ってください）
make test                # すべての Go テスト（Postgres が :5433 で必要）
make test-unit           # Go ユニットテストのみ（DB 不要）
make test-integration    # インテグレーションテスト（Postgres が必要）
make test-e2e            # E2E テスト（Postgres が必要）
make docker-up           # Docker Compose でローカル Postgres を開始
make migrate             # ローカル DB に SQL マイグレーションを適用

完全な開発者ガイド（アーキテクチャ、テスト、コード生成、慣習）は

CLAUE.md

コントリビューション プルリクエストを送信することで、あなたのコントリビューションに対するデベロッパー証明書元源（DCO）を認証します。コミットに

git commit -s

ライセンス Apache 2.0 — LICENSE および NOTICE をご参照ください。