[要約] RFC 6449は、クレームフィードバックループ（CFL）の運用に関する推奨事項を提供しています。このRFCの目的は、CFLの効果的な運用を促進し、スパムや不正行為の対策を強化することです。
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とは別の貿易組織であるメッセージング反虐待ワーキンググループ内の協力的な努力の結果です。このドキュメントが基づいている元のMAAWG文書は、2010年4月に公開されました。このドキュメントは、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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
フィードバックメッセージが認可されたフィードバック消費者にのみ送信されることを保証することがフィードバックプロバイダーの責任であり、各メッセージ送信者のIDは、SMTPセッションの接続IPアドレスまたはメッセージのドメインキー識別された署名ドメインから一般的に決定されます。偽造が難しいです。これは重要です。これは、スパマーやその他の悪党者が、電子メールアドレスやその他の個人情報や企業情報を盗もうとして、自分に属さないネットワークでフィードバックループを申請しようとする可能性があるため重要です。
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].
o 乱用レポート形式 - 付録Aおよび[MARF]で定義されているフィードバックメッセージの標準形式。
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".
o ARF-「乱用報告書」を参照してください。
o ARF Report -- See "Feedback Message".
o ARFレポート - 「フィードバックメッセージ」を参照してください。
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 Envelope Sender-メッセージの転送中に[SMTP]「メール」コマンドへの引数として含まれるメールアドレス。
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 電子メールアドレス-Form 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]会話の「データ」部分）は、ヘッダーとボディの2つの部分で構成されています。「全身」は、単に修正や切り捨てなしで、メッセージの本体全体です。画像またはその他のいわゆる「アタッチメント」は、実際には[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]会話の「データ」部分）は、ヘッダーとボディの2つの部分で構成されています。ヘッダーには複数のヘッダーフィールドが含まれており、それぞれが「ヘッダー名：ヘッダーコンテンツ」としてフォーマットされています。ほとんどのメールユーザーエージェント（MUAS）は、基本的な4つのヘッダーフィールド（、、、、日付、および件名）のみを示していますが、すべてのメッセージには、主に自動処理を支援することを目的とした診断情報またはデータを含む追加のヘッダーフィールドが含まれています。多くの場合、非公式に「フルヘッダー」と呼ばれます。これらのフィールドは[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ヘッダーフィールド - すべての電子メールメッセージに含まれる診断ヘッダーフィールドの1つ（上記の「フルヘッダーセクション」を参照）はメッセージ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].
o MIME -Multipurpose Internet Mail Extensionsとは、メッセージの本文に埋め込まれることを許可する一連の標準を指します。ファイルの添付ファイルやフォーマットまたは「リッチ」テキストなどの概念はすべて、[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 Return -Path-メッセージの封筒送信者を示すオプションのメッセージヘッダーフィールド（上記の「フルヘッダーセクション」を参照）。
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.
o Reverse DNS -DNS名のIPアドレスを返すよりユーザー可視クエリの逆であるため、「リバース」と呼ばれるIPアドレスの[DNS]名前。さらに、逆DNSクエリは、AレコードではなくPTRレコードを返します。
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 SPAM-このドキュメントの目的（およびほとんどの苦情フィードバックループ）のために、「SPAM」は、メッセージの著者や送信者の意図に関係なく、受信者が文句を言うことを選択するメッセージとして定義されます。
o Spam Complaint - See "Complaint" above.
o スパムの苦情 - 上記の「苦情」を参照してください。
o Spammer - An entity that knowingly, intentionally sends Spam messages (see "Spam" above).
o Spammer-意図的に、意図的にスパムメッセージを送信するエンティティ（上記の「スパム」を参照）。
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.
フィードバックループは、通常（常にではない）「Last Hop」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.
o 要求者が実際に関係するIPアドレスのフィードバックを受け取ることを許可されていることをクロスチェックします。
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.
o IPSがISP Smarthost Network、WebHosting Farm、電子メールマーケティングまたはメーリングリストサービス、またはその他のエンティティなど、他の情報を収集します。
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段階のプロセスであり、申請者がフォームに記入し、申請者のリクエストが入力される前に確認メールを受信して確認する必要があります（問題のドメインのabuse@またはpostmaster@に送られます）フィードバックプロバイダーが処理するキュー。
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.
フィードバックループのアプリケーションは、スタンドアロンのWebサイトで受け入れられるか、メールボックスプロバイダーのポストマスターサイトの一部になることができます。とにかく、苦情フィードバックループプログラムのWebサイトには、フィードバックループプログラムのFAQ、フィードバックループの利用規約、おそらく既存の登録を変更するための登録者の方法など、フィードバックループに固有の他のコンテンツを含める必要があります。。
The web site should also provide the Feedback Consumer with general information on how the feedback will be sent, including:
また、Webサイトは、フィードバック消費者に、以下を含むフィードバックの送信方法に関する一般的な情報を提供する必要があります。
o Report Format (ARF or otherwise)
o レポート形式（ARFまたはその他）
o Sending IP addresses and/or DKIM "d=" string
o IPアドレスの送信および/またはdkim "d ="文字列
o "From" Email Address
o 「From」メールアドレス
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.
一部のメーリングリストソフトウェアには、定期的な「プローブ」メールを購読したアドレスに送信して検証する組み込み機能があるように、フィードバックプロバイダーは、フィードバックメッセージを受信するアドレスに同様のメールを送信するツールを開発して、有効であることを確認する必要があります。。これは、登録承認ステップの一部として元々使用されていたAubsion@およびPostmaster@アドレスではないアドレスに特に当てはまります。時間が経つにつれて、人々は雇用主、または少なくとも役割を変更する可能性があり、IPに関連付けられている電子メールアドレスを検証することは、フィードバックプロバイダーがフィードバックメッセージがまだ受け入れられ、フィードバック消費者によって行動されていることを確認するための1つの方法です。
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.
1. Aubse@やPostmaster@などの「役割」のメールアドレス。フィードバックを申請する人は、これらのメールアドレスにアクセスできることを確認する必要があります。フィードバックプロバイダーは、多くの場合、それらのアカウントへの確認リンクを送信して、エンドユーザー、スパマー、または競合他社が許可されていないフィードバックにサインアップできないようにします。
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.
* 各IPの逆DNSは、申請者のメールアドレスまたはフィードバックメッセージを受信するメールアドレスのドメインを共有します。
* WHOIS information for the IPs requested is obviously associated with the domain name.
* 要求されたIPSの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.
フィードバックメッセージは、一般的にフィードバックループに関連付けられている主なメールです。受信者が「This Spam」ボタンにヒットするたびに、フィードバックループシステムは、元の電子メールのコピーが添付されたボイラープレートレポートを作成し、フィードバックループの消費者に送信します。
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
レポートカードの詳細は大きく異なる場合があります。フィードバックプロバイダーは、トラフィックレベルの定期的な概要と見られる苦情レートの定期的な要約を送信する場合があります。おそらく、ソースIPアドレスまたは他の識別子によって概要または破損している場合があります。時々、これらは、ある程度のメトリック（通常は苦情レート）が、メールボックスプロバイダーにフィードバック消費者に通知するレベルに達したときに送信される場合があります。もう一方の極端な場合、一部のレポートカードにはほとんど役に立ちません
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.
データのオリジネーターが苦情を引き起こしているという警告だけで、その電子メールが改善されない限りブロックされるという意味があります。
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:
フィードバックを送信するメールボックスプロバイダーは、フィードバック消費者がフィードバックメッセージを使用することを期待する方法に関するポリシーを公開している可能性があります。実際には、これは主に3つのことになります。
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アドレスが特定の日に引き起こすフィードバックメッセージの数を数えたい場合があります。特定の顧客またはサーバーから突然増加している場合、スパマーがサインアップしたか、システムが侵害されたことの兆候かもしれません。特定の顧客について高いレベルの苦情がある場合、その理由があるかどうかを確認することは調査する価値があるかもしれません。たとえば、1日に10個のフィードバックメッセージは、場合によっては深刻な問題の兆候ですが、月に300,000メールを送信するメッセージオリジネーターの完全に合理的な「背景」レベルである可能性があります。カウントが問題があることを示している場合、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
1つの問題は、フィードバックメッセージが苦情が送信された日にカウントされる傾向があることです。これは、元のメッセージが受信者によって読まれた日です。それはメッセージが送信されたのと同じ日ではないかもしれません。簡単な例は、メッセージの発信者が
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%.
月曜日から金曜日までの定期的に電子メールを送信すると、土曜日に高い苦情率が見られることがよくあります。週末に週の電子メールに追いつく人々から送られたフィードバックメッセージの絶対数はそれほど高くないかもしれません。ただし、土曜日に電子メールはほとんど送信されないため、かなり妥当な数の苦情は、非常に少数の総送信メール、さらにはゼロでさえ分割され、レポートエンジンが破損することになります。これは、疑わしいものからばかげたものまで、どこにでもあると思われる苦情率につながる可能性があります。その結果、週末に事実上静かな大規模なメーリングリストは、土曜日にその日に送信した電子メールよりも多くの苦情を受け、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.
考慮すべきもう1つの算術の問題は、受信トレイ、バルクフォルダー、および「これはスパム」ボタン間の相互作用です。組織が恐ろしい評判を持つ大量の電子メールを送信すると、受信トレイにある10,000のメールのうち500件とバルクフォルダーに残りの9,500が含まれる可能性があります。10個のフィードバックメッセージを取得し、送信した10,000メールで分割すると、非常に立派な0.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.
変化する傾向を逃すことへの評判）。フィードバック消費者がスケールアップする必要がある場合、フィードバックループ処理エンジンで既存のエイリアスを簡単に指すことができます。
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-aol@fbl.example.comを使用して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.
数千人以下の受信者のリスト、または特定の問題の履歴がない小さなISPのリストを持つ小さなフィードバック消費者は、ほとんどのメールメッセージがほとんどまたはまったく自動化されていないフィードバックレポートをほとんどまたはまったく処理できるはずです。インバウンドフィードバックメッセージに非常に軽量の処理を追加して、他のメールクライアントからのトリアージを容易にすることは価値があるかもしれません。たとえば、arffilter.c [wise]インバウンドフィードバックメッセージの件名に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)
o 元のメールを送信した顧客（ESPまたはメールボックスプロバイダーの場合）
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 （おそらく）元の電子メールが送信された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、件名、および受信ヘッダータイムスタンプに基づいてエンドユーザーを識別することが可能かもしれませんが、せいぜい痛みを伴い時間がかかり、しか行う価値があります例外的なケース。
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などの形式で既に存在する場合があります。まだ存在していない場合、情報を追加するのに適した場所は、配信を通じて電子メールの進捗を追跡するためによく使用されるため、メッセージ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
さまざまなデータのビットを個別に保存しているが、いくつかのピースを暗号化または難読化するハイブリッドアプローチは、データベースIDを含めるだけで可能です。これは、ほとんどのデータが第三者にとってすぐに明らかではないが、そのパターンが目で認識できる場合に良い妥協を提供することができます。たとえば、「ESP-423-27-42460@example.com」のメッセージIDはサードパーティに不透明ですが、この形式に精通している人は、システムによって追加されたメッセージIDであることがわかります。この場合、「ESP」から始まり、3つの数字がダッシュで区切られています。つまり、顧客423、キャンペーン27からであり、受信者はデータベースキー42460を持っています。
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.
これを手動で解読することは、顧客番号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 Stringと同じ形式に簡単に変換できるように保存されている場合、フィードバックプロセッサは「偽の」ハードバウンスを作成して既存のバウンスプロセッサに送信し、メールを抑制できます。そのアドレスに。
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は、すべてのメールボックスプロバイダーが、ローカルユーザーベースと法的フレームワークに適したフォームのフィードバックを提供することを奨励しており、すべての電子メールの送信者が利用可能なフィードバックを消費して行動することを奨励しています。既知のフィードバックループの積極的に維持されているリストは、[Wise]で見つけることができます。
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コラボレーション委員会内で書かれています。このプロジェクトは、ジョン・フィーバーとケイト・ノウルージが率いていました。主な著者は、スティーブ・アトキンス、クリスティン・マーフィー・ボルギア、J.D。フォーク、ジョン・フィーバー、トッド・ヘア、ジョン・レヴァイン、ヘザー・ロード、ケイト・ノウルジ、スレシュ・ラマスブラマニアンでした。
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によって公開されるために必要なさらなる編集とフォーマットは、Barry LeibaとMurray Kuchherawyからのアドバイスを含めてJ.D. Falkによって実行されました。
[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] Crocker、D.、Hansen、T。、およびM. Kucherawy、「Domainkeys Idified Mail（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] Delany、M。、「DNS（domainkeys）で宣伝されているパブリックキーを使用したドメインベースの電子メール認証」、RFC 4870、2007年5月。
[MAAWG] Messaging Anit-Abuse Working Group, <http://www.maawg.org/>.
[MAAWG]メッセージングAnit-Abuseワーキンググループ、<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 Sender Best Communications Practices Executive Summary and Maawg Sender Best Communications Practicesバージョン2.0A-Updated」、<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.、Levine、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] Freed、N。and N. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322] Resnick、P.、ed。、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[RFC5598] Crocker、D。、「インターネットメールアーキテクチャ」、RFC 5598、2009年7月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP] Klensin、J。、「Simple Mail Transfer Protocol」、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>.
[Trust] Crocker、D.、ed。、「電子メールの信頼は認証から始まる」、メッセージングAnti-Abuse Working Group（MAAWG）によって発行された、2008年6月、<http://www.maawg.org/sites/maawg/files/news/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] Wikipedia、「可変エンベロープリターンパス」、<https://secure.wikimedia.org/wikipedia/en/wiki/ variable_envelope_return_path>。
[Wise] "arffilter - rewrite ARF reports", <http://wordtothewise.com/products/arffilter.html>.
[wise] "arffilter -rite arfレポート"、<http://wordtothewise.com/products/arffilter.html>。
Appendix A. Abuse Reporting Format (ARF)
付録A. 乱用報告書（ARF）
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」システム - は、フィードバックループの消費者にメッセージのコピー全体を送信することでした。大規模なフィードバック消費者が電子メールに十分な情報を埋め込んで、どのメッセージ受信者が不満を言ったかを特定できることが期待されていました。
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は現在、IETFによってRFC 5965 [MARF]として公開されています。
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レポート（フィードバックメッセージ）は電子メールで送信され、スパムレポートごとに1つのメッセージが送信されます。MultiPart/Reportと呼ばれる標準[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/>、[wise]、および[marf]にあります。
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に対する繰り返しの懸念の1つは、ESPがしばしば数百または数千の顧客ドメインでアドレス指定されたメッセージを送信しますが、これらすべてのドメインに対してフィードバックメッセージを受信したいということです。これは、[dkimの前身）である[dkimの前身]で特に困難でした。Dkimはこのネクタイを削除したため、ESPが独自のドメインを使用してメッセージに署名し、そのドメインで署名されたすべてのメッセージに関するフィードバックにサインアップするのは簡単です。このような署名は、さまざまなクライアントドメインからの署名に加えて、またはその代わりに行われる場合があります。評判に関連する多くの未知数（将来のMAAWGドキュメントで対処されます）がまだありますが、これは明らかに、メッセージに対して責任を負う（およびフィードバックを受け取る）ためのDKIMの適切な使用です。
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.
とはいえ、フィードバックプロバイダーが最初に尋ねられずにフィードバックを送信することを選択した場合、特定のガイドラインに従う必要があります。一般に、メールボックスプロバイダーとアクセスプロバイダーへのマイナスの影響を最小限に抑えるために、賢明な決定を下す必要があります。
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レコードから公開された乱用アドレスに送信するためにのみ設定する必要があります。
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.
ネットワークから来るスパムは乱用です。したがって、乱用のレポートをメールボックスプロバイダーまたはアクセスプロバイダーに返信することが適切です。フィードバックループのセットアップにより、プロセスが自動化されます。
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.フォーク（編集者）メッセージ虐待反乱用作業グループサンフランシスコP.O.Box 29920 572 B Ruger Street San Francisco、CA 94129-0920 US
EMail: ietf@cybernothing.org
URI: http://www.maawg.org/