Sendercallouts（送信者アドレス検証）-これが悪い理由

現在のほとんどのMTAにはSendercalloutを使用する機能があります-これは、SMTPサーバーに接続するときです.SMTPセッション中に指定された送信者アドレスを確認するには、リモートサーバーに接続し、このアドレスにメールを送信してそのようなアドレスが存在するかどうかを確認します。

特に負荷を軽減するために他のすべてのチェックの後に適用する場合、非常に便利なように見えます。 サーバーからの接続を受信し、RCTP TOステージに到達するサーバーは非常に単純に機能します：<our_user@domain.tld>は、example.comへの接続を開き、RCPT TO：<someone@example.com>コマンドの後、応答が250である場合に電子メールを送信しようとしますサーバーはリモートサーバーへの接続を閉じ、メッセージ本文の送信を許可します。 そして、返信先アドレスが存在しないロボットからのメールが表示されるまで、これは正常に機能します。 これは、ホワイトリストの必須サポートによって解決されます。 実際には、送信者のアドレスが偽造される可能性があることは誰もが知っています。 SMTPサーバーでDDOS攻撃が行われた場合、混乱状態にあるサーバーは、リモートサーバーのノックの送信者のヘッダーを多数のリクエストでチェックし始め、おそらく最終的には禁止されます。

両方のサーバーにSAVをインストールすると、さらに悪いことに、アドレスをチェックする無限ループに陥る可能性が高くなります。 最初のメールは電子メールを送信し、2番目のメールは451 Unverifiedに応答し、最初のメールに接続しようと試みます。 もちろん、特定の構成ではこれを回避できますが、リモートサーバーの構成はわかりません。

したがって、送信者チェックのために、 RFC2821で説明されているVRFYコマンドがあります。 以前は、ほぼすべての場所で有効になっており、スパマーは、辞書を使用して検索することで正常に機能する電子メールを検索するのによく使用していました。 その後、既存のアドレスへのスパムの流れを減らすためにあらゆる場所でオフにし始め、その結果、1万年後、再びSAVを使用してそれに戻ろうとしました。 ほとんどすべてのMTAにはVRFYチームがありますが、保護はありません。

PostfixでRCTP TO：<user@example.com>コマンドに250 OKを送信する前に多くのチェックを行うことができると仮定しますが、これらの制限はVRFYコマンドには使用できませんが、もちろん送信者を認証しません。 DomainKeys Identified Mailを使用して、送信者を認証できるようになりました。