フィードバックループ

フィードバックループ（FBL）はComplaint feedback loop とも呼ばれ、電子メールにおいて、ユーザから送信者への苦情をISPから送信者にフィードバックする仕組みである。ISPはウェブメールや電子メールクライアントに「迷惑メール報告ボタン」を設置したり、お客様窓口を通じて、ユーザの苦情を受け取ることができる。メールの送信者（主に電子メールサービスプロバイダ）がフィードバックを積極的に受け付けたい場合は、情報提供元となる各ISPとフィードバック先などについて協定を結んでおく。また、フィードバックを受ける専用の窓口を設けておき、ISPから直接送信されてくるのを待つこともできる。この場合、RFC 2142で定義される abuse@example.com のような不正利用申告用メールアドレスを準備しておくか、WHOISやそれに類するデータベースに受付窓口を設定しておくこともできる。

レポートの流れ編集

SpencerはAliceにメールを送信する。
Aliceは、そのメールの苦情を彼女の加入するISPであるIsaacに申告する。申告は「迷惑メール報告ボタン」を押下することなどで行う。
Isaacは申告されたメールをAbuse Reporting Formatや一般的なmessage/rfc822でMIMEパート化し、Spencerに送信する。（Spencerはフィードバックを受け取るよう事前に承諾している必要がある）

フィードバックループは基本的にユーザの申告によって行われるが、ウイルス検出プロセスなどのプログラムによってなされる場合もある。

利点編集

電子メールが様々な利用形態に及んでいることもあり、一概に言えない部分もあるが、フィードバックループの利点としては以下のようなものが挙げられる。

メール送信者、送信代行業者編集

メール送信者は、フィードバックループを利用することにより、メールの配信が不要と感じている宛先を送信リストから削除すること(listwashing)が可能になる。加えて、配信するメールがどれだけ不要とされているか、どれだけ市場に期待されているかについての情報を得ることができるようになる。メールの送信リストから適切な宛先を削除することは、長期的に見ればプラスになる。これは、ISPがメール送信者から配信されるメールを届けるべきかどうか判定する基準として、IPアドレスやドメインごとの苦情の割合が重要な測定基準となっているからである。メールが送信されるIPアドレスやドメインごとの苦情の割合がISPが要求する基準より低く保たれていれば、より確実にメールが配送先のメールボックスに届けられる。メールの送信代行業を行っているようなESPの場合は、苦情の割合がどの程度に達しているかを知ることによって、顧客がどのようなメールを送信しているのかを判断することも可能となる。

ISP 編集

不必要なメールを大量に受け取るようなISPでは、その対策として迷惑メールフィルタを導入してユーザに提供することがある。しかし、迷惑メールフィルタがユーザ期待通りに判定されるとは限らず、関係ないメールを迷惑メールと判定してしまう可能性がある。フィードバックループをメール送信者と連携して実施することによって、不要なメールが減少し、結果的に問題を軽減できることに繋がると考えられる。

メール受信者編集

自分の加入しているISPが、信頼のおける送信者と協定を結びフィードバックループを実施していれば、「迷惑メール報告ボタン」による報告を続けることによって、送信者に不要なメールを安全に申告できるようになる。

注意点編集

フィードバックループは迷惑メール対策の決め手となるわけではない事に注意が必要である。

たとえフィードバックの量が適切であっても、大部分のESPはそれを受け取るようになっていない。これは、送信者と受信者にとってフィードバックループの利用が任意であることが関係してくる。
また、迷惑メール報告と購読解除を一つのボタンとしてしまうと、それがどのような意図で押下されたのか推測する必要がある。例えば、メール送信者がフィードバックループに参加していなかったり、迷惑メール送信者だった場合は、迷惑メール報告を行ってもメール送信自体が和らぐことはない。

Abuse Feedback Reporting Format (ARF) 編集

2005年、Yakov Shafranovichによりフィードバックループのための標準的なフォーマットが考案され、現在IETFでdraft format として取り扱われている^[1]。 AOLが使用していたフォーマットがその原型になっている。フィードバックループにARFを利用する必要はないが、米国では事実上の標準となっている。

ARFは一般的な不正利用報告に類するものであれば、さまざまな報告ができるよう拡張可能になっている。例えば、対策窓口ヘ迷惑メール報告を行うことや、メールのオプトアウト(購読解除、配信停止)にも利用できる。フォーマットとしては、multipart/reportを含んだMIMEパートと、報告をしたい対象のメールのヘッダ、本文で構成されている。 Draftではオリジナルのヘッダと本文、及び受信者アドレスは変更しないことを推奨しているが、プライバシーポリシー上の理由により一部を修正・変更しても問題ないとしている。

ARFに格納されたフィードバックループは、報告をしたい対象のメールと同じ題名(Subjectフィールド)がそのまま利用される。バウンスメール（エラーメール）のように複数のパートで構成されており、人間が読んで理解できるパート(human readable part)、プログラムが認識できるパート(machine readable part)、報告をしたい対象のオリジナルパートで構成されている。プログラムが認識できるパートタイプはmessage/feedback-reportとして定義され、Draftで詳細に定義されている。 ARFはさまざまなレポートができるように拡張可能になっており、これはFeedback-Typeフィールドで定義されている。

Feedback-Typeフィールド(現在のドラフト)

abuse	迷惑メールなど、電子メールの不正利用を報告する
dkim	送信ドメイン認証であるDKIMの認証失敗を報告する
fraud	なりすましやフィッシング詐欺のメールを報告する
miscategorized	レピュテーションシステムなどを用いたコンテンツフィルタが誤判定した場合に報告する
not-spam	「迷惑メールでない」として報告する
opt-out	メールの送信者にオプトアウト（購読解除、配信停止）を求める
virus	元のメールにウイルスが発見された場合に報告する
other	上記以外の報告を行う

Feedback-Typeフィールド以外にもいくつかのフィールドが利用できる。これらには、特定のFeedback-Typeに作用するようなものもある。また、フィールドによってはSource-IPフィールドのように1つだけ利用されるものもあれば、Removal-Recipientフィールドのように複数回登場するものもある。さらに、DKIM-Failureサブタイプのようなものもある。

ARFのサンプルを次に示す。プログラムが認識できるパートの最初の3行が必須となる。

  From: <abusedesk@example.com>
  Date: Thu, 8 Mar 2005 17:40:36 EDT
  Subject: FW: Earn money
  To: <abuse@example.net>
  MIME-Version: 1.0
  Content-Type: multipart/report; report-type=feedback-report;
       boundary="part1_13d.2e68ed54_boundary"
   
  --part1_13d.2e68ed54_boundary
  Content-Type: text/plain; charset="US-ASCII"
  Content-Transfer-Encoding: 7bit
   
  This is an email abuse report for an email message received from IP
  10.67.41.167 on Thu, 8 Mar 2005 14:00:00 EDT. For more information
  about this format please see http://www.mipassoc.org/arf/.
   
  --part1_13d.2e68ed54_boundary
  Content-Type: message/feedback-report
   
  Feedback-Type: abuse
  User-Agent: SomeGenerator/1.0
  Version: 0.1
  Original-Mail-From: <somespammer@example.net>
  Original-Rcpt-To: <user@example.com>
  Received-Date: Thu, 8 Mar 2005 14:00:00 EDT
  Source-IP: 10.67.41.167
  Authentication-Results: mail.example.com
                 smtp.mail=somespammer@example.com;
                 spf=fail
  Reported-Domain: example.net
  Reported-Uri: http://example.net/earn_money.html
  Reported-Uri: mailto:user@example.com
  Removal-Recipient: user@example.com
   
  --part1_13d.2e68ed54_boundary
  Content-Type: message/rfc822
  Content-Disposition: inline
   
  From: <somespammer@example.net>
  Received: from mailserver.example.net (mailserver.example.net
       [10.67.41.167]) by example.com with ESMTP id M63d4137594e46;
       Thu, 08 Mar 2005 14:00:00 -0400
  To: <Undisclosed Recipients>
  Subject: Earn money
  MIME-Version: 1.0
  Content-type: text/plain
  Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net
  Date: Thu, 02 Sep 2004 12:31:03 -0500
   
  Spam Spam Spam
  Spam Spam Spam
  Spam Spam Spam
  Spam Spam Spam
  --part1_13d.2e68ed54_boundary--