概要
警告には機能としてEMAILが付与されます。警告はレポートのemail_verifications[].warnings[]に表示され、標準の警告オブジェクトの形式(feature、risk、additional_data、log_type、short_description、long_description、node_id)に従います。各警告はセッションごとのログにも送られるため、Business ConsoleのEmailセクションにも表示されます。
一部の警告はハードな自動却下のトリガーです。これらは常に機能のステータスをDeclinedに設定し、log_type: "error"を伴います。それ以外の警告は、ワークフローノードごとまたはAPI呼び出しごとに定義される設定可能なアクション(DECLINE、REVIEW、またはデフォルトのNO_ACTION)に対応します。そのため、同じリスクコードでも、あるワークフローでは却下し、別のワークフローではフラグを立てるだけ、ということがあり得ます。設定したアクションによって重大度も決まります。DECLINEはerror、REVIEWはwarning、NO_ACTIONはinformationになります。
自動却下の条件
次の警告は、設定にかかわらず常にメールアドレス認証ステップを却下します。EMAIL_CODE_ATTEMPTS_EXCEEDED:ユーザーがOTPの試行回数を使い切りました。デフォルトでは、誤ったコードの入力2回(email_max_check_attempts)、またはOTPの送信2回(初回送信と再送信1回、email_max_retries)が上限です。EMAIL_IN_BLOCKLIST:メールアドレスがLists APIで管理されているブロックリストに含まれているか、過去に承認され、その後ブロックリストに登録されたメールアドレス認証と一致しました。UNDELIVERABLE_EMAIL_DETECTED:メールアドレスがメールを受信できません。原因は、無効な構文、存在しないドメイン、DNS(MX)レコードの欠如、またはOTPメールを配信できなかったことです。ステップは直ちにDeclinedとして確定し、コードの確認は一切行われません。例外として、ユーザーがメールアドレスを自分で入力した場合(セッション作成時に事前入力されていなかった場合)は、メールを配信できない場合はインラインのエラーが返され、却下される代わりに別のメールアドレスで再試行できます。
設定可能なリスク
次の各リスクは、DECLINE、REVIEW、NO_ACTIONのいずれかに設定できる設定項目(ワークフローノードごと、またはスタンドアロンのチェックエンドポイントでは呼び出しごと)に対応します。
重複検出の対象は、同じアプリケーション内の過去に承認済みのメールアドレス認証のみで、
vendor_dataごとにグループ化されます。同じvendor_dataを共有する認証は同一のエンドユーザーとして扱われ、対象から除外されます。vendor_dataを空のままにすると、すべてのセッションが別々のユーザーとして扱われます。メールアドレスがメールの許可リストに登録されている場合、重複に対するアクションはスキップされ、代わりにEMAIL_IN_ALLOWLISTが出力されます。
認証試行回数の制限
メールアドレス認証機能は、不正利用を防ぐためにOTPの試行回数に厳格な上限を設けています。- コード入力の試行回数:
email_max_check_attempts、デフォルトは2回です。2回目の誤ったコード(または期限切れのコード)でステップが確定します。 - 送信の試行回数:
email_max_retries、デフォルトは合計2回の送信(初回送信と再送信1回)です。それ以上の再送信リクエストでステップが確定します。
EMAIL_CODE_ATTEMPTS_EXCEEDEDが発生し、自動的に却下されます。どちらの上限もワークフローノードごとに調整できます。
発生する警告
1回の試行で発生するのは、
EMAIL_IN_BLOCKLIST、DUPLICATED_EMAIL、EMAIL_IN_ALLOWLISTのうち最大1つです。優先順位はブロックリスト、重複、許可リストの順です。
セッション間の一致
以前に承認されたメールアドレス認証またはブロックリストでアドレスが検出された場合、その一致はemail_verifications[].matches[]にも表示されます(最大5件)。各一致にはsession_id、session_number、vendor_data、verification_date、email、status、is_blocklisted、api_service、およびsession(別の承認済みの認証)またはlist_entry(ブロックリストのエントリ)のいずれかを示すsourceが含まれます。現在のアドレスがメールアドレスの許可リストに含まれている場合、Diditは一致の証跡を保持しますが、メールアドレス重複時のアクションを適用する代わりにEMAIL_IN_ALLOWLISTを発行します。一致の完全なスキーマについては、メールアドレス認証レポートを参照してください。
例
警告の種類
各リスクには、アプリケーションの設定に基づいて重大度が割り当てられます。重大度は次の3つのカテゴリに分かれます。関連ページ
- メールアドレス認証の概要:機能の動作と料金。
- メールアドレス認証レポート:
lifecycle[]とmatches[]を含むレスポンスの完全な構造。 - データモデル:メールアドレス認証:フィールドごとの正式なスキーマ。
- Management API:Lists:
EMAIL_IN_BLOCKLISTで使用されるメールアドレスのブロックリストを管理します。