スパム報告(より正確には不正報告) とは、電子メッセージを不正なものとして指定し、当局 (電子メール管理者など) に報告して対処してもらう行為です。報告されるメッセージは、電子メール メッセージ、ブログ コメント、またはあらゆる種類のスパムです。
ウェブサイトのユーザー生成コンテンツにフラグを付ける
不正報告は、ユーザーが他のユーザーの投稿を不正コンテンツとして報告できる特別な種類のフィードバックです。ユーザー生成コンテンツを許可しているほとんどのウェブサイトでは、不正報告に基づいて、定義されたしきい値で問題のあるコンテンツを非表示または削除するなどの何らかのモデレーションを適用するか、ユーザーが協力してサイトのコンテンツを管理できるようにさまざまなユーザーロールを実装します。[1]
メールスパム報告
スパマーの行動は、何らかの方法でユーザーにオプトインを強制することから、協力的にオプトアウトの可能性を提供すること、送信者の身元を完全に隠すこと(フィッシングを含む)まで多岐にわたります。最も手に負えないケースは、他の被害者の利益のために、例えばVipul's Razorのようなハッシュ共有システム[2]に不正なメッセージを報告することで対処できます。場合によっては、送信者側に協力的な要素があり、スパム報告を使用して問題を発生元で修正または緩和することがあります。例えば、スパム報告を使用してボットネットを検出したり、[3]送信者を教育したり、単に報告の発信者の登録を解除したりすることがあります。 電子メールのスパムに関する法律は国によって異なり、ある程度は不正な行動を禁止していますが、スパマーを起訴して損害賠償を請求する価値がある場合もあります。
RFC 6650 では、不正なメッセージを受け取った受信者は、そのことをメールボックス プロバイダーに報告することを推奨しています。プロバイダーの不正対策チームは、ハッシュ共有や法的措置も考慮しながら、最善の対応策を決定する必要があります。送信者がフィードバック ループ (FBL)に加入していた場合、メールボックス プロバイダーは、既存の FBL 契約に従って、苦情をフィードバック レポートとして転送します。[4]それ以外の場合、メールボックス プロバイダーは、不正行為の責任者を特定し、苦情をその責任者に転送する必要があります。迷惑な不正報告の受信者は、実際には潜在的な FBL 加入者であり、メールボックス プロバイダーは、報告ストリームを管理する手段を受信者に提供する必要があります。一方、メールボックス プロバイダーは、不正なコンテンツの非協力的な送信者からのさらなるメッセージをブロックできます。[5]
不正報告は、メールボックスの実装によってより直接的な手段が提供されている場合を除いて、不正報告フォーマット(ARF)を使用して電子メールで送信されます。不正報告の宛先アドレスは、不正メッセージが報告される機関によって異なります。選択肢には次のものがあります。[6]
- SpamCopや Abusix の blackhole.mxなどのパブリック レポート ハブ、またはグローバル レピュテーション トラッカー。さまざまなハブと適切にやり取りするには、さまざまなレベルのスキルが必要です。
- エンドユーザーには、ドメイン固有のレポートハブが推奨されます。[7]提供される場合は、メールクライアント の目に見えるボタンまたはメニュー項目からアクセスできる必要があります。
- フィードバックループ サブスクライバーは、エンド ユーザー レポートを受け取った後、メールボックス プロバイダーによってターゲットとして選択されることがあります。ユーザーはプロバイダーのポリシーに注意する必要があります。
- 報告されたメッセージを処理した 認証済みドメインの不正使用POC。DomainKeys Identified Mail(DKIM)は通常の認証プロトコルですが、 [8] Sender Policy Framework(SPF)も同様に使用できます。メールボックスプロバイダーの選択。
- 最後のリレーのIP アドレスの不正使用POC。このようなデータを適切に見つけるには、ある程度のスキルが必要です。これは、サーバーが不正使用メッセージを受信し (受信者が報告する前に)、関連する IP アドレスに注釈を付けたメールボックス プロバイダーのデフォルトの選択肢です。Network Abuse Clearinghouse (名前別)、Abusix (IP アドレス (番号) 別) など、POC データベースを管理するさまざまなサイトがあります。また、関連する地域インターネット レジストリ(RIR) には委任の階層があり、対応する各Whoisレコードには、コメントとして、またはより具体的なデータベース オブジェクト (例:インシデント対応チーム)として、POC が含まれる場合があります。
最初の 3 つの方法では、レポートの送信先となる完全な電子メール アドレスを指定します。それ以外の場合、対象となる不正使用メールボックスは、RFC 2142 で定義されている形式 ( abuse@example.com ) であると想定するか、RIR のwhoisデータベース (クエリ結果の制限がある場合があります[9])またはこの目的のために特別に作成された他のデータベースのいずれかを照会して決定できます。正確な不正使用 POC の公開を義務付ける傾向があります。[10] [11]
悪用された受信者は、さまざまなレベルでスパム報告を自動化できます。メッセージが表示されたらボタンを押すか、スパムと認識されたメッセージを自動的に隔離して報告するツールを実行することができます。特定のツールが利用できない場合は、受信者は手動で悪用を報告する必要があります。つまり、スパムメッセージを添付ファイルとして転送し(ヘッダー全体を含めるように)、選択した機関に送信します。メールボックスプロバイダーは、インシデント通知を自動的に処理するツールを使用することもできます。[12]
参照
参考文献
- ^ フェリックス・シュヴァーゲライト;アンスガー・シェルプ。シュテフェン・スターブ(2011年6月14~17日)。 Web コミュニティにおけるユーザー生成コンテンツのガバナンスに関する調査(PDF)。ウェブサイエンス'11。ACM 。2012 年 1 月 4 日に取得。
- ^ 「ハッシュ共有システム」。wiki。Apache Foundation 。 2012年8月15日閲覧。
- ^ Jason Livingood、Nirmal Mody、 Mike O'Reirdan (2012 年 3 月)。ISP ネットワークにおけるボットの修復に関する推奨事項。IETF。doi : 10.17487 /RFC6561。RFC 6561。2012年8月15 日閲覧。
- ^ 「電子メールフィードバックループ:それが何であるか、なぜそれが重要であるか [2023]」。mailtrap.io 2023-03-01 。2023-04-18閲覧。
- ^ Murray Kucherawy編 (2012 年 6 月)。電子メール フィードバック レポートの作成と使用: 不正使用報告形式 (ARF) の適用性ステートメント。IETF。doi : 10.17487/RFC6650。RFC 6650。2012年6月 28 日取得。MUAは、フィードバック レポートを自分で生成するのではなく、不正使用レポートを作成してこれらのレポートをメールボックス プロバイダーに送り返し、エンド ユーザーに代わって ARFメッセージ
を生成して送信できるようにする必要があります ([RFC6449] のセクション 3.2 を参照)。これにより、レポートの集中処理と追跡が可能になり、フィルタリング システムにトレーニング入力が提供されます。
- ^ Theo Clarke (2005年10月10日). 「ネットワーク不正使用の連絡先を見つける」.ウィキメディア財団. 2011年4月22日閲覧。
- ^ John R. Levine (2009 年 12 月 9 日)。「MUA にスパム ボタンを追加する」。ASRGメーリング リスト(メーリング リスト) 。2011年4 月 22日閲覧。 そのメールスレッドの wiki サマリーも参照してください。
- ^ JD Falk 編 (2011 年 11 月)。苦情フィードバック ループの運用上の推奨事項。IETF。doi : 10.17487/RFC6449。RFC 6449。2011年11月18日閲覧。付録B.
DKIM を使用してフィードバックを
ルーティングする - ^ 「コミュニティ協議進行中 - WHOIS クエリ結果制限の削除」。ARIN。2007年 3 月 12 日。2009 年 9 月 28 日閲覧。ARIN
WHOIS クエリの 256 件の結果制限は、データ マイニングを抑制する手段として ARIN の設立当初から実施されています。
- ^ Leslie Nobile (2011 年 7 月 18 日)。「Abuse Contact To Be Mandatory per Policy 2010-14」。お知らせ。American Registry for Internet Numbers。2011年8 月 24 日閲覧。
- ^ Tobias Knecht (2010年11月8日). 「虐待連絡先情報」.アジア太平洋ネットワーク情報センター. 2011年4月22日閲覧。
- ^ 1つはAbusehelper
