フィードバックループ

フィードバックループ（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が、信頼のおける送信者と協定を結びフィードバックループを実施していれば、「迷惑メール報告ボタン」による報告を続けることによって、送信者に不要なメールを安全に申告できるようになる。 フィードバックループは迷惑メール対策の決め手となるわけではない事に注意が必要である。 たとえフィードバックの量が適切であっても、大部分のESPはそれを受け取るようになっていない。これは、送信者と受信者にとってフィードバックループの利用が任意であることが関係してくる。 また、迷惑メール報告と購読解除を一つのボタンとしてしまうと、それがどのような意図で押下されたのか推測する必要がある。例えば、メール送信者がフィードバックループに参加していなかったり、迷惑メール送信者だった場合は、迷惑メール報告を行ってもメール送信自体が和らぐことはない。 2005年、Yakov Shafranovichによりフィードバックループのための標準的なフォーマットが考案され、現在IETFでdraft format として取り扱われている。 AOLが使用していたフォーマットがその原型になっている。フィードバックループにARFを利用する必要はないが、米国では事実上の標準となっている。 ARFは一般的な不正利用報告に類するものであれば、さまざまな報告ができるよう拡張可能になっている。例えば、対策窓口ヘ迷惑メール報告を行うことや、メールのオプトアウト(購読解除、配信停止)にも利用できる。フォーマットとしては、multipart/reportを含んだMIMEパートと、報告をしたい対象のメールのヘッダ、本文で構成されている。 Draftではオリジナルのヘッダと本文、及び受信者アドレスは変更しないことを推奨しているが、プライバシーポリシー上の理由により一部を修正・変更しても問題ないとしている。 ARFに格納されたフィードバックループは、報告をしたい対象のメールと同じ題名(Subjectフィールド)がそのまま利用される。バウンスメール（エラーメール）のように複数のパートで構成されており、人間が読んで理解できるパート(human readable part)、プログラムが認識できるパート(machine readable part)、報告をしたい対象のオリジナルパートで構成されている。プログラムが認識できるパートタイプはmessage/feedback-reportとして定義され、Draftで詳細に定義されている。 ARFはさまざまなレポートができるように拡張可能になっており、これはFeedback-Typeフィールドで定義されている。 Feedback-Typeフィールド(現在のドラフト) 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-- 以下に挙げるのは主に米国のサービス事業者である。 Yahoo! (ReturnPath 経由) http://feedbackloop.yahoo.net/index.php (米国のみ;DomainKeysかDKIMに対応していることが必須) USA.NET (ReturnPath 経由) http://fbl.usa.net/ AOL http://www.postmaster.aol.com/fbl/index.html Hotmail https://support.msn.com/eform.aspx?productKey=edfsjmrpp&page=support_home_options_form_byemail&ct=eformts&scrx=1 UNITED ONLINE http://www.unitedonline.net/postmaster/whitelisted.html Comcast (ReturnPath 経由) http://feedback.comcast.net/ Roadrunner (ReturnPath 経由) http://feedback.postmaster.rr.com/ Bluetie (ReturnPath 経由) http://feedback.bluetie.com/ ^ Y. Shafranovich; J. Levine; P. Hoffman; M. Kucherawy (2008年6月16日). “An Extensible Format for Email Feedback Reports”. IETF. 17 November 2008閲覧。 Mutual Internet Practices Association の /arf セクション