コールバック検証

コールバック検証は、コールアウト検証または送信者アドレス検証とも呼ばれ、電子メール アドレスを検証するためにSMTPソフトウェアで使用される手法です。検証の最も一般的な対象は、メッセージ エンベロープの送信者アドレス (SMTP ダイアログで「 MAIL FROM」として指定されたアドレス) です。これは主にスパム対策として使用されます。

電子メールのスパムの大部分は偽造された送信者（「mfrom」）アドレスから生成されるため^{[引用が必要]}、この方法を使用して、偽造によって無効なアドレスが生成されていないかどうかを確認することで、一部のスパムを検出できます。

関連する技術として「コール転送」があります。これは、セカンダリ メール エクスチェンジャーまたはファイアウォール メール エクスチェンジャーがドメインのプライマリ メール エクスチェンジャーで受信者を確認し、アドレスが配信可能かどうかを判断できる技術です。

受信メール サーバーは、送信者アドレスの両方の部分、つまりドメイン名 (@ 文字の後の部分) とローカル部分 (@ 文字の前の部分) を検証することで、送信者アドレスを検証します。最初の手順は、送信者アドレスのメール エクスチェンジャーへの SMTP 接続を確立することです。メール エクスチェンジャーは、ドメインの DNS ゾーンでMX レコードを検索することで見つかります。2 番目の手順は、エクスチェンジャーにクエリを実行し、アドレスが有効なものとして受け入れられることを確認することです。これは、そのアドレスに電子メールを送信するのと同じ方法で行われますが、メール エクスチェンジャーが受信者アドレスを受け入れるか拒否すると、プロセスは停止します。これらは、受信メール サーバーが送信者にメールを返送するために実行するのと同じ手順ですが、この場合はメールは送信されません。送信される SMTP コマンドは次のとおりです。

HELO検証ホスト名
メール送信元:<>
RCPT TO:<テストするアドレス>
やめる

同様に、MAIL FROM コマンドと RCPT TO コマンドは VRFY コマンドに置き換えることができますが、VRFY コマンドはサポートされる必要はなく、通常、最新の MTA では無効になっています。

これらの手法は両方とも、関連する SMTP RFC (RFC 5321) に技術的に準拠していますが、RFC 2505 (現在のベスト プラクティス) では、ディレクトリ ハーベスト攻撃を防ぐために、デフォルトで VRFY コマンドを無効にすることを推奨しています。(広く普及している解釈の 1 つは、MAIL FROM/RCPT TO コマンドのペアも同様に応答する必要があることを示唆していますが、これは RFC では明記されていません。)

コールバック検証は不正行為であり^[1] 、サーバー、ドメイン、またはIPブロックの ブロックリスト化につながる可能性があります。

メール サーバーの管理者が VRFY を無効にしている場合、それを回避する方法として RCPT TO を使用することは、不正アクセスであり、アクセス制御を回避しようとする試みです。そのため、オペレーターは、管轄区域に応じて民事訴追または刑事訴追を受ける可能性があります。

postfixとeximの両方のドキュメントでは、この技術の使用に対して警告^{[2] [3]}が示されており、SMTPコールバックの多くの制限について言及しています。特に、この技術が効果的でなかったり、コールバックを受信するシステムに問題を引き起こしたりする状況が多くあります。

• 通常のメール エクスチェンジャーの中には、コールバックに対して有用な結果を提供しないものもあります。
  • ^{すべてのバウンスメールを拒否するサーバー（STD 3 [4]}の一部である RFC 1123 に反する）。この問題を回避するために、たとえば postfix は、コールアウトの MAIL FROM 部分にローカル ポストマスターアドレスまたは「ダブル バウンス」のアドレスを使用します。ただし、この回避策には 2 つの問題があります。1 つ目は、検証ループが発生する可能性があることです。2 つ目は、バックスキャッタを減らすためにバウンス アドレス タグ検証が使用されている場合は失敗します。^[1]そのため、この回避策は使用しないでください。すべてのバウンスの拒否が、以前の MAIL FROM ステージではなく DATA ステージで行われ、無効な電子メール アドレスの拒否が DATA ステージに移動されるのではなく、RCPT TO ステージにとどまる場合は、コールバック検証は機能します。^{[2] [3]}
  • RCPT TO ステージですべての電子メール アドレスを受け入れ、DATA ステージで無効なものを拒否するサーバー。これは通常、ディレクトリ ハーベスト攻撃を防ぐために行われ、設計上、電子メール アドレスが有効かどうかに関する情報は提供されないため、コールバック検証が機能しません。^{[2] [1]}
  • SMTP ダイアログ中にすべてのメールを受け入れるサーバー (その後、独自のバウンスを生成します)。^[2]この問題は、目的のアドレスだけでなく、ランダムに存在しないアドレスをテストすることで軽減できます (テストが成功した場合、それ以上の検証は無意味です)。
  • キャッチオール メールを実装するサーバーは、定義上、すべてのメール アドレスを有効と見なし、受け入れます。受け入れてバウンスするシステムと同様に、ランダムに存在しないアドレスによってこれを検出できます。
• コールバックプロセスは、アドレスが検証されるメールサーバーが「グリーティング遅延」（接続遅延の原因）やグレーリスト（検証の延期の原因）などの低速のスパム対策技術を使用している可能性があるため、配信の遅延を引き起こす可能性があります。^[2]
• コールバック先のシステムがグレーリストを使用している場合、コールバックはグレーリストの時間が経過するまでは有用な情報を返さない可能性があります。グレーリストは、見慣れない MAIL FROM/RCPT TO の電子メール アドレスのペアを見つけたときに「一時的な失敗」(4xx 応答コード) を返すことによって機能します。グレーリスト システムでは、RCPT TO に無効な電子メール アドレスが指定された場合、「永続的な失敗」(5xx 応答コード) を返さず、代わりに 4xx 応答コードを返し続ける場合があります。^[5]
• 一部の電子メールは正当なものですが、ユーザーのエラーや設定ミスにより、有効な「送信元」アドレスがない場合があります。良い点は、検証プロセスによって通常は完全に拒否されるため、送信者がスパマーではなく実際のユーザーである場合は、問題が通知されることです。
• サーバーが大量のスパムを受信すると、コールバックを大量に行う可能性があります。これらのアドレスが無効またはスパムトラップである場合、サーバーはアドレスを収集するために辞書攻撃を行っているスパマーと非常によく似ています。これにより、サーバーは他の場所でブラックリストに登録される可能性があります。^{[2] [1] [6]}
• 管理者によっては、コールバック検証を迷惑メール (UBE) と見なし、バックスキャッターのボリュームが低い場合でも、発信元の SMTP クライアントをブロックしたり、スパムとして報告したり、 DNSBLに追加したりすることがあります。
• すべてのコールバックは、コールバック先のシステムに望まない負担をかけますが、そのシステムがその負担を回避する効果的な方法はほとんどありません。極端な場合、スパマーが同じ送信者アドレスを悪用し、この方法を使用する十分に多様な受信MXセットでそれを使用すると、全員がコールバックを試み、偽造アドレスのMXにリクエストで過負荷をかける可能性があります（事実上、分散型サービス拒否攻撃）。^[1]
• ^{スパマーが実際のメールアドレスを偽装したり[1] [7]}、ヌルバウンスアドレスを使用したりした場合、コールバック検証は効果がありません。

これらの問題の一部は、発信システムが RFC の制限に違反したり、制限を超えたりすることから生じます。検証の問題は、意図せずに無効なアドレスを使用したり、ヌル送信者を拒否したり、グレーリスト化 (たとえば、検証受信者によって発生した遅延が発信者によって発生した遅延と密接に関連している場合) など、送信者にのみこれらの問題を反映します。多くの場合、これは発信システムが問題を検出して修正するのに役立ちます (意図せずに有効なバウンスを受信できないなど)。

上記の問題のいくつかは、検証結果をキャッシュすることで軽減されます。特に、有用な情報を提供しないシステム (RCPT TO の時点で拒否しない、キャッチオール メールなど) は記憶され、今後それらのシステムへのコールバックは不要になります。また、特定のメール アドレスの結果 (肯定的または否定的) を記憶することもできます。Exim などの MTA にはキャッシュが組み込まれています。^[3]

• スパムリンク: 送信者コールアウト検証^[盗用]
• 送信者検証 — フリーソフトウェア財団