メールをバウンスするか、ブラックホールに送信する必要がありますか？
私のマシンにはたくさんの未使用（古い、死んだ）アカウントがあります。それらの多くは、文字通り1日に数千の電子メールを受信し、すべてスパムです。
アカウントが人によって使用された場合、私は電子メールを返送させて、彼らに連絡を取ろうとする誰もが何かが間違っていることを知らせます。しかし、メールアドレスを要求するWebサイトで使用していた使い捨てのアカウントや、Webページにリストするために使用したアドレスなど、他の目的で使用された数百のアカウントについてどうしたらよいかわかりません。 。
オプション1：
これらのアカウントへのすべてのメールを/dev/nullに転送します。送信者はバウンスを受信しません。
オプション2：
メールをバウンスさせます。
電子メールを/dev/nullに送信する利点は、スパマーが私を使用してバウンスメッセージを生成できないことです （後方散乱スパム） 。つまり、「from」行を偽造して嫌いな人にした後、私を使ってその人に大量のバウンスメッセージを送信します。
それらをバウンスすることの利点は、それが私にとってメンテナンスが少ないことです。エイリアスファイルからアイテムを削除するだけで、メールが返送されます。また、新しいスパムトラップを発見し、それらを「スパムブラックホール」リストに追加し続けています。これは時間の無駄です。
各アプローチの長所と短所は何ですか？
そもそもメールの受信を拒否してバウンスする限り、スパマーはバウンスの多い無実の人を困らせるためにあなたを使用することはできません。
RCPT TOコマンドでエラーを返すことができます。これは、アドレスが存在しない場合に通常発生するものです。または、RCPT TOコマンドで成功を返すことができますが、最後にエラーを返します。 DATA。
どちらの場合も、最終結果は同じになります。メールサーバーはメールに対して責任を負わず、送信メールサーバーはメールをバウンスする責任があります。スパムの場合、それはスパマーがバウンスを生成しなければならないことを意味します。 （それが彼らがやりたかったことなら、そもそもメールをあなたに届けようとすることさえせずに、そうすることができたでしょう。）
私はこのアプローチに問題がないと思います。
ただし、メールの受け入れに問題があります。つまりメールサーバーがDATAの終わりを含むトランザクション全体で成功した場合、メールサーバーがメールの配信を担当します。適切な方法がないため、これは問題です。
- 正当なメールが送信された場合、送信者はそれが配信されなかったことを知ることができないため、メールをサイレントにドロップすることは問題です。
- メールサーバーからバウンスを送信することは問題です。その場合、スパムはスパマーに戻るのではなく、無実の人のメールボックスにバウンスするからです。
そもそも電子メールアドレスの配布が非常に制限されていて、そのアドレスに正当なメールが送信されないことがわかっている場合があります。そのような場合、RCPT TOコマンドを拒否しても、メールを受け入れて静かにドロップしても、ほとんど違いはありません。しかし、SMTPトランザクション中にメールを拒否するよりも、サイレントにメールをドロップする方がよいという状況を思いつくことはできません。
用語と構成の詳細は特定のメールサーバー/スパムフィルターソフトウェアによって異なるため、この回答をかなり一般的なものにします。
無効な受信者には、実際には3つのアプローチがあります。
受信者が無効であると判断されたら、配信不能メッセージを送信者に送り返します。
メッセージがまだ「処理中」の間にSMTP接続を閉じます。送信者のSMTPサーバーは、配信不能メッセージの生成を担当します。
メッセージを受け入れて、黙って削除します。送信者は、メッセージが受信されたかどうかを知りません。
アプローチ＃1を使用する理由はほとんどありません。バックスキャッター攻撃の場合、サーバーはスパマーのように見え（無害な犠牲者であっても）、ブラックリストに登録されます。また、バウンスメッセージを送信する必要があるため、サーバーとアップロードの帯域幅により多くの負荷がかかります。
アプローチ＃2は、アプローチ＃1よりもほぼ普遍的に優れています。サーバーがブラックリストに登録されたり、DoSedされたりする可能性を減らします。それは無実の第三者アドレスに対する後方散乱の可能性を排除しませんが、少なくともあなたのサーバーはバウンスメッセージを送信するサーバーではありません。
アプローチ＃3は、後方散乱の可能性を排除します。 Directory Harvest Attack から保護するのにも役立ちます。ただし、外部の送信者があなたのアドレスをタイプミスした場合、彼らは決して知らないことも意味します。誰かがあなたの会社を辞め、顧客が元従業員に連絡を取ろうとした場合にも問題になる可能性があります。
DHAへの懸念から、アプローチ3を利用したメールシステムを継承しました。それはそれが価値があるより多くのトラブルを引き起こしました。ここで、アプローチ＃2を使用します。 （DHAを軽減する方法は他にもあることに注意してください。）
電子メールサーバーが適切に構成されている場合は、SMTPトランザクション中に不明なユーザーへの電子メールを拒否する必要があります。
SMTPトランザクション中に電子メールを拒否する
サーバーは、SMTPトランザクションフェーズ中に不明なユーザーへの電子メールを拒否するように構成する必要があります。これを行うと、送信サーバーに550 SMTPエラーコードが返されます。これはSMTPトランザクション中に発生するため、サーバーが配信不能レポート（バウンス）を送信することはありません。
適切に構成すると、拒否が送信サーバーに直接送信され、他の電子メールヘッダーが無視されるため、後方散乱が防止されます。
メリット
このアプローチの利点は、SMTPトランザクションプロセスですぐに電子メールを拒否することです。これは次のことを意味する可能性があります。
- 特に、すべての電子メールが受け入れられた後に処理のために送信される場合（ウイルス/ AVフィルタリング）、サーバーのリソース使用率が低くなります。
- 送信者は多くの場合、ブラックリストに登録されないように、これらのメールアドレスをリストから削除します。
電子メールをnullルーティングすると、送信サーバーはメッセージが正常に配信されたと見なすと考えてください。これらの無効なアドレスへの電子メール送信を停止する理由はありません。その結果、これらの古いアドレスが積み重なるにつれて、電子メールを処理するためにより多くのサーバーリソースが必要になります。
これを実装するには、電子メールシステムからユーザーを削除するだけです。現在の電子メールのバックアップが必要な場合、それは問題ありません。サーバーに550 user unknown応答を送信させたいだけです。