ブログに戻る
セキュリティ

OpenClawの使い捨てメールをブロックする

Josselin Liebe
Josselin Liebe

OpenClawを使えば、ユーザーデータを処理する自動化ワークフローを簡単に構築できます。ワークフローのいずれかのステップでメールアドレスを収集または使用している場合 - リードフォーム、サインアップトリガー、別のツールからのWebhook - そのメールアドレスは使い捨てである可能性があります。このガイドでは、Veille APIを使用してOpenClawワークフロー内に直接使い捨てメールチェックを追加する方法を説明します。

自動化ワークフローでこれが重要な理由

ワークフローが使い捨てメールアドレスを処理すると、その後のステップでいくつかの問題が発生する可能性があります:

  • アウトリーチシーケンスが存在しない受信ボックスにメールを送信し、バウンス率が上昇します。
  • CRMレコードが転換しない連絡先で埋まります。
  • トライアルのプロビジョニング紹介クレジットが偽アカウントに対して実行されます。
  • レポートが不正確になります。偽のサインアップが本物のリードとしてカウントされるためです。

これらのステップが実行される前にワークフローレベルで問題を検出することは、後からデータをクリーンアップするよりも簡単です。

使い捨てメールがアカウント詐欺にどのように使用されるかについて詳しくは、How disposable emails are used in account fraudをご覧ください。

チェックの仕組み

Veille メール検証APIは単一のメールアドレスを受け取り、以下を含む構造化されたレスポンスを返します:

  • disposable - ドメインが既知の使い捨てメールプロバイダーである場合に true
  • risk_score - 0(安全)から100(高リスク)までのスコア
  • dns.mx - ドメインに設定されたメールサーバーがあるかどうか
  • smtp_valid - 特定の受信ボックスがメールを受信できるかどうか

必要なのは1回のHTTP GETリクエストのみです。SDKもライブラリも不要です。OpenClawのHTTPノードであればどれでもこの呼び出しを行うことができます。

OpenClawでワークフローを設定する

ステップ1 - トリガー

メールアドレスを提供するトリガーから始めます。一般的なソース:

  • フォーム送信(WebhookまたはネイティブフォームトリガーT)
  • CRMイベント(新しい連絡先の追加)
  • Webhook(Stripe、Typeform、Notionなどのサードパーティツールから)

トリガーの出力には、後のステップで参照できる email フィールドが含まれている必要があります。

ステップ2 - HTTPリクエストノード(Veille API呼び出し)

HTTPリクエストノードを追加し、次のように設定します:

フィールド
メソッド GET
URL https://api.veille.io/v1/intelligence/email
クエリパラメータ - query {{trigger.email}} (メール変数)
ヘッダー - x-api-key Veille APIキー

ノードはJSONレスポンスを返します。最も重要なフィールドは disposablerisk_score です。

ステップ3 - 条件ノード

HTTPリクエストの後に条件ノードを追加します。次のロジックを設定します:

IF disposable == true  →  ブランチ: ブロック
IF risk_score >= 75    →  ブランチ: ブロック
ELSE                   →  ブランチ: 続行

OpenClawのバージョンによって条件の処理方法が異なるため、OR論理を使用した単一の条件、または2つの別々のブランチを使用できます。

ステップ4 - ブロックブランチ

ブロックブランチで、拒否されたエントリに対して何を行うかを選択します:

  • 追加のアクションなしにワークフローを停止する(最もシンプルなオプション)
  • CRMの連絡先にタグまたはラベルを追加して無効としてマークする
  • レコードを別のリストやスプレッドシートに移動して手動でレビューする
  • 内部通知を送信してチームが活動を把握できるようにする

ステップ5 - 続行ブランチ

続行ブランチでは、ワークフローが通常通り進みます: アカウントのプロビジョニング、ウェルカムメールの送信、CRMの更新、チームへの通知、またはあなたの通常のフローで行うその他の処理。

risk_scoreを使用した段階的な対応

disposable フィールドは既知の使い捨てメールプロバイダーを検出します。risk_score は、どのブロックリストにも含まれていないが疑わしいシグナルを示すドメイン - 最近登録されたドメイン、メールサーバーの欠如、異常なパターン - のカバレッジを追加します。

risk_score に基づく段階的なアプローチ:

risk_score アクション
0–49 通常通り続行
50–74 続行、レビューフラグを追加
75–100 ブロック

これにより、すべての境界線上のケースをハードブロックすることなく、最も明白なリスクを除去できます。

プライバシーリレーアドレスの処理

Apple Hide My Email、Firefox Relay、SimpleLogin、addy.ioなどのサービスは、一見異常に見える転送アドレスを生成します。これらはプライバシー保護を選択した実際のユーザーのものです。

誤ってブロックするのを防ぐため、Veille API呼び出しの前に、ドメインが既知のプライバシーリレーと一致するかどうかを確認する条件ノードを追加します:

IF email domain is one of:
  privaterelay.appleid.com
  relay.firefox.com
  simplelogin.co
  addy.io
  anonaddy.com
→ Skip the Veille check and go directly to Continue

Veille APIは既知のプライバシーリレープロバイダーのアドレスに低い risk_score 値を割り当てるため、手動の許可リストがなくてもスコアのしきい値によってブロックされる可能性は低いです。

ワークフローの全体構造

[Trigger: form / webhook / CRM event]
        ↓
[Condition: is domain a privacy relay?]
   YES ↓            NO ↓
[Continue]   [HTTP Request: Veille API]
                     ↓
            [Condition: disposable OR risk_score ≥ 75?]
               YES ↓            NO ↓
            [Block branch]   [Continue branch]

APIレスポンスの例

使い捨てアドレスに対してVeille APIを呼び出すと、次のようなレスポンスが返されます:

{
  "email": "user@mailinator.com",
  "disposable": true,
  "risk_score": 95,
  "role_account": false,
  "dns": {
    "mx": true
  },
  "smtp_valid": false
}

正当なアドレスの場合:

{
  "email": "contact@example.com",
  "disposable": false,
  "risk_score": 12,
  "role_account": false,
  "dns": {
    "mx": true
  },
  "smtp_valid": true
}

OpenClawの一般的なユースケース

リードエンリッチメントワークフロー - フォームからCRMに連絡先が追加されます。連絡先がアウトリーチシーケンスに入る前に、Veilleでメールを確認します。disposable: false かつ risk_score < 75 の連絡先のみがシーケンスに入ります。

トライアルサインアップの自動化 - 新しいユーザーが無料トライアルに申し込みます。サインアップWebhookがVeilleを呼び出すOpenClawワークフローをトリガーします。メールが使い捨ての場合、プロビジョニングステップがスキップされてレコードにフラグが立てられます。

紹介プログラムの処理 - 紹介の申請が受信されます。紹介クレジットが適用される前に、Veilleがメールを確認します。リスクの高いメールは自動クレジットの代わりに手動レビューをトリガーします。

ウェイトリストの検証 - ローンチ前にウェイトリストでバッチワークフローが実行されます。各メールがVeille APIに対してチェックされます。招待状が送信される前に使い捨てエントリが別のシートに移動されます。

関連記事