虐待報告フォーマット

不正使用報告フォーマット( ARF )は、メッセージ不正使用報告フォーマット (MARF)とも呼ばれ、電子メール経由でスパムを報告するための標準フォーマットです。

歴史

フィードバックループ（FBL）レポートの標準フォーマットを記述した草案が、2005年4月にヤコフ・シャフラノビッチによって投稿され[ 1 ]、現在のRFC  5965へと発展しました。[ 2 ] 2003年にこの分野の先駆者であるAOLは、当初は別のフォーマットを使用していましたが、2008年にこの事実上の標準に移行しました。[ 3 ]フィードバックループはARFを使用する必要はありませんが、ほとんどのフィードバックループはARFを使用しています。

2010年1月、IETFはARFの標準化を目指して新たなワーキンググループを設立しました[ 4 ] 。このワーキンググループはMessaging Abuse Reporting Format WG（MARF）と呼ばれ、 RFC 5965を策定しました。2012年には、電子メール認証の失敗を報告するための失敗レポートを定義するために、 RFC 6591とRFC 6692によって拡張されました。 2015年には、後者のレポートタイプはRFC 7489によってさらに拡張され、 DMARCの失敗レポート が定義されました。    

目的

ARFは拡張性を考慮して設計されており、例えばユーザーからアンチスパムセンターやヘルプデスクへの一般的なスパム報告や、オプトアウト操作などに対応しています。このフォーマットでは、添付ファイルに含めるべき新しいMIMEmultipart/reportタイプを定義し、少なくとも問題となっているメッセージのヘッダー情報を含めます。ドラフト版の説明では、一部のオペレータがプライバシーや法的理由から該当部分を修正または編集する可能性があることが認められていますが、修正されていない受信者アドレスを含む元のメールメッセージ全体を添付することを 推奨しています。

ARFでカプセル化されたFBLレポートには、問題のあるメッセージと同じ件名が付けられます。バウンスメッセージと同様に、不正使用レポートは、人間が読める部分、機械が読める部分、そして元のメッセージで構成されます。機械が読める部分のタイプは であり、その定義が本草案の中核を成しています。レポートの特性を示すFeedback-Typemessage/feedback-reportフィールドを含めることで、拡張性が実現されています。このフィールドの可能な値は次のとおりです。

乱用
スパムやその他の種類の電子メールの不正使用。
詐欺
何らかの詐欺行為またはフィッシング行為を示唆する;
ウイルス
発信元メッセージにウイルスが見つかったという報告。
他の
他のタイプに当てはまらないその他のフィードバック。
スパムではない
誤ってスパムとしてマークされた電子メールメッセージを報告するために使用できます。[ 5 ]

Feedback-Typeおよびその他のフィールド名には、IANA レジストリが用意されています。[ 6 ]各フィールド名は、すべてのタイプのフィードバックに関連する場合もあれば、特定のタイプにのみ関連する場合もあります。一部のフィールドは複数回出現する場合があります。たとえば、元のメッセージを受信したIP アドレスを含むSource-IPフィールドは、すべてのタイプの FBL レポートに出現しますが、1 回だけです。削除する電子メール アドレスを示すRemoval-Recipientフィールドは、オプトアウトレポートにのみ出現しますが、1 回以上です。さらに、DKIM-Failureサブタイプがあり、独自の IANA レジストリがあります。

電子メールの不正使用に関する報告の例は次のとおりです。（機械可読部分の最初の 3 行のみが必要であることに注意してください。） 

送信者: <[email protected]>日付: 2005年3月8日(木) 17:40:36 EDT件名: FW:お金 を稼ぐ宛先: <[email protected]> MIMEバージョン: 1.0 コンテンツタイプ: multipart / report ; report-type = feedback-report ; boundary = "part1_13d.2e68ed54_boundary"--part1_13d.2e68ed54_boundaryコンテンツタイプ: text/plain; 文字セット="US-ASCII"コンテンツ転送エンコーディング: 7ビットこれは、2005年3月8日（木）14:00:00 EDTにIPアドレス192.0.2.2から受信したメールメッセージに関する不正使用報告です。このフォーマットの詳細については、http://www.mipassoc.org/arf/をご覧ください。--part1_13d.2e68ed54_boundaryコンテンツタイプ: メッセージ/フィードバックレポートFeedback-Type: abuse User-Agent: SomeGenerator/1.0 Version: 1 Original-Mail-From: <[email protected]> Original-Rcpt-To: <[email protected]> Received-Date: Thu, 8 Mar 2005 14:00:00 EDT Source-IP: 192.0.2.2 Authentication-Results: mail.example.com;  spf=fail [email protected] Reported-Domain: example.net Reported-Uri: http://example.net/earn_money.html Reported-Uri: mailto:[email protected] Removal-Recipient: [email protected]--part1_13d.2e68ed54_boundaryコンテンツタイプ: message/rfc822コンテンツ配置: inline送信者: <[email protected]>受信先: mailserver.example.net (mailserver.example.net  [192.0.2.2])、example.com、ESMTP id M63d4137594e46;  Thu, 8 Mar 2005 14:00:00 -0400宛先: <Undisclosed Recipients>件名: Earn money MIME-Version: 1.0 Content-type: text/plainメッセージ ID: [email protected]日付: Thu, 2 Sep 2004 12:31:03 -0500スパム スパム スパムスパム スパム スパムスパム スパムスパム スパム スパム--part1_13d.2e68ed54_boundary--

参照

参考文献

  1. ^ Yakov Shafranovich (2005年4月14日). 「New Abuse Draft」 . Shaftek.org. 2008年10月7日時点のオリジナルよりアーカイブ。2008年11月17日閲覧。
  2. ^ John Levine (2010年9月1日). 「ARFがIETF標準に」 . CircleID. 2010年9月5日時点のオリジナルよりアーカイブ。2010年9月12日閲覧。
  3. ^ Christine Borgia (2008年6月27日). 「AOL、2008年9月2日にすべてのFBLをARFに変換」 AOL. 2008年12月2日時点のオリジナルよりアーカイブ。 2008年11月17日閲覧。
  4. ^ IETF. 「MARF憲章」 . 2010年1月26日閲覧。
  5. ^ Kepeng Li; Barry Leiba (2011年11月). 「メールフィードバックレポートタイプの値: not-spam」 .提案標準. IETF . 2011年11月11日閲覧。
  6. ^ 「メッセージング不正報告フォーマット（MARF）パラメータ」 .プロトコルレジストリ. IANA . 2010年5月26日. 2011年11月29日閲覧。
「 https://en.wikipedia.org/w/index.php?title=Abuse_Reporting_Format&oldid=1322664214」より取得