web-dev-qa-db-ja.com

バックアップmxサーバーは、プライマリmxに接続できる場合、電子メールの送信を拒否するように構成できますか?

スパマーが使用する可能性のある手法の1つは、セカンダリメールサーバーにスパムを送信することです。これらのサーバーは強力ではない傾向があり、プライマリが持つすべてのスパムフィルタリングを備えていない可能性があるためです。

プライマリサーバーがまだ起動していてアクセス可能な場合に、受信メールを拒否するようにバックアップメールサーバーを設定できますか?セカンダリサーバーがセカンダリでsmtpセッションが開始されるとすぐに(helo/ehloの前でも)プライマリにすばやくpingを実行し、プライマリが応答した場合は拒否することを想像します。プライマリがまだオンラインの場合、優先度の低いメールサーバーに電子メールを送信する正当な理由はありません。

これは接尾辞で可能ですか?このアプローチに見当たらない落とし穴はありますか?

5

それは非常にお勧めできません。簡単に言えば、まったく間違っています。セカンダリサーバーがプライマリに接続できるからといって、1つ以上の正当なSMTPクライアントがプライマリに接続できるとは限りません。

複数のMXサーバーは、主にルーティングと接続の問題を処理するように設計されています(また、重み付けパラメーターは、優先サーバー、つまり最終的なローカル配信を行うサーバーを示唆するのに役立ちます)。 SMTPプロトコル自体は、電子メールを失うことなく、短時間の停止(最大数日)を処理するように設計されています。複数のMXサーバーを使用して、サーバーの停止、または必然的にラストワンマイルの接続の停止に対処しようとしないでください。

最近では、プライマリを信頼性の高い接続されたコロ/クラウドプロバイダーに配置し、他のすべてのMXサーバーを削除する方がよいでしょう。

本当に多くの着信接続を処理する必要がある場合は、プロビジョニングできる複数のサーバーで処理できます。次に、複数のサーバーを使用して、並列MXホストごとに1つずつ、複数のAレコードをMXホスト名に追加します。 (過去、そしておそらく今日でも、MXターゲットの複数のAレコードは、異なるターゲットホストの複数の等しい重みのMXレコードよりも均等に分散されます。)ただし、複数のホストを構成すると、コスト、メンテナンスの問題、およびセキュリティリスク。

概要:通常、追加のMXサーバーがすべての接続を拒否する場合は、追加のMXレコードをアドバタイズしないでください。その結果、いくつかの面でメールを失うことになります。

12
Greg A. Woods