バックスキャッター(アウトスキャッター、誤送信バウンス、ブローバック、または付随スパムとも呼ばれる) は、通常は受信スパムの副作用として、メール サーバーによって誤って送信される自動バウンス メッセージです。
このようなメッセージの受信者は、受信者が要求していないため、迷惑メールまたはスパムの一種と見なします。これらのメッセージは実質的に類似しており、大量に配信されます。電子メールのバックスキャッターを生成するシステムは、さまざまな電子メール ブラックリストに掲載され、インターネット サービス プロバイダーの利用規約に違反している可能性があります。
バックスキャッターは、ワームやスパムメッセージが送信者アドレスを偽装することが多いために発生します。[1]スパムメッセージを単に拒否するのではなく、誤って構成されたメールサーバーは、そのような偽装されたアドレスにバウンスメッセージを送信します。これは通常、メールサーバーがメッセージをキュー後の処理手順、たとえばウイルス対策スキャンやスパムチェックに中継するように構成されていて、それが失敗し、ウイルス対策スキャンやスパムチェックが完了した時点でクライアントがすでに切断されている場合に発生します。このような場合、クライアントはウイルス対策スキャンやスパムチェックの終了を待っている間にタイムアウトするため、 SMTPトランザクションを拒否することは通常できません。この場合、バックスキャッターを作成するリスクを冒すのではなく、メッセージを黙ってドロップするのが最善です。
この問題を軽減するための対策としては、ほとんどの拒否を最初のSMTP接続段階で行うことでバウンス メッセージの必要性を回避すること、その他のケースでは、偽造されていないと確実に判断できるアドレスにのみバウンス メッセージを送信することなどが挙げられます。このようなケースでは、送信者が検証できないため、メッセージを無視します (つまり、破棄します)。
原因
スパムやウイルスの作成者は、受信者がメッセージを開かないように、メッセージが正当なソースから送信されたように見せかけたいと考えます。そのため、多くの場合、Web クロール ソフトウェアを使用して、 Usenet の投稿、メッセージ ボード、Web ページを スキャンし、正当な電子メール アドレスを探します。
SMTPメールの設計上、偽造されたメッセージを受信する受信メール サーバーには、送信者の信頼性を判断するための単純または標準的な方法がありません。接続フェーズでメールを受け入れ、さらに確認した後で拒否した場合 (たとえば、ソフトウェアがメッセージをスパムである可能性が高いと判断した場合)、サーバーは (偽造された可能性のある) 送信者のアドレスを使用して、問題を見かけ上の送信者に報告する誠意ある努力を試みます。
メール サーバーは、配信できないメッセージを 4 つの根本的に異なる方法で処理できます。
- 拒否。受信サーバーは、送信サーバーがまだ接続されている間に、接続段階で受信メールを拒否できます。接続時にメッセージが 5xx エラー コードで拒否された場合、送信サーバーは実際の送信者に問題を明確に報告できます。
- ドロップ。受信側サーバーは、最初はメッセージ全体を受け取りますが、その後、それがスパムまたはウイルスであると判断し、場合によっては最終的な受信者を「/dev/null」などに書き換えて自動的に削除します。この動作は、電子メールの「スパム スコア」が非常に高い場合や、メールにウイルスが含まれている場合に使用できます。RFC 5321 では、「メッセージが深刻な詐欺または不適切であるという確信が非常に高い場合にのみ、メッセージをサイレントにドロップすることを検討してください」と述べられています。
- 隔離。受信側サーバーは、最初はメッセージ全体を受け取りますが、その後、スパムであると判断して隔離します。つまり、 「ジャンク」または「スパム」フォルダーに配信され、最終的には自動的に削除されます。これは一般的な動作です。
- バウンス。受信側サーバーは、最初はメッセージ全体を受け入れますが、その後、それがスパムであるか、存在しない受信者宛であると判断し、メッセージの配信に失敗したことを示すバウンス メッセージを想定された送信者に返送します。
バックスキャッターは、「バウンス」方式が使用され、受信メールの送信者情報が無関係な第三者のものであった場合に発生します。
問題の軽減
ワームやスパム メッセージを制御するためのあらゆる手順は バックスキャッターの削減に役立ちますが、このセクションのような他の一般的なアプローチでも同じ問題が軽減されます。
接続段階の拒否
最初のSMTP接続中に、メールサーバーはさまざまなチェックを行うことができ、送信サーバーがまだ接続されている間は、 5xxエラーコードでメールを拒否することがよくあります。このように接続段階でメッセージを拒否すると、通常、送信 MTAはローカルの認証済みユーザーに対してローカルバウンスメッセージまたは配信不能通知(NDN)を生成します。[2]
拒否の理由は次のとおりです:
- 受信者検証失敗[3] [4] [5]
- SPF、DKIM、Sender IDなどの偽造防止チェックに失敗した
- 前方確認された逆DNSエントリを持たないサーバー
- ブロックリストに登録された送信者[6]
- グレーリスト方式による一時的な拒否
メールを転送するメール転送エージェント(MTA) は、透過的な SMTP プロキシを使用することでバックスキャッターの生成を回避できます。
バウンス受信者の確認
電子メールのバウンス メッセージを送信するメール サーバーは、さまざまな手段を使用して、返信先アドレスが偽造されているかどうかを判断できます。
後方散乱のフィルタリング
バックスキャッターを防ぐことが望ましいですが、フィルタリングすることでその影響を軽減することも可能であり、多くのスパムフィルタリングシステムには、バックスキャッターメールをスパムとして検出して拒否するオプションが含まれています[7]。
さらに、バウンス アドレス タグ検証などのスキームを使用するシステムは、受信した偽のバウンス メッセージを確実に検出できるように、送信メールに「タグ」を付けます。
参照
参考文献
- ^ 「通信ネットワークのセキュリティとプライバシーに関する第 3 回国際会議の議事録」。2007年通信ネットワークのセキュリティとプライバシーに関する第 3 回国際会議およびワークショップ - SecureComm 2007。IEEE。2007年。pp. i. doi :10.1109 / seccom.2007.4550292。ISBN 978-1-4244-0974-7。
- ^ あるいは、MTAがメッセージを中継している場合は、リバースパスに示されているように、そのようなNDNをもっともらしい発信者に
のみ
送信する必要があります。Klensin , J (2001年4月)、Simple Mail Transfer Protocol、IETF、p. 25、doi : 10.17487/RFC2821、RFC 2821たとえば、 SPFチェックに合格した場合などです。 - ^ 送信者と受信者のフィルタリングの隠れた力、MS Exchange.org。
- ^ 「受信者フィルタリングの構成」、Technet、Microsoft
- ^ 「受信者アドレス検証」、アドレス検証の readme、Postfix.org。
- ^ Marsono, MN (2007)、「SMTP セッション中のスパムの拒否」、Proc. Communications, Computers and Signal Processing、Pacific Rim: IEEE、pp. 236–39。
- ^ 「「ウイルスバウンスルールセット」は、バックスキャッターをキャッチするための SpamAssassin ルールセットです」
外部リンク
- 配信不能メッセージによるメール DDoS 攻撃(PDF)、Techzoom、2004 年、オリジナル(論文)から2013 年 1 月 16 日にアーカイブ、2008 年 4 月 11 日に取得。
- 「バックスキャッター」、Postfix (readme)。
- 「Backscatter」、SpamLinks、2008-04-05 にオリジナルからアーカイブ
{{citation}}: CS1 maint: unfit URL (link)。 - RFC 3834: 電子メールへの自動応答に関する推奨事項。
- 「愚かなメール自動応答」、地獄からの FAQ、FI: Iki。
- 「なぜ自動応答はダメなのか?」FAQ、SpamCop。
- スパムを返さない: スパムをバウンスしてはいけない理由。
- 100 通のメールがバウンスバック? PC World がバウンスバックしています。
