メールをバウンスさせるか、ブラックホールに送信する必要がありますか？

私のマシンにはたくさんの未使用（古い、死んだ）アカウントがあります。それらの多くは、文字通り1日に数千の電子メールを受信し、すべてスパムです。

アカウントが人によって使用された場合、私は電子メールを返送させて、彼らに連絡を取ろうとする誰もが何かが間違っていることを知らせます。しかし、メールアドレスを要求するWebサイトで使用していた使い捨てのアカウントや、Webページにリストするために使用したアドレスなど、他の目的で使用された数百のアカウントについてどうすればよいかわかりません。 。

オプション1：
すべてのメールをこれらのアカウントに転送し/dev/nullます。送信者はバウンスを受け取りません。

オプション2：
メールをバウンスさせます。

にメールを送信する利点は/dev/null、スパマーが私を使用してバウンスメッセージ（バックスキャッタースパム）を生成できないことです。つまり、「差出人」の行を好きではない人に偽造し、私を使用して大量の返送メッセージをその人に送信します。

それらをバウンスすることの利点は、それが私にとってメンテナンスが少ないことです。エイリアスファイルからアイテムを削除するだけで、メールが返送されます。また、私は新しいスパムトラップを発見し、それらを私の「スパムブラックホール」リストに追加し続けます。これは時間の無駄です。

各アプローチの長所と短所は何ですか？

そもそも受信を拒否してメールをバウンスしている限り、スパマーはあなたを使って、多くのバウンスで無実の誰かを困らせることはできません。

RCPT TOコマンドにエラーが返される場合があります。これは、アドレスが存在しない場合に通常発生するものです。または、RCPT TOコマンドに成功したがの最後にエラーを返すこともできますDATA。

どちらの場合も、最終結果は同じになります。メールサーバーはメールの責任を負わず、送信メールサーバーがメールのバウンスを担当します。スパムの場合は、スパマーがバウンスを生成する必要があることを意味します。（そして、それが彼らがやりたかったことなら、そもそもメールをあなたに届けようとすることさえせずに、そうすることができたでしょう。）

私はこのアプローチに問題がないと思います。

ただし、メールの受信に問題があるようです。つまり、メールサーバーがの最後を含むトランザクション全体で成功した場合、メールサーバーDATAがメールの配信を担当します。適切な方法がないため、これは問題です。

• 正当なメールが送信された場合、送信者はそれが配信されなかったことを知ることができないため、サイレントにメールをドロップすることは問題です。
• メールサーバーからバウンスを送信することは問題です。その場合、スパムはスパマーに戻るのではなく、罪のない人のメールボックスにバウンスするためです。

そもそも電子メールアドレスの配布が非常に制限されていて、そのアドレスに正当なメールを送信できないことがわかっている場合があります。このような場合、RCPT TOコマンドを拒否したり、メールを受け入れて静かにドロップしたりしても、ほとんど違いはありません。しかし、SMTPトランザクション中にメールを拒否するよりも、静かにメールをドロップする方がよい状況を思いつくことはできません。

用語と構成の詳細は特定のメールサーバー/スパムフィルターソフトウェアによって異なるため、この回答はかなり一般的なものにします。

無効な受信者に対する実際のアプローチは3つあります。

1. 受信者が無効であると判断されたら、配信不能メッセージを送信者に送り返します。

2. メッセージがまだ「処理中」の間にSMTP接続を閉じます。送信者のSMTPサーバーは、配信不能メッセージの生成を担当します。

3. メッセージを受け入れ、サイレントに削除します。送信者は、メッセージが受信されたかどうかはわかりません。

アプローチ＃1を使用する理由はほとんどありません。バックスキャッター攻撃の場合、サーバーはスパマーのように見え（無害な犠牲者であっても）、ブラックリストに登録されます。また、バウンスメッセージを送信する必要があるため、サーバーとアップロードの帯域幅により多くの負荷がかかります。

アプローチ＃2は、アプローチ＃1よりも普遍的に優れています。サーバーがブラックリストに登録されたり、DoSされたりする可能性を減らします。それは無実の第三者アドレスに対する後方散乱の可能性を排除しませんが、少なくともあなたのサーバーはバウンスメッセージを送信するサーバーではありません。

アプローチ＃3は、後方散乱の可能性を排除します。また、ディレクトリハーベスト攻撃に対する防御にも役立ちます。ただし、これは、外部の送信者があなたのアドレスを誤って入力した場合、彼らがそれを知ることが決してないことも意味します。誰かがあなたの会社を辞め、顧客が元従業員に連絡を取ろうとした場合にも問題になる可能性があります。

DHAへの懸念から、アプローチ3を利用したメールシステムを継承しました。それは価値があるよりも多くのトラブルを引き起こしました。ここで、アプローチ＃2を使用します。（DHAを軽減する方法は他にもあることに注意してください。）

電子メールサーバーが適切に構成されている場合は、SMTPトランザクション中に不明なユーザーへの電子メールを拒否する必要があります。

SMTPトランザクション中に電子メールを拒否する

SMTPトランザクションフェーズ中に不明なユーザーへの電子メールを拒否するようにサーバーを構成する必要があります。これを行うと、送信サーバーに550 SMTPエラーコードが返されます。これはSMTPトランザクション中に発生するため、サーバーが配信不能レポート（バウンス）を送信することはありません。

適切に構成されていれば、拒否が送信サーバーに直接送信され、他の電子メールヘッダーが無視されるため、後方散乱が防止されます。

利点

このアプローチの利点は、SMTPトランザクションプロセスですぐに電子メールを拒否することです。これは次のことを意味します：

• 特に、すべての電子メールが受け入れられた後に処理のために送信される場合（ウイルス/ AVフィルタリング）、サーバーのリソース使用率を下げます。
• 送信者は、ブラックリストに登録されないように、これらのメールアドレスをリストから削除することがよくあります。

メールをnullルーティングした場合、送信サーバーはメッセージが正常に配信されたと見なします。これらの無効なアドレスへのメール送信を停止する理由はありません。その結果、これらの古いアドレスが積み重なるにつれて、電子メールを処理するためにますます多くのサーバーリソースが必要になります。

これを実装するには、電子メールシステムからユーザーを削除するだけです。現在の電子メールのバックアップが必要な場合は問題ありませんが、サーバーから550 user unknown応答を送信するだけです。