|
この項目では、電子メールでの仕組みについて説明しています。
- 楽曲については「ハスキング・ビー#アルバム」をご覧ください。
|
フィードバックループ（FBL）はComplaint feedback loop とも呼ばれ、電子メールにおいて、ユーザから送信者への苦情をISPから送信者にフィードバックする仕組みである。ISPはウェブメールや電子メールクライアントに「迷惑メール報告ボタン」を設置したり、お客様窓口を通じて、ユーザの苦情を受け取ることができる。 メールの送信者（主に電子メールサービスプロバイダ）がフィードバックを積極的に受け付けたい場合は、情報提供元となる各ISPとフィードバック先などについて協定を結んでおく。また、フィードバックを受ける専用の窓口を設けておき、ISPから直接送信されてくるのを待つこともできる。この場合、RFC 2142で定義される abuse@example.com のような不正利用申告用メールアドレスを準備しておくか、WHOISやそれに類するデータベースに受付窓口を設定しておくこともできる。
|
目次
- 1 レポートの流れ
- 2 利点
- 2.1 メール送信者、送信代行業者
- 2.2 ISP
- 2.3 メール受信者
- 3 注意点
- 4 Abuse Feedback Reporting Format (ARF)
- 5 Feedback Loopを活用しているESP一覧
- 6 脚注
- 7 外部リンク
|
レポートの流れ [編集]
- 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--
Feedback Loopを活用しているESP一覧 [編集]
以下に挙げるのは主に米国のサービス事業者である。
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. 2008年11月17日閲覧。
外部リンク [編集]
- Mutual Internet Practices Association の /arf セクション
