Internet Engineering Task Force (IETF) J. Falk, Ed.
Request for Comments: 6449 Messaging Anti-Abuse WG
Category: Informational November 2011
ISSN: 2070-1721
Complaint Feedback Loop Operational Recommendations
Abstract
抽象
Complaint Feedback Loops similar to those described herein have existed for more than a decade, resulting in many de facto standards and best practices. This document is an attempt to codify, and thus clarify, the ways that both providers and consumers of these feedback mechanisms intend to use the feedback, describing some already common industry practices.
苦情フィードバックは、本明細書に記載されているものと同様に、多くのデファクトスタンダードとベストプラクティスで、その結果、10年以上にわたって存在しているループします。この文書では、体系化、ひいては明確化しようとすると、これらのフィードバック機構の両方のプロバイダと消費者は、いくつかすでに一般的な業界の慣行を記述し、フィードバックを使用する方法です。
This document is the result of cooperative efforts within the Messaging Anti-Abuse Working Group, a trade organization separate from the IETF. The original MAAWG document upon which this document is based was published in April, 2010. This document does not represent the consensus of the IETF; rather it is being published as an Informational RFC to make it widely available to the Internet community and simplify reference to this material from IETF work.
この文書では、メッセージングアンチ虐待ワーキンググループ、IETFとは別の業界団体内での協力の努力の結果です。このドキュメントは4月に発表されたベースとなるオリジナルMAAWG文書は、2010このドキュメントは、IETFのコンセンサスを表すものではありません。むしろインターネットコミュニティにそれが広く利用できるようにし、IETFの作業から、この材料への参照を簡素化するための情報RFCとして公開されています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6449.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6449で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English.
RFCとして公表のためにそれをフォーマットしたり、英語以外の言語に翻訳することを除いて、このドキュメントは変更されないことがあり、それの派生作品が作成されないことがあります。
Table of Contents
目次
1. Overview ........................................................4
2. Glossary of Standard Terms ......................................5
3. Mailbox Providers and Feedback Providers ........................9
3.1. Benefits of Providing Feedback .............................9
3.2. Collecting Complaints .....................................10
3.3. Creating Reports ..........................................11
3.4. Policy Concerns ...........................................11
3.4.1. Privacy and Regulatory Compliance ..................11
3.4.2. Terms of Use .......................................12
3.5. Handling Requests to Receive Feedback .....................12
3.5.1. Application Web Site ...............................13
3.5.2. Saying No ..........................................14
3.5.3. Automation .........................................14
3.6. Ongoing Maintenance .......................................15
3.6.1. IP Validation ......................................15
3.6.2. Email Address Validation ...........................16
3.6.3. Feedback Production Changes ........................16
4. Feedback Consumers .............................................16
4.1. Preparation ...............................................17
4.2. What You'll Receive .......................................18
4.2.1. Feedback Reports ...................................18
4.2.2. Administrative Messages ............................18
4.2.3. Report Cards .......................................18
4.3. Handling Feedback Messages ................................19
4.3.1. Unsubscription or Suppression ......................20
4.3.2. Trending and Reporting .............................21
4.4. Automatically Handling an Incoming Feedback Stream ........22
5. Conclusion .....................................................25
6. Acknowledgments ................................................26
6.1. About MAAWG ...............................................26
7. Security Considerations ........................................26
8. Informative References .........................................26
Appendix A. Abuse Reporting Format (ARF) ..........................28
A.1. A Brief History ............................................28
A.2. Structure of an ARF Message ................................28
Appendix B. Using DKIM to Route Feedback ..........................29
Appendix C. Unsolicited Feedback ..................................30
C.1. Guidelines .................................................30
C.2. Pros .......................................................30
C.3. Cons .......................................................31
The intent of a Complaint Feedback Loop is to provide Feedback Consumers with information necessary to mitigate Spam or the perception of Spam. Thus, feedback was originally only offered to mailbox, access, and network providers -- in other words, to ISPs -- who would use the feedback to identify network compromises and fraudulent accounts or to notify their downstream customer that there may be a problem.
苦情フィードバックループの意図は、スパムやスパムの認識を軽減するために必要な情報をフィードバック消費者に提供することです。ネットワークの妥協や不正アカウントを特定したり、問題があるかもしれないことを彼らの下流の顧客に通知するためにフィードバックを使用する - つまり、ISPに - したがって、フィードバックはもともとのみ、メールボックス、アクセス、およびネットワーク・プロバイダーに提供されていました。
Senders of bulk, transactional, social, or other types of email can also use this feedback to adjust their mailing practices, using Spam Complaints as an indicator of whether the Recipient wishes to continue receiving email. Common reactions often include refining opt-in practices, mailing frequency, list management, message content, and other measures. Over time, this has become the Feedback Consumer use case most often discussed at MAAWG meetings and other industry events -- but readers are cautioned that it is not the sole use for feedback.
バルク、トランザクション、社会的、または電子メールの他のタイプの送信者も受信者が電子メールを受信し続けることを望むかどうかの指標としてスパム苦情を使用して、彼らの郵送慣行を調整するために、このフィードバックを使用することができます。一般的な反応は、多くの場合、精錬オプトインプラクティス、郵送周波数、リスト管理、メッセージの内容、およびその他の措置が含まれます。時間が経つにつれて、これはほとんどの場合、MAAWG会議や他の業界イベントで議論フィードバックコンシューマーユースケースとなっている - しかし、読者はそれがフィードバックのための唯一の使用ではないと警告しています。
[ Feedback Consumer Database ]
|
V
[ User ] [ Mailbox ] [ Feedback ]
[ Reports ]--->[ Provider ]--SMTP-->[ Provider ]
[ Spam ] | |
V V [ Feedback ]
[Spam Filter Rules] [ ARF Message ]--SMTP-->[ Consumer ]
Figure 1
図1
When an End User of a Mailbox Provider issues a Spam Complaint, the Feedback Provider sends a report to the Feedback Consumer. This report may include the Full Body of the original email or (less commonly) only the full header of the original email. Some Feedback Providers will redact information deemed private, such as the Message Recipient's Email Address.
メールボックスプロバイダのエンドユーザーはスパム苦情を発行すると、フィードバックプロバイダは、フィードバック消費者にレポートを送信します。このレポートでは、元の電子メールの唯一のフルヘッダー元の電子メールまたは（あまり一般的ではない）のフルボディを含むことができます。いくつかのフィードバック・プロバイダは、このようなメッセージ受信者の電子メールアドレスなどの個人とみなされる情報を、墨消します。
Ensuring that Feedback Messages are only sent to authorized Feedback Consumers is the responsibility of the Feedback Provider, with the identity of each message Sender generally determined from the SMTP session's connecting IP address or a message's DomainKeys Identified Mail (DKIM) signature domain, both of which are hard to forge. This is important because Spammers and other miscreants may also attempt to apply for Feedback Loops on networks not belonging to them, in an attempt to steal Email Addresses and other private personal or corporate information.
一般的にSMTPセッションの接続IPアドレスまたはメッセージのドメインキー・アイデンティファイド・メール（DKIM）署名ドメインから決定された各メッセージ送信者の同一性を有するフィードバック・プロバイダの責任は、メッセージのみ許可フィードバック消費者に送信されるフィードバックさ確実どちらの偽造が困難です。スパマーやその他の悪党にもフィードバックネットワークは、メールアドレスや他の民間の個人や企業の情報を盗むための試みで、それらに属さないでループに対して適用しようとするので、これは重要です。
It is the responsibility of the Feedback Consumer to identify the source and nature of the original message in the reports they receive and take any appropriate action. The Feedback Provider does not make any claims or judgments about the validity of the complaint, beyond whatever technical data the Feedback Provider has themselves included. Every complaint is forwarded to the Feedback Consumer without human review, without any additional application of filters; thus, some individual reports may prove not to be actionable.
それは彼らが受け取るレポートに元のメッセージの送信元と性質を特定し、任意の適切な行動を取るようにフィードバック消費者の責任です。フィードバックプロバイダは、フィードバックプロバイダ自体は含まれています技術的なものは何でもデータを超える苦情の妥当性に関するいかなる主張または判断を下すことはありません。すべての苦情は、フィルタの追加のアプリケーションなしに、人間の審査なしにフィードバック消費者に転送されます。このように、いくつかの個々のレポートは実用的ではないと証明することがあります。
The Feedback Consumer and the Feedback Provider will each evaluate a Spam Complaint for validity and take whatever action deemed necessary from their own perspective and, in most cases, will not communicate with each other which actions were (or were not) taken. Similarly, it is rare for any party to communicate further with the End User who initiated the complaint.
フィードバック消費者とフィードバックプロバイダは、それぞれの有効性のためのスパムの苦情を評価し、独自の観点から必要と認められると、ほとんどの場合、撮影したアクションがあった（またはありませんでした）が相互に通信しませんどんな行動がかかります。いずれかの当事者が苦情を開始したエンドユーザーとの更なる通信するために同様に、それは稀です。
Wherever possible, these terms are derived from [RFC5598].
可能な限り、これらの用語は、[RFC5598]に由来します。
o Abuse Reporting Format - The standard format for Feedback Messages, defined in Appendix A and [MARF].
【MARF]付録Aで定義されたフィードバック・メッセージのための標準フォーマットと - O形式レポート乱用。
o Access Provider - Any company or organization that provides End Users with access to the Internet. It may or may not be the same entity that the End User uses as a Mailbox Provider.
Oアクセスプロバイダ - インターネットへのアクセスをエンドユーザーに提供する任意の会社または組織。これは、またはエンドユーザーがメールボックスプロバイダとして使用するのと同じエンティティであってもなくてもよいです。
o Application for Feedback Loop - the process, manual or online, by which a prospective Feedback Consumer requests to receive a Feedback Loop from a particular Feedback Provider.
フィードバックループのためのOアプリケーション - プロセス、マニュアルまたはオンライン、将来のフィードバック消費者の要求は、特定のフィードバックプロバイダからのフィードバックループを受け取るためにそれによって。
o ARF -- See "Abuse Reporting Format".
ARF○ - 「不正行為の報告書式」を参照してください。
o ARF Report -- See "Feedback Message".
ARFレポートO - 「フィードバックメッセージ」を参照してください。
o Body - See "Full Body".
Oボディ - 「フルボディ」を参照してください。
o Complaint or Complaint Message - See "Feedback Message".
O苦情や苦情メッセージ - 「フィードバックメッセージ」を参照してください。
o Complaint Feedback Loop - See Overview and Taxonomy section.
O苦情フィードバックループは - 概要と分類を参照してください。
o Complaint Stream - See "Feedback Stream".
O苦情ストリーム - 「フィードバックストリーム」を参照してください。
o Delivery - See "Message Delivery".
O配信 - 「メッセージ配信」を参照してください。
o DKIM - DomainKeys Identified Mail, further described in the MAAWG email authentication white paper "Trust in Email Begins with Authentication" [Trust] and [DKIM].
O DKIM - DomainKeysの更なるMAAWGの電子メール認証のホワイトペーパーで説明した認証メール、[DKIM] [トラスト]および「電子メールでの信頼は認証で始まります」。
o End User - A customer of a Mailbox Provider or Access Provider.
Oエンドユーザー - メールボックスプロバイダまたはアクセスプロバイダの顧客。
o Envelope Sender - The Email Address included as the argument to the [SMTP] "MAIL" command during transfer of a message.
Oエンベロープ送信者は、 - 電子メールアドレスは、メッセージの転送中に[SMTP]「MAIL」コマンドの引数として含まれています。
o Email Address - A string of the form user@domain, where the domain (after the @ symbol) is used to determine where to transfer an email message so that it may be delivered to the mailbox specified by the username (before the @ symbol). The precise technical format of an Email Address is defined in [SMTP]. Email delivery can be a complex process and is not described further in this document.
Oメールアドレス - ドメイン（@記号の後には）ここで、それは、@記号の前に（ユーザ名で指定したメールボックスに配信することができるように、電子メールメッセージを転送するかを決定するために使用されたuser @ domain形式の文字列、 ）。メールアドレスの正確な技術的なフォーマットは、[SMTP]で定義されています。メール配信は、複雑なプロセスになる可能性があり、この文書でさらに説明されていません。
o Email Service Provider (ESP) - A provider of email sending services; the ESP is often a Message Originator working on behalf of a Message Author. MAAWG uses the term "ESP" solely for this definition and does not refer to a Mailbox Provider for End Users as ESPs.
Oメールサービスプロバイダ（ESP） - 電子メール送信サービスのプロバイダー。 ESPは、多くの場合、メッセージの著者に代わって作業メッセージの発信です。 MAAWGはもっぱらこの定義のための用語「ESP」を使用し、ESPのようにエンドユーザーのためのメールボックスプロバイダを参照していません。
o FBL - The acronym "FBL" (Feedback Loop) is intentionally not used in this document.
O FBL - 頭字語「FBL」（フィードバックループ）が意図的にこのドキュメントで使用されていません。
o Feedback or Feedback Stream - A set (often a continuous stream) of Feedback Messages sent from a single Feedback Provider to a single Feedback Consumer.
Oフィードバックまたはフィードバックストリーム - 単一フィードバック消費者に単一のフィードバックプロバイダから送られたフィードバックメッセージのセット（多くの場合、連続ストリーム）。
o Feedback Consumer - A Recipient of the Feedback Messages, almost always on behalf of or otherwise associated with the Message Originator. Often the Message Originator and Feedback Consumer are the same entity, but we describe them separately in this document because they are each responsible for different parts of the Complaint Feedback Loop process, as demonstrated in the flowchart in the Overview section.
Oフィードバック消費者 - それ以外の場合は、メッセージ発信と関連するのか、代わってほとんど常にフィードバックメッセージの受信者、。多くの場合、メッセージ発信やフィードバック消費者は同じエンティティですが、彼らはそれぞれの苦情フィードバックループプロセスの異なる部分を担当しているので、我々は、概要セクションのフローチャートで示したように、このドキュメントでそれらを別々に説明します。
o Feedback Loop - See Complaint Feedback Loop.
Oフィードバックループ - 苦情フィードバックループを参照してください。
o Feedback Message - A single message, often using the Abuse Reporting Format defined above and outlined in Appendix 1, which is part of a Feedback Stream.
Oフィードバックメッセージ - 単一のメッセージ、しばしばフィードバックストリームの一部である書式上に定義され、付録1に概説し、レポート乱用を使用。
o Feedback Provider - The Sender of the Feedback Messages, almost always on behalf of or associated with the Mailbox Provider. Often the Mailbox Provider and Feedback Provider are the same entity, but we describe them separately in this document because they are each responsible for different parts of the Complaint Feedback Loop process. In some instances, the Feedback Provider may be operating solely on behalf of the Message Recipient, without any direct participation from their Mailbox Provider.
Oフィードバックプロバイダ - フィードバックメッセージの送信者、ほとんどいつもの代わりにまたはメールボックスプロバイダに関連付けられています。多くの場合、メールボックスのプロバイダとフィードバックプロバイダは同じエンティティですが、彼らはそれぞれの苦情フィードバックループプロセスの異なる部分を担当しているので、我々は、この文書でそれらを別々に説明します。いくつかの例では、フィードバックプロバイダは、自分のメールボックスプロバイダから任意の直接参加せず、単にメッセージ受信者に代わって操作することができます。
o Full Body - An email message (the "DATA" portion of the [SMTP] conversation) consists of two parts: the header and the body. The "Full Body" is simply the entirety of the body of the message, without modification or truncation. Note that images or other so-called "attachments" are actually part of the body, designated in accordance with the [MIME] standard.
ヘッダとボディ - Oフルボディ電子メールメッセージ（[SMTP]会話の「DATA」部分）は、二つの部分からなります。 「フルボディは、」変更または切り捨てずに、単にメッセージのボディの全体です。画像又は他のいわゆる「添付ファイル」[MIME]規格に従って指定され、実際に身体の一部であることに留意されたいです。
o Full Header Section - An email message (the "DATA" portion of the [SMTP] conversation) consists of two parts: the header and the body. The header contains multiple header fields, each formatted as "Header-Name: header contents". Although most Mail User Agents (MUAs) only show the basic four header fields (From, To, Date, and Subject), every message includes additional header fields that primarily contain diagnostic information or data intended to assist automatic processing. Often informally called "Full Headers". These fields are fully defined in [RFC5322]
ヘッダとボディ - Oフルヘッダーセクション電子メールメッセージ（[SMTP]会話の「DATA」部分）は、二つの部分からなります。ヘッダは、複数のヘッダフィールド、「ヘッダーの内容ヘッダ名」としてフォーマットそれぞれを含んでいます。ほとんどのメールユーザエージェント（MUA）は基本的な4つのヘッダーフィールド（TO、日付、および対象由来）を示しているが、すべてのメッセージは、主に自動処理を支援することを意図した診断情報又はデータを含む付加的なヘッダフィールドを含みます。多くの場合、非公式に「フルヘッダー」と呼ばれます。これらのフィールドは、完全に[RFC5322]で定義されています
o Header - See "Full Header Section" above.
Oヘッダ - 上記の「フルヘッダーセクション」を参照してください。
o ISP - Internet Service Provider, usually referred to as either an Access Provider or a Mailbox Provider in this paper.
O ISP - インターネットサービスプロバイダは、通常、アクセスプロバイダまたは本論文では、メールボックスのプロバイダのいずれかと呼ばれます。
o Mail Abuse Reporting Format (MARF) - See "Abuse Reporting Format" above.
Oフォーマット（MARFを）報告メール乱用は - 上記の「不正行為の報告書式」を参照してください。
o Mailbox Provider - A company or organization that provides email mailbox hosting services for End Users and/or organizations. Many Mailbox Providers are also Access Providers.
Oのメールボックスプロバイダ - エンドユーザおよび/または組織のために、電子メールのメールボックスのホスティングサービスを提供する企業や組織。多くのメールボックスプロバイダは、アクセスプロバイダです。
o Mailing List - A set of Email Addresses that will receive specific messages in accordance with the policies of that particular list.
Oメーリングリスト - その特定のリストの方針に従って、特定のメッセージを受信する電子メールアドレスのセット。
o Message-ID Header Field - One of the diagnostic header fields included in every email message (see "Full Header Section" above) is the Message-ID. Theoretically, it is a unique identifier for that individual message.
Oメッセージ-IDヘッダフィールド - 診断ヘッダフィールドの一つは、すべての電子メールメッセージ（上記の「フル・ヘッダセクション」を参照）に含まれるメッセージIDです。理論的には、その個々のメッセージの一意の識別子です。
o Message Delivery - The process of transferring a message from one mail transfer agent (MTA) to another. Once the message has been accepted by the MTA operating on behalf of the Recipient, it is considered to be "delivered" regardless of further processing or filtering that may take place after that point.
Oメッセージ配信 - 別のメール転送エージェント（MTA）からメッセージを転送するプロセス。メッセージは受信者に代わって操作するMTAによって受け入れられていると、関係なく、その時点後に行うことができる、さらに処理やフィルタの「配信」していると考えられます。
o Message Originator - The Sender, but not necessarily the author or creator, of a message.
Oメッセージの発信 - 送信者が、必ずしもそうではないメッセージの作成者や作成者、。
o Message Recipient - The person or mailbox that receives a message as final point of delivery.
Oメッセージ受信者 - 配達の最終点としてメッセージを受信者またはメールボックス。
o MIME - Multipurpose Internet Mail Extensions refers to a set of standards permitting non-plaintext data to be embedded in the body of a message. Concepts such as file attachments and formatted or "rich" text are all accomplished solely through [MIME].
MIME○ - 多目的インターネットメール拡張機能は、メッセージの本体に埋め込まれるように、非平文データを許可基準のセットを指します。そのようなファイルの添付ファイルやフォーマットされたまたは「リッチ」テキストなどの概念は、すべてのみ[MIME]を通じて達成されています。
o MUA - Mail User Agent; loosely referring to the software used by an End User to access, interact with, or send email messages.
O MUA - メールユーザエージェント。緩く、アクセスと対話する、または電子メールメッセージを送信するためにエンドユーザーが使用するソフトウェアを指します。
o Provider - See "Feedback Provider" above.
Oプロバイダ - 上記の「フィードバックプロバイダ」を参照してください。
o Received Header Field - Diagnostic header fields included in an email message (see "Full Header Section" above) that start with "Received:" and document (from bottom to top) the path a message traversed from the originator to its current position.
メッセージは、その現在の位置に発信から横断パスをし、（底部から上部へ）ドキュメント：「受信」診断ヘッダフィールドは、電子メールメッセージに含まれる（上記「フルヘッダーセクション」を参照）で始まる - Oヘッダーフィールドを受信しました。
o Recipient - See "Message Recipient" above.
O受信者 - 上記の「メッセージ受信者」を参照してください。
o Return-Path - An optional message header field (see "Full Header Section" above) that indicates the Envelope Sender of the message.
Oリターンパス - オプションのメッセージヘッダフィールドは、メッセージのエンベロープ送信者を示している（上記の「フル・ヘッダセクション」を参照します）。
o Reverse DNS - The [DNS] name of an IP address, called "reverse" because it is the inverse of the more user-visible query that returns the IP address of a DNS name. Further, a Reverse DNS query returns a PTR record rather than an A record.
IPアドレスの[DNS]名前、それはDNS名のIPアドレスを返し、よりユーザに見えるクエリの逆数であるため、「逆」と呼ばれる - O DNSリバース。さらに、リバースDNSクエリがPTRレコードではなくAレコードを返します。
o Sender - see "Message Originator" above.
O送信者 - 上記の「メッセージの発信」を参照してください。
o SMTP - Simple Mail Transfer Protocol, the mechanism and language for transferring an email message from one place to another as defined in RFC 5321 [SMTP].
O SMTP - RFC 5321で定義されるように別の場所から電子メールメッセージを転送するための簡易メール転送プロトコル、機構及び言語[SMTP]。
o Spam - For the purposes of this document (and for most Complaint Feedback Loops), "spam" is defined as any message that the Recipient chooses to complain about, regardless of the intent of the message's author or Sender.
Oスパム - このドキュメントの目的のためには、（ほとんどの苦情フィードバックループ用）、「迷惑メール」を受信者に関係なく、メッセージの作成者または送信者の意図を、文句を言うことを選択した任意のメッセージとして定義されます。
o Spam Complaint - See "Complaint" above.
Oスパム苦情 - 上記の「苦情」を参照してください。
o Spammer - An entity that knowingly, intentionally sends Spam messages (see "Spam" above).
Oスパマー - 故意に、意図的にスパムメッセージを送信したエンティティは、（上記の「迷惑メール」を参照してください）。
o Terms of Use - A legal document describing how a particular system or service is to be used.
使用のO規約 - 特定のシステムまたはサービスを使用する方法を説明する法的文書。
o VERP - Variable Envelope Return Path [VERP], an informally standardized method for encoding information about the Message Recipient into the return path while delivering a message in order to ensure that any non-delivery notices are processed correctly.
O VERP - 可変エンベロープリターンパス[VERP]、任意の非配信通知が正しく処理されることを保証するためにメッセージを配信しながら、リターンパスにメッセージの受信者に関する情報を符号化するための非公式の標準化方法。
In practice, a Mailbox Provider receives complaints from their End Users, and is often also the Feedback Provider for those complaints and is a consumer of feedback from other providers. In this document, we separate the Mailbox Provider and Feedback Provider functions to reduce possible confusion over those cases where they are separate, and we also urge Mailbox Providers to read the "Feedback Consumer" section later in this document.
実際には、メールボックスのプロバイダは、エンドユーザーからの苦情を受け、また、多くの場合、これらの苦情のためのフィードバックプロバイダであり、他のプロバイダからのフィードバックの消費者です。この文書では、我々は、彼らが別々であるような場合の上に混同の可能性を減らすために、メールボックスプロバイダとフィードバックプロバイダの機能を分離し、我々はまた、このドキュメントの後半では「フィードバック消費者」セクションを読み取るために、メールボックスプロバイダを促します。
The decision to provide a Complaint Feedback Loop service should not be taken lightly. The benefits of a Feedback Loop are great, but success depends on a sound plan, organized implementation, and dedication to upkeep.
苦情フィードバックループのサービスを提供するという決定は、軽く取られるべきではありません。フィードバックループのメリットは大きいですが、成功は音計画、組織化、実装、および維持管理への献身に依存します。
What are some benefits of providing feedback to fellow Mailbox Providers and Access Providers? Primarily, other industry actors are quickly alerted to Spam outbreaks on their networks.
仲間のメールボックスプロバイダとアクセスプロバイダにフィードバックを提供するいくつかの利点は何ですか？主に、他の業界の関係者はすぐに彼らのネットワーク上のスパムの発生が通知されます。
End Users are becoming more aware of and comfortable with mechanisms to report Spam, and a Feedback Loop does just what it implies; it closes the loop. The End User's complaint makes its way back to the Message Originator (not necessarily the message Sender, who may be a Spammer), allowing the originator to take appropriate action. In this process, the mail system operator is just a messenger, relieved of the responsibility of reviewing and forwarding complaints manually.
エンドユーザーは、より多くの意識やスパムを報告するためのメカニズムを快適になっている、とフィードバックループは、それが意味するだけで何ありません。それは、ループを閉じます。エンドユーザーの不満は、発信者が適切な行動を取ることができ、バックメッセージの発信（スパマーかもしれない必ずしもメッセージ送信者）への道を作ります。このプロセスでは、メールシステムのオペレータは、ちょうど見直し、手動で苦情を転送する責任から解放メッセンジャー、です。
Further, because every complaint is sent immediately -- without any review or analysis by the Feedback Provider -- the complaint is received by the Feedback Consumer in near real time. If the Feedback Consumer is paying attention to their Feedback Stream and taking appropriate action on it, the receiving Mailbox Provider receives less Spam, blocks less legitimate mail, and does not have to assign staff to follow up with the originating network. If the Mailbox Provider does not pay attention to its Feedback Stream, and does not take appropriate action, the Feedback Provider may block or otherwise filter the email from that Message Originator, considering the Feedback Messages to be sufficient notice.
さらに、すべての苦情がすぐに送信されるため - フィードバックプロバイダによって、任意のレビューや分析なし - 苦情はほぼリアルタイムでフィードバック消費者によって受信されます。フィードバック消費者が彼らのフィードバックストリームに着目し、その上に適切な行動を取っている場合は、受信メールボックスプロバイダはあまり正当なメールより少ないスパム、ブロックを受信し、発信ネットワークをフォローアップするためにスタッフを割り当てる必要はありません。メールボックスのプロバイダは、そのフィードバックストリームに注意を払っていないし、適切な措置を講じていない場合は、フィードバックプロバイダは、フィードバックメッセージは十分注意事項であることを考慮すると、そのメッセージの発信からのメールをブロックするか、そうでない場合はフィルタリングすることができます。
What are some benefits of providing Feedback Loops to bulk Feedback Consumers? As Message Recipients become more aware of and comfortable with Spam reporting mechanisms, they often prefer this method over the often-confusing and inconsistent "unsubscribe" or "opt-out" mechanisms provided by most legitimate Message Originators or Senders.
フィードバックを提供するいくつかの利点は何バルクフィードバック消費者にループ？メッセージ受信者は、より多くの意識とスパムのメカニズムを報告して快適になると、彼らはしばしば、多くの場合、混乱と矛盾する「配信停止」または、ほとんどの正当なメッセージのオリジネーターまたは送信者が提供する「オプトアウト」のメカニズムを介して、この方法を好みます。
End Users often do not remember what lists they signed up for or are otherwise not confident in the established relationship they may have with a message Sender. As such, they often choose to report messages as Spam to their Mailbox Providers, considering that to be sufficient notification of their desire not to receive such email in the future.
エンドユーザーは、多くの場合、彼らがサインアップしたか、そうでない場合は、メッセージの送信者を持っているかもしれ確立された関係に自信を持っていない示していますどのような覚えていません。そのため、彼らはしばしば、それが将来的に、このような電子メールを受信しないように自分の欲望を十分に通知することを考慮して、自分のメールボックスプロバイダにスパムとしてメッセージを報告することを選択しました。
If the Message Originator is paying attention to and taking appropriate action on their Feedback Stream, it will have a happier set of Message Recipients and should receive fewer Spam Complaints (assuming their opt-in processes are sound). If the Message Originator is not paying attention to Feedback and not taking appropriate action, the Mailbox Provider may consider the Feedback Stream sufficient notice that messages from that originator may no longer be accepted in the future.
メッセージの発信がに注意を払って、そのフィードバックストリームに適切な行動を取っている場合は、メッセージ受信者の幸せなセットを持っていますし、（そのオプトインのプロセスが健全であると仮定して）少ないスパム苦情を受けるべきです。メッセージの発信がフィードバックに注意を払っていないし、適切な行動を取っていない場合は、メールボックスのプロバイダは、その発信元からのメッセージは、もはや将来的に受け入れられることをフィードバックストリーム十分な注意事項を考慮することができます。
To produce Feedback Messages and to ensure they are useful, the Feedback Provider needs to obtain near real-time complaints from the Mailbox Provider's users. This is typically done by integrating the feedback mechanism with the collection of Spam reports from its users.
フィードバックメッセージを生成するために、彼らが有用であることを確認するために、フィードバックプロバイダは、メールボックスのプロバイダのユーザーからリアルタイムに近い苦情を取得する必要があります。これは通常、そのユーザーからのスパム報告の収集とフィードバック機構を統合することによって行われます。
These reports are typically made using the "Report Spam" buttons integrated into Webmail interfaces, or a proprietary desktop client provided to users. Mailbox Providers may also look at deploying a toolbar or MUA plug-in that provides a "Report Spam" button in the MUA interface.
これらのレポートは、一般的にユーザに提供するWebメールインターフェースに統合「迷惑メールを報告」ボタン、または独自のデスクトップクライアントを使用して作られています。メールボックスのプロバイダは、ツールバーやMUAを展開を見てもよいプラグインで、MUAインターフェイスに「迷惑メールを報告」ボタンを提供します。
Usability studies with average users should be performed on all interface changes before implementation. A "help" interface should also be available to educate users about how the Spam button should be used and what it does.
平均的なユーザーとのユーザビリティ調査は、実装前に、すべてのインターフェイスの変更で実行する必要があります。 「ヘルプ」インターフェースもどのように迷惑メールボタンを使用する必要があり、何それがない程度のユーザーを教育するために利用可能でなければなりません。
If the Mailbox Provider does not offer its customers a mail client with this button, then the Feedback Provider's chances for providing an effective Feedback Loop are slim. While it is possible for the Mailbox Provider to instruct its customers to forward unwanted mail to a central location and for the Mailbox Provider to explain how to ensure the report includes headers and bodies, the success rate of customers doing so tends to be low. Even those complaints that do contain all required information might prove difficult to parse, as variations in formatting and content types will lead to automated tools being consistently updated with new logic blocks for each variation that occurs.
メールボックスのプロバイダは、このボタンをお客様のメールクライアントを提供していない場合には、効果的なフィードバックループを提供するためのフィードバックプロバイダのチャンスはスリムです。メールボックスのプロバイダは、レポートヘッダーとボディを含んでいるかどうかを確認する方法を説明するために、メールボックスプロバイダ中央の場所へとするために、不要なメールを転送するために顧客を指示することは可能であるが、そうする顧客の成功率が低くなる傾向にあります。フォーマットとコンテンツタイプの変動は自動化ツールが一貫発生する各バリエーションのための新たな論理ブロックで更新されることにつながるよう、必要なすべての情報が含まれていても、これらの苦情は、解析が難しいことを証明することがあります。
It is recommended that Feedback Messages be sent using the standard Abuse Reporting Format, to facilitate uniformity and ease of processing for all consumers of feedback. This will also enable the Feedback Provider to extensively automate the processes of generating and sending Feedback Messages and of analyzing complaint statistics. This format is described further in Appendix 1.
フィードバックメッセージは、フィードバックのすべての消費者のための均一性や処理を容易にするために、標準的な虐待の報告様式を使用して送信することをお勧めします。これはまた、広範囲にフィードバックメッセージを生成して送信すると、苦情の統計を分析するプロセスを自動化するためにフィードバックプロバイダが有効になります。このフォーマットは、付録1にさらに記載されています。
Feedback Loops are usually (but not always) keyed to the "last hop" IP address (i.e., the IP address that passed the unwanted message to the Mailbox Provider's servers). Consequently, the Feedback Provider must be able to process the header from each complaint to determine the IP address for the complaint.
フィードバックループは、通常は（常にではない）されている「最後のホップ」IPアドレスをキーに（つまり、メールボックスプロバイダのサーバーへの不要なメッセージを渡されたIPアドレス）。その結果、フィードバック・プロバイダは、クレームのためのIPアドレスを決定するために、各クレームからヘッダを処理できなければなりません。
A Feedback Provider may wish to provide, as part of its Feedback Loop, other information beyond Spam Complaints that Feedback Consumers may find valuable. It might include summary delivery statistics (volume, inbox delivery rate, Spam trap hits, etc.) or other data that the Feedback Provider may deem pertinent to Feedback Consumers.
フィードバックプロバイダは、そのフィードバックループの一部として、フィードバック消費者は貴重な見つけることがスパム苦情を越えて他の情報を提供することを望むかもしれません。これは、フィードバックプロバイダのフィードバック消費者に適切とみなすことができることを要約配信統計（ボリューム、受信トレイの配信レート、スパムトラップヒットなど）や他のデータが含まれる場合があります。
Any mature Feedback Loop system will produce situations in which the Feedback Consumer may have follow-up questions or have other information to provide in regard to the feedback. Feedback Messages should include contact information (typically an Email Address) for the Feedback Consumer to use for such questions, and ideally the contact Email Address will feed into a ticket system or other automated tool used by the Mailbox Provider's postmaster and/or anti-abuse staff for handling general email delivery issues.
どれ成熟したフィードバックループシステムは、フィードバック消費者は、フォローアップの質問を持っているか、フィードバックに関して提供するその他の情報を持っている可能性のある状況を生成します。フィードバックメッセージは、フィードバック消費者がこのような質問のために使用するための連絡先情報（通常は電子メールアドレス）を含める必要があり、理想的には連絡先のメールアドレスは、チケットシステムやメールボックスプロバイダーの郵便局長および/または抗乱用によって使用される他の自動化ツールに送ります一般的なメール配信の問題を処理するためのスタッフ。
Feedback Messages provide information relayed by Feedback Providers from a Mailbox Provider's End Users to the Feedback Consumer. There might not be any concerns with relaying non-private data to a third party. However, the information provided in the complaints generated by the user must be evaluated and any data deemed private may need to be removed before distributing to a third party, per local policy. For example, the Recipient's or reporter's Email Address and IP address may be categorized as private data and removed from the feedback report that is provided to the Feedback Consumer. Privacy laws and corporate data classification standards should be consulted when determining what information should be considered private.
フィードバックメッセージは、フィードバックの消費者へのメールボックスプロバイダのエンドユーザーからのフィードバックプロバイダによって中継された情報を提供します。第三者への非プライベートなデータを中継するとの懸念があっていない可能性があります。しかし、ユーザーによって生成された苦情で提供される情報が評価されなければならないとプライベートとみなされる任意のデータは、ローカルポリシーに従って、第三者に配布する前に除去する必要があるかもしれません。たとえば、受信者や記者の電子メールアドレスとIPアドレスは、プライベートデータとして分類することができるとフィードバックの消費者に提供されるフィードバックレポートから削除します。プライベート考慮すべき情報を決定する際に個人情報保護に関する法律や企業のデータ分類基準を相談する必要があります。
Information provided by the Feedback Consumer to the Feedback Provider for the purpose of enrolling in the Feedback Loop should also be kept private. It should only be shared or used for the purposes explicitly agreed to during the enrollment process (see the "Terms of Use" section below).
フィードバックループに登録する目的のためにフィードバックプロバイダにフィードバック消費者によって提供される情報も非公開にする必要があります。それだけで共有したり（以下の「利用規約」を参照）、明示的に登録プロセスの間に合意された目的のために使用する必要があります。
Feedback Loops inevitably span country borders. Local laws and regulations regarding distribution of information domestically and internationally need to be considered when implementing a Feedback Loop program. For example, in some European countries, data exchange requires permission from governing bodies. The terms and circumstances surrounding the exchange of data need to be clearly defined and approved.
フィードバックは、必然的に国境をまたがるループします。国内外の情報の流通に関する現地の法律や規制は、フィードバックループプログラムを実装する際に考慮する必要があります。例えば、一部のヨーロッパ諸国では、データ交換が体を支配からの許可が必要です。データの交換を取り巻く条件と状況が明確に定義され、承認される必要があります。
A written Terms of Use agreement should be provided by the Feedback Provider and agreed to by the Feedback Consumer before any feedback is provided. The following concepts should be considered when drafting the terms of use agreement:
利用契約の書かれた規約は、フィードバックプロバイダによって提供され、任意のフィードバックが提供される前にフィードバック消費者によって合意されなければなりません。利用契約の条項を起草する場合は、次の概念を考慮する必要があります。
o Data provided in Feedback Messages are provided to a specific, approved entity. Information should not be transmitted outside of the intended, approved Recipient. Any inappropriate use of the information can lead to immediate termination from the feedback program.
Oフィードバックメッセージに提供されるデータは、特定の、承認されたエンティティに提供されています。情報が意図し、承認された受信者の外に送信するべきではありません。情報の不適切な使用は、フィードバックプログラムからの即時終了につながることができます。
o Consumers of Feedback have a responsibility to keep the information they provide for Feedback Loop purposes -- such as abuse contact information, IP addresses, and other records -- accurate and up to date.
フィードバックのO消費者はフィードバックループの目的のために提供した情報を維持する責任がある - など虐待の連絡先情報、IPアドレス、およびその他のレコードとして - 、正確かつ最新の状態に。
o The providing of Feedback information is a privilege and needs to be treated appropriately. It does not entitle the consumer of the feedback to any special sending privileges.
フィードバック情報提供oを特権であり、適切に処理される必要があります。それは特別な送信者権限へのフィードバックの消費者が権利を与えるものではありません。
o Approval and continued enrollment in the program is a privilege that can be denied or revoked for any reason and at any time.
プログラム中のOの承認と継続的な登録が拒否されたか、何らかの理由で、いつでも取り消すことができる権限です。
There should be a streamlined application process for receiving feedback and the vetting of such applications. This vetting may be stringent in cases where the Mailbox Provider chooses to tie its Complaint Feedback Loop program to a whitelist. Criteria may involve the following: o Cross-checking that the requestor is indeed authorized to receive feedback for the IP addresses concerned.
フィードバックと、このようなアプリケーションの審査を受けるための合理化されたアプリケーションプロセスがあるはずです。この審査は、メールボックスのプロバイダは、ホワイトリストにその苦情フィードバックループプログラムを結びつけることを選択した場合には厳しいかもしれません。基準は以下を含むことができる：要求者が実際に関係するIPアドレスのためのフィードバックを受け取ることを許可されていることをクロスチェックoを。
o Gathering other information such as whether the IPs are an ISP smarthost network, a webhosting farm, an email marketing or Mailing List service, or other entity.
こうしたIPアドレスはISPのスマートホストのネットワーク、ウェブホスティングファーム、メールマーケティングやメーリングリストサービス、または他のエンティティであるかどうかなど、Oの収集その他の情報。
o Requesting information such as a link to the policies of the requestor, contacts to send Feedback Messages, and escalation points of contact.
そのような要求者の政策、フィードバックメッセージを送信する連絡先、連絡先のエスカレーションポイントへのリンクなどの情報を要求し、O。
Ideally, enrollment will be a two-step process, with the applicant filling out a form and being required to receive and acknowledge a confirmation email (best sent to abuse@ or postmaster@ the domain in question) before the applicant's request is even put into the queue for the Feedback Provider to process.
理想的には、登録は申請者がフォームに記入し、申請者の要求がさえに入れられる前に、確認メール（最良の問題のドメイン@虐待@またはポストマスターに送信された）を受信し、承認を要求されると、2段階のプロセスになりますプロセスへのフィードバックプロバイダのキュー。
Ownership of IP addresses can and should be cross-checked by means of origin Autonomous System Number (ASN), WHOIS/RWHOIS records, Reverse DNS of the sending hosts, and other sources. This can be automated to some extent, but it often requires some manual processing.
IPアドレスの所有権は、原点自律システム番号（ASN）、WHOIS / RWHOISレコード、送信ホストのDNSを逆にし、他のソースによってクロスチェックする必要がありますすることができます。これは、ある程度自動化することができますが、それは多くの場合、いくつかの手動処理が必要となります。
Applications for Feedback Loops can be accepted on a stand-alone web site or can be part of the Mailbox Provider's postmaster site. Regardless, the web site for the Complaint Feedback Loop program should contain other content specific to the Feedback Loop, including FAQs for the Feedback Loop program, the Terms of Service for the Feedback Loop, and perhaps a method for enrolled parties to modify their existing enrollments.
フィードバックループのためのアプリケーションは、スタンドアローンのウェブサイト上で受け入れることができるか、メールボックスプロバイダーの郵便局長サイトの一部にすることができます。在籍当事者は、既存の入学者を変更するためにかかわらず、苦情フィードバックループプログラムのウェブサイトは、他のコンテンツフィードバックループプログラムについてよくあるご質問、フィードバックループのためのサービス規約を含むフィードバックループに特有の、そしておそらくメソッドが含まれている必要があります。
The web site should also provide the Feedback Consumer with general information on how the feedback will be sent, including:
ウェブサイトも含めて、フィードバックを送信する方法に関する一般的な情報とフィードバック消費者に提供すべきです：
o Report Format (ARF or otherwise)
Oレポート形式（ARFまたはその他）
o Sending IP addresses and/or DKIM "d=" string
IPアドレスおよび/またはDKIM "D =" 文字列を送信するO
o "From" Email Address
メールアドレス「から」O
Denial of a Feedback Loop application may be appropriate in certain cases such as:
フィードバックループアプリケーションの拒否は、次のような特定の場合に適切であり得ます。
o Where the Feedback Provider suspects "gaming" of delivery policies via the Feedback received, with attempts to pollute Feedback Loop metrics by, for example, creating bogus accounts and reporting false negatives with these, to offset the negative reputation caused by high complaint rates.
Oフィードバックプロバイダー容疑者などしてフィードバックループメトリックを汚染しようとする試みで、受け取ったフィードバックを経由して配信ポリシーの「ゲーム」、偽のアカウントを作成し、これらと偽陰性の報告では、高苦情率によって引き起こされる負の評判を相殺する場所。
o Where the Feedback Provider has decided to block the Message Originator's IP space for which feedback has been requested on the grounds that email from that originator has a sufficiently negative reputation that it will not be delivered at all. This is somewhat on the lines of a global unsubscribe of the Message Provider's users from the originator's lists, which would make rendering additional feedback unnecessary.
Oはどこフィードバックプロバイダは、フィードバックは、その発信元からのメールは、それがすべてで配信されないことを十分に負の評判を持っていることを理由に要求されたメッセージ発信者のIPスペースをブロックすることを決定しました。これは、不必要な追加のフィードバックをレンダリングするだろう発信者のリストからのメッセージプロバイダのユーザーのグローバル退会のラインに多少です。
It is recommended that the Feedback Provider send notification if an application is denied. Additionally, they should maintain a documented, clear, and transparent appeals process for denial of requests. This process can be as simple as the prospective Feedback Consumer replying to the denial email requesting review or escalation to a team lead, which also cites reasons the application should be reviewed.
アプリケーションが拒否された場合のフィードバックプロバイダが通知を送信することをお勧めします。さらに、彼らは要求の拒否の文書化、明確、かつ透明控訴手続きを維持する必要があります。このプロセスは、将来のフィードバック消費者はまた、アプリケーションが見直されるべきな理由を挙げ、チームのリードにレビューやエスカレーションを要求して拒否メールに返信するだけです。
For a Feedback Loop to be cost-effective and usable for large Feedback Consumers and Feedback Providers, it must be possible for reports to be generated and processed automatically without any human interaction. On the other hand, it should be possible for small Feedback Consumers to handle a low volume of reports manually, without requiring any automation.
フィードバックループは、コスト効果的かつ大規模なフィードバック消費者やフィードバックプロバイダで使用可能なものにするためのレポートが生成され、任意の人間の相互作用せずに自動的に処理されるようにするために、それが可能でなければなりません。小さなフィードバック消費者は任意の自動化を必要とせずに、手動でレポートの低いボリュームを処理するため一方、それは可能なはずです。
In automating the feedback process, the consumer of the Feedback Stream must receive enough information about the report that it can take appropriate action, typically to remove the Recipient from the Mailing List about which it is sending a report. The Recipient's Email Address is not enough, as the Recipient may be on several Mailing Lists managed by the Feedback Loop consumer and only need to be removed from the particular list reported.
フィードバックプロセスを自動化することで、フィードバックストリームの消費者は、それがレポートを送信しているかについて一般的にメーリングリストから受信者を削除するには、適切な行動を取ることができることを報告に関する十分な情報を受け取る必要があります。受信者は、フィードバックループの消費者によって管理される、いくつかのメーリングリスト上にのみ報告特定のリストから削除する必要があるかもしれないとして、受信者の電子メールアドレスは、十分ではありません。
Also, some producers of Feedback Loops might redact the Recipient's Email Address for privacy reasons. Effective implementation of a Complaint Feedback Loop requires that the Feedback Provider put in place as many automated processes and tools as feasible to handle all aspects of the process. Feedback Providers should seek to automate or script the following:
また、フィードバックループの一部の生産者は、プライバシー上の理由のために受信者の電子メールアドレスを墨消しすることがあります。苦情フィードバックループの効果的な実施は、プロセスのすべての側面を処理するためにフィードバックプロバイダが所定の位置に置くことを可能な限り多くの自動化されたプロセスとツールが必要です。フィードバックプロバイダは、自動化またはスクリプト以下に努める必要があります。
o Accepting and validating Feedback Loop Applications from prospective Feedback Consumers.
将来のフィードバック消費者からのフィードバックループ申請を受け付けし、検証し、O。
o Processing requests to determine whether or not they meet the Feedback Provider's criteria for enrollment in the program.
彼らはプログラムに入学のためのフィードバックプロバイダの基準を満たしているかどうかを判断するためにO処理要求。
o Accepting Spam Complaints from End Users; this will form the bulk (and perhaps sole) component of the feedback sent by the Feedback Provider.
エンドユーザーからのスパムの苦情を受け入れ、O。このフィードバック・プロバイダによって送信されたフィードバックのバルク（そしておそらく唯一）成分を形成するであろう。
o Production of Feedback Messages from Spam Complaints.
Oスパム苦情からのフィードバックメッセージの生成。
o Production of other Feedback Loop artifacts as chosen by the Feedback Provider.
フィードバックプロバイダによって選ばれたように、他のフィードバックループアーティファクトのO生産。
o Optionally, provision of a mechanism for Feedback Consumers to further engage a Feedback Provider about a given Feedback Message.
O必要に応じて、さらに所定のフィードバックメッセージに関するフィードバック・プロバイダと係合するようにフィードバック消費者のための機構を提供します。
o Ongoing validation of Feedback Loop enrollments to determine if a currently enrolled IP address or network merits continued inclusion in the Feedback Loop.
Oフィードバックループの継続的な検証は、現在のIPアドレスまたはネットワークメリットがフィードバックループに含めるを継続登録かどうかを決定するために入学します。
o Optional periodic emails to Feedback Consumers to determine if their enrolled Email Addresses are still valid.
その在籍メールアドレスがまだ有効であるかどうかを判断するためにフィードバック消費者へのOオプションの定期的な電子メール。
It is recommended that self-service maintenance be offered to Feedback Consumers, to the extent practicable. The more they can do themselves, the less you have to do.
セルフサービスのメンテナンスを実施可能な限り、フィードバック消費者に提供することをお勧めします。より多くの彼らは自分自身を行うことができ、より少ないあなたがしなければなりません。
The criteria that a Feedback Provider uses to validate a Feedback Loop application may change over time. It is a near certainty at least some subset of Feedback Consumers enrolled to receive feedback will at some point after enrollment fail to meet those criteria, regardless of whether or not the criteria change.
フィードバックプロバイダがフィードバックループアプリケーションを検証するために使用する基準は、時間の経過とともに変化することがあります。これは、フィードバック消費者の少なくともいくつかのサブセットが登録に関係なく、基準が変化したか否かの、これらの基準を満たすために失敗した後、いくつかの点で意志のフィードバックを受け取るために登録ほぼ確実です。
The Feedback Provider should put in place tools to periodically re-validate all Feedback Consumers enrolled in its Feedback Loop system against its current criteria. Additionally, the Feedback
フィードバックプロバイダは、すべてのフィードバック消費者は、現在の基準に照らしてそのフィードバックループシステムに登録定期的に再検証する場所ツールに置く必要があります。また、フィードバック
Provider will likely have objective criteria for remaining in the Feedback Loop for enrolled Feedback Consumers; the enrolled consumers should be validated against those criteria as well.
プロバイダは、おそらく在籍フィードバック消費者のためのフィードバックループ内の残りのための客観的な基準を持っています。在籍消費者は同様にそれらの基準に照らして検証する必要があります。
Just as some Mailing List software has the built-in ability to send periodic "probe" emails to subscribed addresses to validate them, so too should the Feedback Provider develop tools to send similar emails to the addresses receiving Feedback Messages to ensure that they are valid. This is especially true for the addresses that are not the abuse@ and postmaster@ addresses originally used as part of the enrollment acknowledgment step. Over time, people may change employers, or at least roles, and validating the Email Addresses associated with an IP is one way for the Feedback Provider to ensure that Feedback Messages are still being accepted and acted upon by the Feedback Consumer.
いくつかのメーリングリストソフトウェアは、それらを検証するために、サブスクライブのアドレスに定期的に「プローブ」メールを送信する機能を内蔵しているので、あまりにもフィードバックプロバイダは、彼らが有効であることを保証するために、フィードバックメッセージを受信したアドレスに類似した電子メールを送信するためのツールを開発すべきであるのと同じように。これは、もともと登録承認ステップの一部として使用されたアドレス@虐待@および郵便局長ないアドレスのために特に当てはまります。時間が経つにつれて、人々は雇用者を変更、または少なくとも役割で、そしてIPに関連付けられた電子メールアドレスを検証することフィードバックメッセージはまだ受け入れられ、フィードバック消費者によって作用されていることを確実にするためにフィードバックプロバイダのための一つの方法であることがあります。
Updating Feedback Consumers when one's own IP addresses are changing is an important aspect of Feedback Loop maintenance. The exact format, automation, and other considerations of these updates are outside the scope of this document, but are topics worthy of further discussion and eventual documentation.
自分のIPアドレスが変更されているフィードバック消費者を更新すると、フィードバックループのメンテナンスの重要な側面です。正確なフォーマット、自動化、およびこれらの更新プログラムの他の考慮事項は、この文書の範囲外であるが、更なる議論と最終的な文書に値するトピックです。
A Feedback Consumer receives its Feedback Messages after its submitted Application for a Complaint Feedback Loop is approved. A Feedback Consumer will usually have Complaint Feedback Loop subscriptions set up with multiple Feedback Providers. Different Feedback Streams may be in different formats or include different information, and the Feedback Consumer should identify a process to organize the data received and take appropriate action.
フィードバック消費者はループが承認された苦情のフィードバックのためにその提出適用した後にそのフィードバックメッセージを受け取ります。フィードバック消費者は通常、複数のフィードバック・プロバイダで設定苦情フィードバックループのサブスクリプションを持っています。異なるフィードバックストリームは異なるフォーマットであるか、または異なる情報を含み、フィードバック消費者は、受信したデータを整理し、適切な行動を取るためのプロセスを識別すべきであることができます。
A Feedback Consumer, Mailbox Provider, or Access Provider (i.e., a hosting company or ISP) will use this Feedback to identify network compromises, fraudulent accounts, policy violations, and other concerns. The Feedback Loop provides real-time visibility into Spam Complaints from Message Recipients, greatly enabling these Mailbox Providers to mitigate Spam propagating from their networks.
フィードバック消費者、メールボックスプロバイダー、またはアクセスプロバイダ（すなわち、ホスティング会社やISP）は、ネットワークの妥協、不正アカウント、ポリシー違反、およびその他の問題を識別するために、このフィードバックを使用します。フィードバックループが大幅に自社のネットワークから伝播スパムを軽減するために、これらのメールボックスプロバイダを有効にする、メッセージ受信者からスパムの苦情にリアルタイムの可視性を提供します。
Senders of bulk email should use the complaints to make decisions regarding future mailings. Such decisions may include one or more of the following: modification of email frequency, branding, opt-in practices, or list management.
バルク電子メールの送信者は、将来の郵送に関する意思決定を行うために苦情を使用する必要があります。電子メールの頻度、ブランディング、オプトイン慣行、またはリスト管理の変更：このような決定は、以下の1つ以上を含むことができます。
The authors of this document urge those who are solely Feedback Consumers to also read the previous sections for Mailbox Providers and Feedback Providers. This will provide the proper context of the recommendations included below.
本書の著者は、単にフィードバック消費者のある方にもメールボックスプロバイダとフィードバックプロバイダの前のセクションを読むことを強くお勧めします。これは、以下に含ま勧告の適切なコンテキストを提供します。
Further recommendations for bulk senders may be found in the MAAWG Sender Best Communications Practices [MAAWG-BCP].
バルク送信者のための更なる勧告はMAAWG送信者のベストプラクティス・コミュニケーションズ[MAAWG-BCP]に見出すことができます。
Feedback Consumers need to prepare to process and act on feedback before asking to receive it. At a minimum, make sure to have:
フィードバック消費者はそれを受け取るために尋ねる前に処理して、フィードバックに基づいて行動する準備をする必要があります。最低でも、持っていることを確認してください。
1. The "Role" Email Addresses such as abuse@ and postmaster@. The person who applies for the Feedback needs to make sure they have access to these Email Addresses. Feedback Providers often send a confirmation link to those accounts to prevent End Users, Spammers, or competitors from signing up for Feedback for which they are not authorized.
こうした虐待@とのpostmaster @として1.「役割」メールアドレス。フィードバックのために適用される人は、彼らがこれらの電子メールアドレスへのアクセス権を持っていることを確認する必要があります。フィードバックプロバイダは、多くの場合、彼らが許可されていないため、フィードバックにサインアップするからエンドユーザー、スパマー、または競合他社を防ぐために、それらのアカウントに確認用のリンクを送信します。
2. A dedicated Email Address to receive the Feedback Messages, such as fbl@example.com or isp-feedback@example.com. While not required, this will make it easier for to process the reports received.
2.専用のメールアドレスは、このようなfbl@example.comやisp-feedback@example.comとしてフィードバックメッセージを、受信します。必須ではありませんが、これはそれが簡単に受信レポートを処理できるようにするためだろう。
3. A list of IP addresses for which you want to receive Feedback Messages, making sure you can prove the ownership of the IP addresses and associated domains. Feedback Providers often require that:
3.フィードバックメッセージを受信したいIPアドレスのリストを、あなたはIPアドレスと関連付けられているドメインの所有権を証明することができることを確認すること。フィードバックプロバイダは、多くの場合、そのが必要です。
* Reverse DNS for each IP shares the domain of either the
applicant's Email Address or the Email Address that will be
receiving the Feedback Messages.
* WHOIS information for the IPs requested is obviously associated with the domain name.
*要求されたIPアドレスのためのWHOIS情報は明らかに、ドメイン名に関連付けられています。
4. Contact information such as name, Email Address, phone number, and other relevant information.
4.連絡先情報名前、メールアドレス、電話番号、およびその他の関連情報など。
5. The knowledge that if the application form asks for your credit card number or other financial information, it is assuredly a scam.
5.申込書は、クレジットカード番号やその他の財務情報を要求した場合、それは確実に詐欺であるという知識に。
Once a Feedback Consumer has signed up to receive feedback from a Feedback Provider, it may also receive several other sorts of delivery-related reports. This includes Feedback Messages, administrative messages, and other messages.
フィードバック消費者のフィードバックプロバイダからのフィードバックを受け取るためにサインアップしていたら、それはまた、配信関連のレポートのいくつかの他の種類を受け取ることができます。これは、フィードバックメッセージ、管理メッセージ、およびその他のメッセージを含んでいます。
Feedback Messages are the main emails generally associated with a Feedback Loop. Each time a Recipient hits the "This Is Spam" button, the Feedback Loop system creates a boilerplate report with a copy of the original email attached and sends it to the consumer of the Feedback Loop.
フィードバックメッセージは、一般的にフィードバックループに関連する主な電子メールです。受信者がヒットするたびにボタン「これはスパムである」、フィードバックループシステムが接続元の電子メールのコピーを持つ定型レポートを作成し、フィードバック・ループの消費者に送信します。
The handling of feedback reports is discussed in the next section.
フィードバック・レポートの取扱いについては、次のセクションで説明されています。
Administrative messages will typically be sent to the Email Address provided for contacting the person who originally applied for the Feedback Loop, rather than to the address provided for handling the Feedback Messages. These messages are likely to be sent infrequently and irregularly, but it is important they are seen by the person managing the Feedback Stream processor in a timely manner. It is usually a poor idea to have these sent to an individual's Email Address since they may be lost if that person is on vacation, changes position within the company, or leaves the company.
管理メッセージは通常、むしろフィードバックメッセージを処理するために提供されたアドレスよりも、もともとのフィードバックループの適用者に接触するために提供したメールアドレスに送信されます。これらのメッセージは、まれと不規則に送られる可能性が高いが、彼らがタイムリーにフィードバックストリームプロセッサを管理する人が見られていることが重要です。それは、その人が、会社内の位置を変更し、休暇にあるか、会社を離れた場合、彼らが失われる可能性があるため、これらは個人のメールアドレスに送信されてきたために、通常は貧しい考えです。
Instead, they should be sent to a role account that goes to a ticketing system or "exploded" to multiple responsible parties within the organization. If there is not already an appropriate role account such as support@ or noc@ that reaches the right team, it may be a good idea to set up a dedicated alias such as fblmaster@ to sign up for all Feedback Loops.
代わりに、彼らはチケットシステムに行くか、組織内の複数の責任者に「爆発」役割アカウントに送信されなければなりません。このような支持@または右のチームになったNOCの@として、既に適切な役割のアカウントが存在しない場合、すべてのフィードバックループにサインアップするために、このようなfblmasterの@として専用のエイリアスを設定するのは良いアイデアかもしれません。
The detail in a report card can vary greatly. Feedback Providers might send a regular summary of traffic levels and complaint rates seen, perhaps just an overview or possibly broken down by source IP address or some other identifier. Sometimes these may be sent just when some metric (typically a complaint rate) reaches a level that causes the Mailbox Provider to notify the Feedback Consumer there may be a problem developing that needs to be investigated and addressed. At the other extreme, some report cards will contain almost no useful data at all, just a warning that the Message Originator is causing complaints -- with the implication that its email will be blocked unless it is improved.
レポートカードでの詳細は大きく異なります。フィードバックプロバイダは、送信元IPアドレスまたは他の識別子によって破壊多分ちょうど概要または多分見トラフィックレベルと苦情率の定期的な要約を送信することがあります。時には、これらは、いくつかのメトリック（通常は苦情率）を調査して対処する必要がある問題現像があるかもしれませんフィードバック消費者に通知するメールボックスプロバイダの原因となるレベルに達したときだけ送信されることがあります。それが改善されない限り、その電子メールがブロックされることを暗示して - 他の極端では、いくつかのレポートカードは、すべてでメッセージの発信が苦情の原因となっていることだけで警告をほとんど有用なデータが含まれています。
Report cards are human readable, since there are not currently any standard machine-readable formats and the information they include, both the provided metrics and their semantics, varies widely from one Mailbox Provider to another. They are useful reference overviews for a Message Originator to monitor the overall perceived quality of the email it sends and, in the case of ESPs, perhaps which customers are causing higher than expected rates of complaints. They can also be the only warning of serious problems prior to email being blocked altogether by the receiving Mailbox Provider. It is critical they be are seen by someone handling delivery issues for the Message Originator, so again, they should be handled by an email alias that is always read.
レポートカードは、任意の標準機械可読フォーマットが現在存在しないので、読める人間であり、彼らには、情報提供メトリックとその意味論の両方、別のメールボックスプロバイダから大きく異なります。彼らはそれが送信し、ESPの場合には、おそらく顧客が苦情の期待収益率よりも高い原因となっている電子メールの全体的な知覚品質を監視するためのメッセージの発信のための便利なリファレンスの概要です。彼らはまた、受信メールボックスプロバイダによって完全にブロックされて電子メールで送信する前に深刻な問題の唯一の警告することができます。彼らが常に読まれた電子メールエイリアスによって処理されなければならない、彼らは再び、メッセージ発信のため配信の問題を扱う誰かに見られていることが重要です。
Report cards also contain useful data to track mechanically and perhaps report on trends, though as their content varies, it is hard to generalize what use might be made of them. At the very least, the "warning" report cards are something that should be visible on an ESP's business intelligence or delivery dashboard.
レポートカードも機械的に追跡し、その内容が変化するように、彼らで作られるかもしれないものを使用し一般化するのは難しいですが、おそらく、動向を報告する有用なデータが含まれています。少なくとも、「警告」のレポートカードはESPのビジネス・インテリジェンスや配信ダッシュボードに表示されなければならない何かです。
Mailbox Providers sending feedback may have published policies as to how they expect a Feedback Consumer to use Feedback Messages or may expect the Feedback Consumer to simply "make the problem stop". In practice, this mostly boils down to three things:
フィードバックを送信するメールボックスのプロバイダは、彼らがフィードバック消費者は、フィードバックメッセージを使用することを期待するか、フィードバック消費者は単に「問題の停止を行う」ことを期待してどのようにとの方針を発表している可能性があります。実際には、これは主に三つに要約します：
o First, where the consumer of the feedback has some specific control over sending the email, it is expected not to send email of the same type to the same Recipient again.
フィードバックの消費者は、電子メールの送信の上にいくつかの特定のコントロールを持っているO第一には、再び同じ受信者に同じタイプの電子メールを送信しないように期待されています。
o Second, it should identify the underlying problem (if any) and fix it so that it receives fewer reports of that type in the future.
O第二に、それは根本的な問題を特定し、（もしあれば）、それが将来的にそのタイプの少数の報告を受け取るようにそれを修正する必要があります。
o Third, it is not necessary to inform the Mailbox Provider or Feedback Provider, or their End User(s), of which actions have been or will be taken in response to automated complaint feedback.
O第三に、メールボックスプロバイダまたはフィードバックプロバイダ、またはアクションがまたは自動苦情のフィードバックに応じて取得されますされているの彼らのエンドユーザー（複数可）、通知する必要はありません。
If the Feedback Consumer is a separate entity from the Message Originator, the two entities are expected to work together to resolve any problem.
フィードバック消費者がメッセージ発信とは別のエンティティである場合には、2つのエンティティは、任意の問題を解決するために協力することが期待されます。
A Sender (whether author or originator) of commercial email should treat the Feedback Message similar to an unsubscribe request, ensuring that no further email from that list is sent to that Recipient, either by removing the email from that list or adding it to the associated suppression list. It needs to use its best judgment, keeping in mind the goal of reducing future complaints, as to how broadly to apply that unsubscribe. Suppressing the address across an entire ESP is likely too broad. However, if a single Feedback Consumer (or customer of an ESP) has multiple segmented lists, then suppressing them across all those lists is probably a good idea.
商用電子メールの送信者（著者または発信するかどうか）は、そのリストから、更なる電子メールがそのリストからメールを削除または関連に追加することのいずれかによって、その受信者に送信されないことを保証する、解除要求と同様フィードバックメッセージを扱うべき抑制リスト。それは心の中でその退会を適用する方法広くするとして、将来の苦情を削減するという目標を保ち、その最善の判断を使用する必要があります。全体のESP間でアドレスを抑制することは広すぎる可能性があります。単一フィードバック消費者（またはESPの顧客）は、複数のセグメント化されたリストを持っている場合は、それらすべてのリスト間でそれらを抑制することは、おそらく良いアイデアです。
It is universally acknowledged that not all complaints are intentional; for example, Recipients might accidentally hit the wrong button or mark an entire mailbox as Spam. However, it is best for Feedback Consumers to assume the Recipient does not want more email and to suppress mail to the Recipient in all but fairly extreme cases such as a Mailing List the Recipients pay to receive, email from a genuine company to its valid employees, or email from an Access Provider or Mailbox Provider to its users.
普遍的ではない、すべての苦情は意図的なものであることを認めています。例えば、受信者が誤って間違ったボタンを押すか、スパムなどのメールボックス全体をマークすることがあります。しかし、それはその有効な従業員に本物の会社からの電子メール、受信者が複数の電子メールを望んでいないと受信者が受け取るために支払うようにメーリングリストなどすべてが、かなり極端な場合には受信者にメールを抑制すると仮定するフィードバック消費者のために最善でありますそのユーザーへのアクセスプロバイダまたはメールボックスプロバイダから、または電子メール。
This gets more complex in the case of transactional mail -- mail that is tied to some other service, such as ticket purchase confirmations or billing statements. In that case, the Feedback Consumer has to, again, use its best judgment based on the specific situation. In some cases, the right thing to do may be to communicate with the Recipient via another channel, such as a message on a web site used for the service; i.e., "You reported your notification mail as Spam so we are not going to send you any more messages unless you tell us otherwise".
いくつかの他のサービスに接続されていたメールは、そのようなチケット購入の確認や請求書など - これは、トランザクションのメールの場合は、より複雑になります。その場合には、フィードバック消費者は、再び、特定の状況に基づいて最良の判断を使用する必要があります。いくつかのケースでは、行うには正しいことは、そのようなサービスのために使用されるWebサイト上のメッセージとして、別のチャネルを介して受信者と通信することであってもよいです。すなわち、「あなたはとても私たちは、あなたがそうでなければ、私たちに教えていない限り、あなたに任意のより多くのメッセージを送信するつもりはありませんスパムとしてあなたの通知メールを報告」。
In some cases, the best thing to do may be to ignore the Feedback Message. For example, if your customer has reported as Spam the airline tickets he purchased and you emailed him, he probably did not mean it and he is going to be very annoyed if you do not send him the other tickets he has ordered. In rare cases, it might be appropriate to suppress email to the Recipient, but also to suspend access to a service he or she uses until the Recipient confirms a desire to receive the associated email. In all these cases, the important goal is to keep the customer happy and reduce future complaints, even in the apparently paradoxical situations where the way to do that is to ignore their Feedback. In the real world, however, these are a small minority of cases.
いくつかのケースでは、行うための最善のことは、フィードバックメッセージを無視することであってもよいです。たとえば、顧客がスパムとして彼を彼が購入し、あなたが電子メールで送信航空券を報告した場合、彼はおそらくそれを意味しなかった、あなたは彼に彼が命じた他のチケットを送信しない場合、彼は非常にイライラになるだろう。まれなケースでは、受信者に電子メールを抑制するために、だけでなく、受信者は、関連する電子メールを受信したいという願望を確認するまで、彼または彼女が使用するサービスへのアクセスを停止することが適切であるかもしれません。これらすべてのケースでは、重要な目標であってもそれを行うための方法は、彼らのフィードバックを無視することで明らかに逆説的な状況で、幸せな顧客を維持し、将来の苦情を減らすことです。現実の世界では、しかし、これらは例ごく少数です。
Counting the Feedback Messages received over regular time periods can provide much useful information to ISPs, ESPs, and other Feedback Consumers, especially when broken down appropriately.
フィードバック・メッセージは、定期的な時間期間にわたって受信されたカウントを適宜破壊特にISPは、のESP、および他のフィードバック消費者に多くの有用な情報を提供することができます。
An ISP (Mailbox Provider or Access Provider) might want to count the number of Feedback Messages a particular customer or IP address causes in a given day. If there is a sudden increase from a particular customer or server, it may be a sign that a Spammer has signed up or a system has been compromised. If there is a high level of complaints about a particular customer, it may be worth investigating to see if there is a reason for that. For example, 10 Feedback Messages a day would be a sign of serious problems in some cases, but might be perfectly reasonable "background" levels for a Message Originator that sends 300,000 emails a month. If the count shows there may be a problem, the ISP can dig down and look at the emails that are being reported to determine the underlying cause.
ISP（メールボックスプロバイダまたはアクセスプロバイダ）は、特定の顧客またはIPアドレスを指定した日になりフィードバックメッセージの数をカウントすることがあります。特定の顧客またはサーバからの急激な増加があれば、それはスパマーがサインアップしたか、システムが危険にさらされている徴候である可能性があります。特定の顧客に関する苦情のハイレベルがある場合は、その理由があるかどうかを確認するために調査する価値があるかもしれません。例えば、10のフィードバックメッセージの日は、いくつかのケースでは深刻な問題の兆候だろうが、完全に30万電子メールの月を送信メッセージの発信のための合理的な「バックグラウンド」レベルであるかもしれません。カウントは問題がある可能性があり示された場合、ISPは掘り下げると根本的な原因を決定することが報告されている電子メールを見ることができます。
An ESP can do similar things but can also break the data down in more ways: by customer, by Mailing List, by campaign. An ESP also has access to more information; it knows how many emails were delivered to the receiving Mailbox Provider over a given time period. As a result, it can estimate the number of complaints divided by the number of emails sent, which is often a more useful metric than the absolute number of reports. This is critical data for ESPs to track over time because it can help identify and quantify problem customers.
ESPは同様のことを行うことができますだけでなく、ダウンより多くの方法でデータを壊すことができる：顧客による、キャンペーンによって、メーリングリストで。 ESPはまた、より多くの情報へのアクセスを持っています。それは、与えられた時間期間にわたって受信メールボックスプロバイダに配信されたどのように多くのメールを知っています。その結果、多くの場合、レポートの絶対数よりも有用メトリックで送信されたメールの数で割った苦情の数を推定することができます。それは問題のある顧客を特定し、定量化することができますので、これはESPのは、時間の経過を追跡するための重要なデータです。
An individual Feedback Consumer, whether sending their own email or using an ESP, can acquire at least some information from complaint rates. A spike in complaints on an otherwise stable list might be a sign there is a problem with address acquisition, if the spike is due to reports from new subscribers. If it came from older subscribers, it might be attributable to content of a particular mailing that was not well received. Perhaps the branding was not recognized or the content was offensive or inappropriate for the list.
個々のフィードバック消費者は、自分の電子メールを送信するか、ESPを使用しているかどうか、苦情率から少なくともいくつかの情報を取得することができます。それ以外の場合は安定したリストの苦情のスパイクはスパイクが新規加入者からの報告によるものである場合は、アドレスの取得に問題がある兆候かもしれません。それは、古い加入者から来た場合、それがうまく受信されなかった特定のメーリングリストの内容に起因している可能性があります。おそらく、ブランディングは認識されませんでしたか、コンテンツが、リストのための攻撃的または不適切でした。
The complaint rate is determined by the number of Feedback Messages received over a given time period divided by the number of emails delivered to the associated Mailbox Provider over the same period. It is an obvious and useful metric to track, but there are a few subtle issues to be aware of.
クレーム率は同じ期間にわたって関連するメールボックス・プロバイダに送出メールの数で割った所与の時間期間にわたって受信されたフィードバック・メッセージの数によって決定されます。追跡する明白かつ有用な測定基準であるが、注意すべきいくつかの微妙な問題があります。
One issue is that Feedback Messages tend to be counted on the day the complaint was sent, which is the day the original message was read by the Recipient. That may not be the same day that the message was sent. A simple example is the fact that a Message Originator that sends email regularly Monday through Friday will often see a high complaint rate on Saturday. The absolute number of Feedback Messages sent by people catching up with the week's email over the weekend may not be that high. However, since hardly any email is sent on Saturday, a fairly reasonable number of complaints end up being divided by a very small number of total sent emails, possibly even zero, which would break the reporting engine. This can lead to a complaint rate that seems to range anywhere from suspicious to ridiculous. Consequently, large Mailing Lists that are virtually silent on the weekend could end up receiving more complaints on a Saturday than email they sent that day, leading to complaint rates of well over 100%.
1つの問題は、フィードバックメッセージは元のメッセージが受信者によって読み取られた日である苦情が送信された日、上でカウントされる傾向があるということです。これは、メッセージが送られたのと同じ日ではないかもしれません。簡単な例では金曜日まで定期的にメール月曜日を送信メッセージの発信は、多くの場合、土曜日の高い苦情率を見るという事実です。週末に週の電子メールに追いつく人々によって送信されたフィードバック・メッセージの絶対数はそれほど高くないかもしれません。しかし、ほとんどすべての電子メールは土曜日に送信されていないため、苦情のかなり合理的な数は全体の非常に小さな数で分割されてしまうレポートエンジンを壊すことになる、ゼロであっても、おそらく、電子メールを送りました。これはどこでも疑わしいからばかげの範囲であると思わ苦情率につながることができます。その結果、週末にほぼ沈黙している大規模なメーリングリストをはるかに超える100％の苦情率につながる、彼らはその日の送信した電子メールよりも、土曜日に多くの苦情を受けてしまう可能性があります。
Another arithmetic issue to consider is the interaction between the inbox, the bulk folder, and the "This Is Spam" button. If an organization sends a high volume of email that has a terrible reputation, it may end up with perhaps 500 of its 10,000 mails in the inbox and the remaining 9,500 in the bulk folder. If it gets 10 Feedback Messages and divides that by the 10,000 emails it sent, it will get a very respectable 0.1% complaint rate. However, the Mailbox Provider is probably going to calculate the complaint rate by dividing the number of emails delivered to the inbox instead -- giving a 2% complaint rate, which is probably grounds for immediate blocking. So, if one sees a large difference between a complaint rate as reported by a Mailbox Provider or other reputation system and the rate calculated from raw delivery numbers, it is important to look closely at the data.
考慮すべきもう一つの算術の問題は、受信トレイ、バルクフォルダ、および「これはスパムである」ボタンとの間の相互作用です。組織がひどい評価を得ていた電子メールの高いボリュームを送信した場合、それはおそらく500万件の受信トレイ内のメールやバルクフォルダ内の残りの9,500ので終わることがあります。それは10件のフィードバックメッセージを取得し、万通の電子メールによってそれが送られたことを分割した場合、それは非常に立派0.1％苦情率を取得します。おそらくすぐに遮断するための根拠である2％の苦情率を与える - しかし、メールボックスのプロバイダは、おそらく代わりに、受信トレイに配信メールの数を割ることにより、苦情率を計算しようとしています。 1メールボックスプロバイダまたは他の評判システムと生配信数から算出した割合によって報告された苦情率に大きな差を見ればそう、データをよく見ることが重要です。
Even when signing up for a Feedback Loop is partly automated, modifications to it tend to be handled manually. Even something as trivial as changing the Email Address that the Feedback Messages are sent to can be time-consuming and can cause significant overhead to the Feedback Provider. Multiply that by a dozen Feedback Loops, and getting it right the first time can save a lot of time and energy.
ループが部分的に自動化されているフィードバックのためにサインアップする場合であっても、それへの変更は手動で処理される傾向にあります。でもフィードバックメッセージが送信されているメールアドレスを変更するほどの些細な何かが、時間がかかることができ、フィードバックプロバイダに大きなオーバーヘッドが発生する可能性があります。フィードバックループダースを掛け、そして右の初めてそれを取得することは、時間とエネルギーを大幅に節約することができます。
Even the smallest of users should create a unique email alias for each Feedback Loop. There are several advantages to this, even if they all deliver to the same person's inbox at first. Sending each Feedback Loop to a unique address makes it immediately clear which Feedback Provider was the source of any given report, even if it is sent from an inconsistent From address. It makes it easy to put lightweight pre-processing in place for a particular Feedback Stream, if needed. It makes it easy to discard Feedback Messages if needed (though only temporarily, as it could be very bad for one's reputation to miss a changing trend). If a Feedback Consumer needs to scale up, it is easy to point the existing aliases at a Feedback Loop processing engine.
でも、ユーザーの最小は、各フィードバックループのための一意の電子メールエイリアスを作成する必要があります。いくつかの利点は、それらはすべて、最初は同じ人の受信トレイに配信する場合でも、これにあります。固有のアドレスに、各フィードバックループを送信すると、それはアドレスから矛盾から送信された場合でも、任意のレポートのソースがあったフィードバックプロバイダ、それはすぐに明らかになります。必要な場合は、特定のフィードバックストリームのための場所で軽量な前処理を配置することが容易になります。必要に応じて、（1の評判は変化傾向を欠場することが非常に悪いかもしれないように、しかしのみ一時的に）これは、フィードバックメッセージを破棄することが容易になります。フィードバック消費者がスケールアップする必要がある場合は、フィードバックループ処理エンジンで既存のエイリアスを指すように簡単です。
If an organization might possibly scale up appreciably in the future or consider outsourcing its Feedback Loop processing to a third-party Feedback Consumer, it may be even better to create a subdomain for handling Feedback Streams. For example, example.com might use fbl-aol@fbl.example.com to accept its AOL Feedback Loop, allowing it to delegate the whole of @fbl.example.com to a Feedback Loop handling appliance or service, should the need arise.
組織は、おそらく将来的にはかなりスケールアップまたはサードパーティのフィードバック消費者へのフィードバックループ処理をアウトソーシングを検討する可能性がある場合は、フィードバックストリームを処理するためのサブドメインを作成するために、さらに良いかもしれません。たとえば、example.comは、それがアプライアンスまたはサービスを扱うフィードバックループに@ fbl.example.comの全体を委任することができ、そのAOLのフィードバックループを受け入れるためにfbl-aol@fbl.example.comを使用する場合があり、必要が生じれば。
Small Feedback Consumers, with lists of no more than a few thousand Recipients, or small ISPs with no particular history of problems, should be able to handle feedback reports with little or no automation, as an ARF message should be readable in most mail clients. It may be worthwhile to add some very lightweight processing to the inbound Feedback Messages to make them easier to triage from other email client. For example, arffilter.c [Wise] can annotate the Subject line of inbound Feedback Messages with the IP address being reported, making it easier to see patterns of problems by sorting the messages by Subject line in the mail client. To identify which Recipient is causing the feedback to be sent, small Feedback Consumers should add some of the automation mentioned below that is intended for larger Feedback Consumers.
ARFメッセージは、ほとんどのメールクライアントで読めるべきであるとして問題の無い特定の歴史を持つ数千の受信者、または小規模のISPを超えないのリストを持つ小さなフィードバック消費者は、、ほとんど、あるいは全く自動化フィードバック・レポートを処理することができるはずです。他の電子メールクライアントからのトリアージにそれらを容易にするために、インバウンドフィードバックメッセージにいくつかの非常に軽量な処理を追加する価値があるかもしれません。例えば、arffilter.c [ワイズ]は、それが簡単にメールクライアントで件名でメッセージをソートすることにより、問題のパターンを確認するために行う、と報告されているIPアドレスとのインバウンドフィードバックメッセージの件名行に注釈を付けることができます。フィードバックを送信する原因となっている受信者を識別するために、小さなフィードバック消費者は、後述の自動化の一部を追加する必要があり、より大きなフィードバック消費者のために意図されています。
Larger Feedback Consumers need to be able to automate the handling of Feedback, as it scales beyond the ability of someone to manage manually quite quickly. The main capability a Feedback Loop processor needs is to extract some relevant data from the report, reliably. The most important bits of data tend to be the following:
それは非常に迅速に手動で管理するために誰かの能力を超えて拡大縮小などのより大きなフィードバック消費者は、フィードバックの取り扱いを自動化できるようにする必要があります。フィードバックループプロセッサが必要と主な機能は、確実に、レポートからいくつかの関連データを抽出することです。データの最も重要なビットは、次のことをする傾向があります。
o The Recipient of the original email
元の電子メールの受信者O
o The Mailbox Provider originating sending the Feedback Message (some Feedback Providers operate on behalf of multiple Mailbox Providers)
フィードバックメッセージを送信元のメールボックスのプロバイダO（いくつかのフィードバック・プロバイダは、複数のメールボックスプロバイダに代わって動作）
o The customer who sent the original email (in the case of an ESP or Mailbox Provider)
（ESPまたはメールボックスプロバイダの場合）元の電子メールを送った顧客O
o The campaign and Mailing List that the original email belonged to, if any
もしあれば、元の電子メールが、所属というキャンペーンやメーリングリストO
o (Possibly) the IP address from which the original email was sent and any [DKIM] signature domain
O（おそらく）元のEメールが送信されたIPアドレスと任意[DKIM]署名ドメイン
The last isn't vital, but may be a useful piece of data in diagnosing delivery problems.
最後は不可欠ではなく、配信の問題を診断するには、データの有効な部分かもしれません。
It can be very difficult to extract some of this data without some upfront work before email is sent. Some Feedback Providers will redact the Email Address in the To: header or Recipient Email Addresses anywhere within the message. Some will delete any identifying information they can. It may be possible to identify the End User based on the Message-ID, Subject line, and Received header timestamps, if there is access to the mail server logs, but at best it is painful and time-consuming, and only worth doing in an exceptional case.
電子メールが送信される前に、いくつかの先行作業をせずに、このデータの一部を抽出することは非常に困難です。どこにでもメッセージ内のヘッダまたは受信者の電子メールアドレス：いくつかのフィードバック・プロバイダは、にメールアドレスを墨消します。いくつかは、彼らができる任意の識別情報を削除します。メールサーバのログへのアクセスがある場合には、メッセージID、件名、およびReceivedヘッダのタイムスタンプに基づいてエンドユーザーを識別することが可能かもしれないが、最高の状態で、それは苦痛と時間がかかり、および中やって唯一の価値があります例外的なケース。
The solution is similar to the one used for automated bounce handling using VERP -- embed the information in the email in a way that it is unlikely to be removed by Feedback Providers but is easy to recognize in the email. That information may already be there in a form such as VERP if the Return-Path header is included in the embedded email, or included in one-click unsubscribe links included in the body of the email. If it is not already there, a good place to add the information is in the local part of the Message-ID as that is often used to track the progress of email through delivery. It is often available from log files as well as in the headers of the original message included in the Feedback Message.
解決策は、VERPを使用して処理する自動化されたバウンスのために使用されているものと同様である - フィードバック・プロバイダによって除去される可能性は低いですが、メールに認識しやすいような方法で、電子メールで情報を埋め込みます。リターンパスヘッダを埋め込み、電子メールに含まれる、または電子メールの本文に含まれる解除リンクをワンクリックに含まれていれば、その情報はすでにVERPなどの形態であってもよいです。それがまだない場合はそれは多くの場合、配信を通じて電子メールの進捗状況を追跡するために使用されるよう、情報を追加するのに適した場所は、Message-IDのローカル部分です。これは、ログファイルからだけでなく、フィードバックメッセージに含まれる元のメッセージのヘッダーにしばしば利用可能です。
There are several good ways to store the mapping between Recipients and identifiers in mail. For a database-backed ESP or bulk sender, a synthesized database primary key can be used. It is very small, and very opaque, and it is not expensive to retrieve the associated data from the main database -- but it is impossible to read by hand. Therefore, it needs automation with access to the core database to map the key onto the actual data.
メールの受信者と識別子の間のマッピングを保存するには、いくつか良い方法があります。データベースバックアップESPまたはバルク送信者のために、合成されたデータベースの主キーを使用することができます。それは非常に小さく、かつ非常に不透明であり、メインのデータベースから関連するデータを取得するために高価ではありません - 手で読み取ることは不可能です。したがって、実際のデータへのキーをマップするために、コア・データベースへのアクセスを自動化する必要があります。
Recording the required information directly within the email but encrypting it with strong or weak encryption removes the need for database access to extract the data. However, it still does need some automation.
メール内で直接必要な情報を記録したが、強いか、弱い暗号で暗号化してデータを抽出するために、データベース・アクセスの必要性を取り除きます。しかし、それはまだいくつかの自動化を必要としません。
A hybrid approach with the various bits of data stored separately but having some pieces either encrypted or obfuscated is possible by just including a database ID. This can provide a good compromise where most of the data is not immediately obvious to third parties but patterns in it can be recognized by eye. For example, a Message-ID of "esp-423-27-42460@example.com" is opaque to a third party, but someone familiar with the format can tell that it is a Message-ID added by the system. In this case it starts with "esp" followed by three numbers separated by dashes, meaning it is from customer 423, campaign 27, and the Recipient has the database key 42460. Even decoding this manually, while it may not be possible to identify customer number 423, it is easy to recognize that 10 Feedback Messages in a row relate to the same customer. From experience, it is not unusual for the vast majority of reports at an ESP to be about a very small number of customers, and one learns their customer IDs very quickly.
データの様々なビットを有するハイブリッドアプローチが別々に格納されているが、暗号化又は難読化のいずれかのいくつかの部分を有するだけで、データベースのIDを含むことによって可能です。これは、それが目で認識できるデータのほとんどは第三者が、パターンにすぐに明らかにされていません良好な妥協を提供することができます。たとえば、「esp-423-27-42460@example.com」のメッセージIDは、第三者に不透明であるが、形式に精通誰かがそれがシステムによって追加のMessage-IDであることを伝えることができます。この場合、それは、顧客423、キャンペーン27からある意味、「ESP」ダッシュで区切られた3つの数字が続くで始まり、そして受信者は、顧客を識別することは可能でないかもしれないが42460.があっても、手動でこれを復号鍵データベースを有します番号423は、行の10件のフィードバックメッセージが同じ顧客に関連することを認識することは容易です。経験から、それは顧客の非常に少数の程度とESPでの報告の大半のために珍しいことではありません、そして一つは非常に迅速に顧客IDを学習します。
Once a Message Originator embeds Recipient identifiers in an easily recognizable format in all its mail, it is quite easy for a Feedback Message processor to extract that with a conventional expression match and possibly a couple of database queries. It can then suppress that Email Address and record the customer and campaign for future reporting. In the case where the Feedback Messages are recorded in a ticketing system, it can also annotate the tickets with that data (again, for reporting and trending analysis).
メッセージ発信元はすべてのメールに容易に認識可能な形式で受信者識別子を埋め込むと、従来式の一致およびおそらくデータベースクエリのカップルとそれを抽出するフィードバック・メッセージ処理のための非常に簡単です。それは、そのメールアドレスを抑制し、今後のレポート作成のための顧客とのキャンペーンを記録することができます。フィードバックメッセージがチケットシステムに記録されている場合、それはまた、（レポートおよび傾向分析のために、再び）そのデータをチケットに注釈を付けることができます。
A Feedback Message processor is often bolted onto the side of an already complex bulk mail generator, making it difficult to reliably suppress mail to the Recipient. If the delivery data is stored in a way that makes it easy to convert into the same format as the VERP string used for bounce processing then the Feedback processor can create a "fake" hard bounce and send it to the existing bounce processor, suppressing mail to that address.
フィードバックメッセージプロセッサは、多くの場合、それが困難確実に受信者にメールを抑制すること、すでに複雑なバルクメール発電機の側にボルトで固定されています。配信データは、バウンス処理に使用VERP文字列と同じ形式に変換することを容易にする方法で格納されている場合、フィードバック・プロセッサは、「偽」のハードバウンスを作成し、メールを抑え、既存のバウンスプロセッサに送信することができますそのアドレスへ。
Mailbox Providers and Access Providers also need to automate Feedback processing. They are usually less interested in the details about the message and more interested in the IP address and which customer sent it. In most cases, the IP address can be extracted easily from ARF metadata; whereas, in other cases, it may need to be extracted from the Received headers embedded in the included original message. That data can then be used both for automated forwarding of Feedback Messages to the originating customer, if the ISP feels that is appropriate, and also for reporting on complaint levels across the ISP's customer base.
メールボックスのプロバイダとアクセスプロバイダはまた、フィードバック処理を自動化する必要があります。彼らは通常、メッセージの詳細にはあまり興味があり、IPアドレスで、より興味を持って、どの顧客がそれを送りました。ほとんどの場合、IPアドレスは、ARFメタデータから容易に抽出することができます。一方、他の場合には、それが含まれる元のメッセージに埋め込まれた受信ヘッダから抽出される必要があるかもしれません。 ISPは、ISPの顧客基盤全体に苦情レベルに報告するためにも、それが適切であると感じ、そして場合そのデータは、その後、元の顧客に、両方のフィードバックメッセージの自動化された転送のために使用することができます。
Whether you are acting as a Mailbox Provider or a Feedback Consumer, Complaint Feedback processing can be complex and scary -- or, with some intelligence and automation, simple and easy. In either case, it is an important and necessary tool for detecting messaging abuse and ensuring End User satisfaction.
または、いくつかのインテリジェンスと自動化で、シンプルで使いやすい - あなたがメールボックスプロバイダまたはフィードバック消費者として機能しているかどうかは、苦情のフィードバック処理が複雑で怖いことができます。いずれの場合も、メッセージの不正使用を検出し、エンドユーザーの満足度を確保するための重要かつ必要なツールです。
MAAWG encourages all Mailbox Providers to offer Feedback of whatever form is appropriate for their local user base and legal framework, and it encourages all Senders of email to consume and act upon any Feedback available. An actively maintained list of known Feedback Loops can be found at [Wise].
MAAWGは、ローカルユーザーベースと法的枠組みに適切であり、それが消費し、利用可能な任意のフィードバックに基づいて行動するために、電子メールのすべての送信者を励ますどんな形のフィードバックを提供するために、すべてのメールボックスプロバイダを奨励しています。知られているフィードバックループの積極維持されるリストは、[ワイズ]で見つけることができます。
This document was written within the MAAWG Collaboration Committee. The project was led by John Feaver and Kate Nowrouzi. The primary authors were Steve Atkins, Christine Murphy Borgia, J.D. Falk, John Feaver, Todd Herr, John Levine, Heather Lord, Kate Nowrouzi, and Suresh Ramasubramanian.
この文書は、MAAWGコラボレーション委員会の中に書かれていました。このプロジェクトは、ジョン・フィーバーとケイトNowrouziによって導かれました。主な著者はスティーブ・アトキンズ、クリスティン・マーフィーボルジア、J.D.フォーク、ジョン・フェバー、トッド君、ジョン・レヴァイン、ヘザー主よ、ケイトNowrouzi、およびスレシュRamasubramanianました。
The document was edited by John Levine, J.D. Falk, and Linda Marcus. Further editing and formatting required for this version to be published by the IETF was performed by J.D. Falk, with advice from Barry Leiba and Murray Kucherawy.
文書はジョン・レヴァイン、J.D.フォーク、そしてリンダ・マーカスが編集しました。 IETFによって公開されるこのバージョンのために必要なさらなる編集および書式設定はバリー・レイバとマレーKucherawyからのアドバイスで、J.D.フォークによって行われました。
[MAAWG] is the largest global industry association working against Spam, viruses, denial-of-service attacks, and other online exploitation. Its members include ISPs, network and mobile operators, key technology providers, and volume sender organizations. It represents over one billion mailboxes worldwide, and its membership contributed their expertise in developing this description of current Feedback Loop practices.
[MAAWG]スパム、ウイルス、サービス拒否攻撃、およびその他のオンライン搾取不利に働い世界最大の業界団体です。そのメンバーは、ISPのネットワークとモバイル通信事業者、キーテクノロジー・プロバイダー、およびボリュームの送信者団体が含まれます。これは、全世界で10億以上のメールボックスを表しており、その会員数は現在のフィードバックループ慣行のこの記述の開発に彼らの専門知識を貢献しました。
Security and privacy considerations are discussed in many sections of this document, most notably Sections 1, 3.4, and 3.5.
セキュリティとプライバシーの考慮事項は、この文書の多くのセクションで説明されている最も顕著なセクション1、3.4、および3.5。
[DKIM] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011.
[DKIM]クロッカー、D.、ハンセン、T.、およびM. Kucherawy、 "ドメインキーを識別メール（DKIM）署名"、RFC 6376、2011年9月。
[DNS] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[DNS] Mockapetris、P.、 "ドメイン名 - 概念と施設"、STD 13、RFC 1034、1987年11月。
[DomainKeys] Delany, M., "Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, May 2007.
[DomainKeysの]デラニー、M.、 "DNS（ドメインキー）で公開鍵アドバタイズを使用したドメインベースの電子メール認証"、RFC 4870、2007年5月。
[MAAWG] Messaging Anit-Abuse Working Group, <http://www.maawg.org/>.
[MAAWG]メッセージングANIT-虐待作業部会、<http://www.maawg.org/>。
[MAAWG-BCP] MAAWG, "MAAWG Sender Best Communications Practices Executive Summary and MAAWG Sender Best Communications Practices Version 2.0a-Updated", September 2011, <http://www.maawg.org/sites/maawg/files/news/ MAAWG_Senders_BCP_Ver2.pdf>.
[MAAWG-BCP] MAAWG、 "MAAWG送信者ベストプラクティスコミュニケーションズエグゼクティブサマリーとMAAWG送信者ベストプラクティス・コミュニケーションズバージョン2.0A-更新"、2011年9月、<http://www.maawg.org/sites/maawg/files/news/ MAAWG_Senders_BCP_Ver2.pdf>。
[MARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, August 2010.
[MARF] Shafranovich、Y.、レヴァイン、J.、およびM. Kucherawy、 "電子メールのフィードバックレポートの拡張フォーマット"、RFC 5965、2010年8月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 5322、2008年10月。
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[RFC5598]クロッカー、D.、 "インターネットメールのアーキテクチャ"、RFC 5598、2009年7月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP] Klensin、J.、 "簡易メール転送プロトコル"、RFC 5321、2008年10月。
[Trust] Crocker, D., Ed., "Trust in Email Begins with Authentication", Issued by the Messaging Anti-Abuse Working Group (MAAWG), June 2008, <http://www.maawg.org/sites/maawg/files/news/ MAAWG_Email_Authentication_Paper_2008-07.pdf>.
[トラスト]クロッカー、D.、エドは、「電子メールへの信頼は、認証で始まる」、メッセージング濫用防止ワーキンググループ（MAAWG）、2008年6月、<http://www.maawg.org/sites/maawg発行/ファイル/ニュース/ MAAWG_Email_Authentication_Paper_2008-07.pdf>。
[VERP] Wikipedia, "Variable Envelope Return Path", <https://secure.wikimedia.org/wikipedia/en/wiki/ Variable_envelope_return_path>.
[VERP]ウィキペディア、 "可変エンベロープリターンパス"、<https://secure.wikimedia.org/wikipedia/en/wiki/ Variable_envelope_return_path>。
[Wise] "arffilter - rewrite ARF reports", <http://wordtothewise.com/products/arffilter.html>.
[ワイズ] "arffilter - ARFレポートを書き換える"、<http://wordtothewise.com/products/arffilter.html>。
Appendix A. Abuse Reporting Format (ARF)
付録A.乱用報告様式（ARF）
A.1. A Brief History
A.1。簡単な歴史
The approach used by the first Feedback Loop to be deployed -- the "scomp" system at AOL -- was to send an entire copy of the message to the consumer of the Feedback Loop. It expected that large Feedback Consumers would embed sufficient information in the email so they could identify which Message Recipient had complained.
AOLの「SCOMP」システム - - 展開される第1のフィードバックループによって使用されるアプローチは、フィードバックループの消費者へのメッセージの全体のコピーを送信することでした。それは彼らが訴えていたそのメッセージの受信者を識別できるように大きなフィードバック消費者は電子メールで、十分な情報を埋め込むことが期待しました。
That worked well enough when there was only a single entity providing feedback, but as other Mailbox Providers started to offer Feedback, it became clear that it would be useful for the Feedback Provider to be able to add some additional information, both machine readable and human readable, to the report. This led to ARF, the Abuse Reporting Format, which quickly became the de facto standard for Feedback Messages.
フィードバックを提供する唯一の単一のエンティティがあった場合には十分に働いていたが、他のメールボックスプロバイダは、フィードバックを提供し始めたとして、両方のマシンが読めると人間、フィードバックプロバイダは、いくつかの追加情報を追加できるようにすることが有用であろうことが明らかになりました報告書に、読みやすいです。これはすぐにフィードバックメッセージのデファクトスタンダードになったARF、虐待の報告フォーマット、につながりました。
Today, ARF is used by nearly all Feedback Providers, both within MAAWG and without, constituting the vast majority of all Feedback Messages generated worldwide. ARF is recognized by all MAAWG members that have developed software or services that consume and process Feedback Messages. There are no competing standards for reporting individual messages.
今日では、ARFは、世界的に生成されたすべてのフィードバックメッセージの大半を構成する、MAAWG内となしの両方、ほぼすべてのフィードバック・プロバイダによって使用されます。 ARFは、すべての消費ソフトウェアやサービスを開発しましたMAAWGメンバーとプロセスフィードバックメッセージによって認識されています。個々のメッセージを報告するための競合規格ではありません。
ARF has now been published by the IETF as RFC 5965 [MARF].
ARFは現在、RFC 5965 [MARF]としてIETFによって公開されています。
A.2. Structure of an ARF Message
A.2。 ARFメッセージの構造
An ARF report (Feedback Message) is sent by email, with one message sent for each Spam report made. It consists of three sections, in a standard [MIME] message format called multipart/report.
ARFレポート（フィードバックメッセージ）が行われた各スパムレポートのために送られた一つのメッセージで、電子メールで送信されます。これは、マルチパート/レポートと呼ばれる標準[MIME]メッセージフォーマットでは、3つのセクションから構成されています。
The first section contains human-readable plaintext, primarily for the benefit of small Feedback Consumers who are handling reports manually. It typically contains boilerplate text explaining that this is a Feedback Message and providing URLs to other data such as contact information for the Feedback Provider or Mailbox Provider that originated the Feedback Message.
最初のセクションでは、主にレポートを手動で扱っている小さなフィードバック消費者の利益のために、人間が読める平文が含まれています。それは、典型的には、定型テキストが、これはフィードバックメッセージであることを説明すると、このようなフィードバックメッセージを発信したフィードバックプロバイダまたはメールボックスプロバイダの連絡先情報などの他のデータへのURLを提供するが含まれています。
The second section contains some machine-readable information, including the version of the ARF protocol used and the type of report it is ("abuse," "fraud," or other label). It also might include some optional information about the email being reported, such as the original Envelope Sender or the time the mail was received. In theory, the information in this section can be used to mechanically route and triage the report, though in current practice most Feedback
2番目のセクションでは、使用ARFプロトコルのバージョンと、それがあるレポートの種類（「虐待」、「詐欺」、または他の標識）を含むいくつかの機械読み取り可能な情報が含まれています。また、このようなオリジナルのエンベロープ送信者やメールを受信した時のように報告された電子メールについてのいくつかのオプション情報を、含まれる場合があります。理論的には、このセクションの情報は、経路および現在の実務慣行ほとんどのフィードバックにかかわらず、報告書を、トリアージを機械的に使用することができます
Messages are treated identically. As a result, this section is often ignored entirely by Feedback Consumers who prefer to process the third section themselves.
メッセージは同様に処理されています。その結果、このセクションには、多くの場合、3番目のセクションそのものを処理することを好むフィードバック消費者によって完全に無視されます。
The third section of the report consists of a copy of the original email that the report is about, as a standard [MIME] message/rfc822 attachment. While ideally this would be an unmodified copy of the original email, it is likely that many producers of reports will modify or "redact" some elements of the report, especially the Email Address of the Recipient, due to privacy or other legal concerns.
レポートの第3のセクションは、レポートが標準の[MIME]メッセージ/ RFC822の添付ファイルとして、周りにある元の電子メールのコピーから成ります。理想的には、これは元の電子メールの無修正コピーだろうが、レポートの多くの生産者が変更またはプライバシーやその他の法的懸念による報告書のいくつかの要素、受信者の特に電子メールアドレスを、「墨消し」する可能性があります。
The strict technical specifications of ARF, as well as some example reports and tools to handle the format, can be found at <http://mipassoc.org/arf/>, [Wise], and in [MARF]
ARFの厳格な技術仕様、ならびにフォーマットを処理するためにいくつかの例のレポートおよびツールは、<http://mipassoc.org/arf/>で、[ワイズ]、および[MARF]に見出すことができます
Appendix B. Using DKIM to Route Feedback
ルートフィードバックにDKIMを使用して、付録B.
Historically, the IP address of the "last hop" -- the MTA that transferred a message into the receiving Mailbox Provider's administrative domain -- was the sole reliable identifier used to denote the source of a message. With the emergence of authentication technologies such as [DKIM], another identifier can now be used; specifically, the authenticated domain associated with a message. This domain is the "d=" value in a DKIM-Signature header field.
歴史的に、「最後のホップ」のIPアドレス - 受信メールボックスプロバイダの管理ドメインにメッセージを転送したMTAは - メッセージの送信元を示すために使用唯一の信頼できる識別子でした。このような[DKIM]などの認証技術の出現により、別の識別子は、現在使用することができます。具体的には、認証されたドメインは、メッセージに関連付けられています。このドメインは、DKIM-Signatureヘッダーフィールドに「D =」値です。
In a social or policy context, applying a DKIM signature to a message is tantamount to stating, "I take responsibility for this message". The DKIM signature is most often applied by the author or originator of a message, which may be far upstream of the "last hop" MTA. This is true particularly in cases where the originator's intended Recipient Email Address is configured to forward to another Recipient Email Address. Stories of users who have strung together multiple forwarding accounts are not uncommon, and these users are unable to complain effectively about Spam because their Mailbox Providers cannot easily or reliably follow the path of a message back to the initial originator.
社会的あるいは政策文脈では、メッセージにDKIM署名を適用すると、「私は、このメッセージのために責任を取る」、述べることに等しいです。 DKIM署名は、ほとんどの場合、「最終ホップ」MTAのはるか上流にあってもよいメッセージの作成者または発信者によって適用されます。これは特に、発信者の意図した受信者のメールアドレスが他の受信者のメールアドレスに転送するように設定されている場合に真です。一緒に複数の転送アカウントを張られているユーザーの物語は珍しいことではない、と自分のメールボックスのプロバイダは簡単または確実に戻って最初の発信元にメッセージの道を歩むことができないため、これらのユーザーが迷惑メールについて効果的に訴えることができません。
A single DKIM "d=" value may be used across multiple servers with multiple IP addresses. Servers may be added or removed at any time without changing the dynamics of the DKIM signature. When a Feedback Loop is based on the IP address, the Feedback Consumer must contact the Feedback Provider to change its subscription options every time an IP address needs to be added or removed. However, when a Feedback Loop uses DKIM, no reconfiguration is necessary because the signing domain does not change.
シングルDKIM「D =」値は、複数のIPアドレスを持つ複数のサーバに使用することができます。サーバーは、DKIM署名のダイナミクスを変えることなく、いつでも追加または削除してもよいです。フィードバックループは、IPアドレスに基づいている場合、フィードバック消費者は、IPアドレスを追加または削除する必要のあるたびに、そのサブスクリプションオプションを変更するためにフィードバックプロバイダに連絡する必要があります。フィードバックループは、DKIMを使用する際に署名ドメインが変化しないためしかし、再設定は不要です。
One recurring concern with DKIM, however, is that ESPs often send messages addressed with hundreds or thousands of customer domains, yet they want to receive Feedback Messages for all of these domains. This was particularly difficult with [DomainKeys] (the predecessor to DKIM), which tied the "d=" to the "From" header field. DKIM removed this tie, so it is simple for an ESP to use a domain of its own to sign the message and sign up for Feedback regarding all messages signed with that domain. Such a signature may be in addition to, or instead of, signatures from the various client domains. While there are still many unknowns related to reputation (which will be addressed in a future MAAWG document), this is clearly an appropriate use of DKIM to take responsibility (and receive Feedback) for a message.
DKIMの一つの定期的な懸念は、しかし、ESPのは、多くの場合、メッセージを送信することで、顧客のドメインの数百または数千に対処し、まだ彼らはこれらのドメインのすべてのためのフィードバックメッセージを受信したいです。これは、「差出人」ヘッダフィールドに「= D」結ば（DKIMの前身）、[ドメインキー]と特に困難でした。 DKIMは、このネクタイを削除するので、ESPは、メッセージに署名し、そのドメインで署名されたすべてのメッセージに関するフィードバックにサインアップするために、独自のドメインを使用することは簡単です。そのような署名は、に加えて、または代わりに、様々なクライアントドメインから署名することができます。 （将来MAAWG文書で解決される予定）の評判に関連する多くの未知数はまだありますが、これは明らかにメッセージの責任を取る（とフィードバックを受信）するDKIMの適切な使用です。
Appendix C. Unsolicited Feedback
付録C.迷惑フィードバック
Is it always necessary for a Feedback Consumer to apply for a Feedback Loop or is it permissible for a Feedback Provider to configure a Feedback Loop for a Feedback Consumer without an explicit request? There is continuing debate about whether this is an acceptable practice, and MAAWG is neither endorsing nor condemning such activity at this time.
フィードバックプロバイダが明示的な要求なしにフィードバック消費者のためのフィードバックループを構成するためのフィードバック消費者のフィードバックループを申請するか、それが許されていることが常に必要ですか？これは許容練習で、MAAWGは支持しないでも、この時点で、このような活動を非難もされていないかどうかについて引き続き議論があります。
That said, if a Feedback Provider chooses to send Feedback without being asked first, certain guidelines should be followed. In general, it should make prudent decisions to minimize the negative impact on Mailbox Providers and Access Providers.
これは、フィードバックプロバイダが最初に聞かれることなく、フィードバックを送信することを選択した場合、特定のガイドラインに従うべきである、と述べました。一般的には、メールボックスのプロバイダとアクセス・プロバイダへの悪影響を最小限に抑えるために賢明な意思決定を行う必要があります。
C.1. Guidelines
C.1。ガイドライン
This should only be done for Mailbox and Access Providers.
これは、メールボックスおよびアクセスプロバイダーのために行われるべきです。
This should only be done after attempting to contact the provider to ask if it is possible to set up a Feedback Loop via the normal practice.
これは、通常の練習を経てフィードバックループを設定することが可能であるかどうか尋ねるためにプロバイダに連絡しようとした後に行うべきです。
These Feedback Loops should only be set up to send to the published abuse address from the provider's WHOIS record.
これらのフィードバックループは、プロバイダのWHOISレコードから発表され虐待アドレスに送信するように設定する必要があります。
C.2. Pros
C.2。賛否
Feedback Consumers may not realize they have abuse problems until they begin receiving the spam complaints.
フィードバック消費者は、スパムの苦情を受け始めるまで、彼らは虐待の問題を持って実現しないかもしれません。
Feedback Consumers may not be aware of Feedback Loops and may appreciate the additional data feed.
フィードバック消費者はフィードバックループを認識できない場合があり、追加のデータフィードを理解し得ます。
Upstream providers have an additional information stream to help them identify problem customers.
上流プロバイダは、彼らが問題のある顧客を識別するのに役立つ追加情報ストリームを持っています。
Spam coming from a network is abuse; therefore it is appropriate to send reports of the abuse back to the Mailbox Provider or Access Provider. Setting up a Feedback Loop automates the process.
ネットワークからのスパムは虐待です。したがって、戻ってメールボックスプロバイダまたはアクセスプロバイダへの虐待の報告を送信することが適切です。フィードバックを設定するループは、プロセスを自動化します。
C.3. Cons
C.3。短所
It creates confusion for Feedback Consumers if they did not apply and do not understand why they are suddenly receiving complaints.
彼らは適用されませんでしたし、彼らは突然の苦情を受けている理由を理解していない場合には、フィードバックの消費者のために混乱を作成します。
It can conflict with existing Terms of Service because a new feed of information is available. For example, if a provider has a policy to terminate service after a certain number of abuse complaints, and it starts receiving unexpected Feedback Loop complaints, it may either be forced to terminate customers that did not have a previous issue or be required to update its Terms of Service and Acceptable Use Policy agreements.
情報の新しいフィードが利用可能であるので、それはサービスの既存の規約と競合することができます。プロバイダは虐待の苦情の特定の番号の後にサービスを終了する方針を持っており、それは予想外のフィードバックループの苦情を受けて開始した場合、どちらかの以前の問題を持っていなかったか、その更新に必要なことが、顧客を終了することを強制することができますサービスと利用規定契約の利用規約。
Upstream providers do not have access to the mail being sent by their customers, so they cannot tell whether bulk mail complaints constitute a problem.
上流プロバイダは、顧客によって送信されたメールへのアクセス権を持っていないので、彼らは、バルクメールの苦情が問題となるかどうかわかりません。
The listed abuse address may not be the correct place for automated spam complaints to be sent.
記載されている虐待のアドレスが送信される自動化されたスパムの苦情のための正しい場所ではないかもしれません。
The listed abuse address may feed into a ticketing system that is not capable of correctly handling ARF messages.
記載されている虐待アドレスが正しくARFのメッセージを処理できないチケッティングシステムに供給することができます。
Feedback Consumers may not be equipped to handle the volume or format of complaints without some warning and preparation.
フィードバック消費者は、いくつかの警告と準備することなく、苦情のボリュームやフォーマットを処理するために装備することはできません。
Author's Address
著者のアドレス
J.D. Falk (editor) Messaging Anti-Abuse Working Group Presidio of San Francisco P.O. Box 29920 572 B Ruger Street San Francisco, CA 94129-0920 US
J.D.フォーク（編集者）、サンフランシスコの私書箱のメッセージングアンチ虐待ワーキンググループプレシディオ29920 572 Bルガー・ストリート、サンフランシスコ、CA 94129-0920米国箱
EMail: ietf@cybernothing.org URI: http://www.maawg.org/
電子メール：ietf@cybernothing.org URI：http://www.maawg.org/