Internet Engineering Task Force (IETF) J. Falk, Ed.
Request for Comments: 6449 Messaging Anti-Abuse WG
Category: Informational November 2011
ISSN: 2070-1721
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.
类似于本文所述的投诉反馈循环已经存在了十多年，产生了许多事实上的标准和最佳实践。本文件旨在编纂并澄清这些反馈机制的提供者和消费者打算使用反馈的方式，描述一些已经很常见的行业实践。
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的共识；相反，它是以信息RFC的形式发布的，以使其广泛地提供给互联网社区，并简化IETF工作中对该材料的引用。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6449.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
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 ]
[ Feedback Consumer Database ]
|
V
[ User ] [ Mailbox ] [ Feedback ]
[ Reports ]--->[ Provider ]--SMTP-->[ Provider ]
[ Spam ] | |
V V [ Feedback ]
[Spam Filter Rules] [ ARF Message ]--SMTP-->[ Consumer ]
Figure 1
图1
When an End User of a Mailbox Provider issues a Spam Complaint, the Feedback Provider sends a report to the Feedback Consumer. This report may include the Full Body of the original email or (less commonly) only the full header of the original email. Some Feedback Providers will redact information deemed private, such as the Message Recipient's Email Address.
当邮箱提供商的最终用户发出垃圾邮件投诉时，反馈提供商将向反馈消费者发送报告。此报告可能包含原始电子邮件的全文，或者（不太常见）仅包含原始电子邮件的完整标题。一些反馈提供者将编辑被视为隐私的信息，如消息接收者的电子邮件地址。
Ensuring that Feedback Messages are only sent to authorized Feedback Consumers is the responsibility of the Feedback Provider, with the identity of each message Sender generally determined from the SMTP session's connecting IP address or a message's DomainKeys Identified Mail (DKIM) signature domain, both of which are hard to forge. This is important because Spammers and other miscreants may also attempt to apply for Feedback Loops on networks not belonging to them, in an attempt to steal Email Addresses and other private personal or corporate information.
确保反馈消息只发送给授权的反馈消费者是反馈提供者的责任，每个消息发送者的身份通常由SMTP会话的连接IP地址或消息的域密钥标识邮件（DKIM）签名域确定，两者都很难伪造。这一点很重要，因为垃圾邮件发送者和其他不法分子也可能试图在不属于他们的网络上申请反馈环路，试图窃取电子邮件地址和其他私人或公司信息。
It is the responsibility of the Feedback Consumer to identify the source and nature of the original message in the reports they receive and take any appropriate action. The Feedback Provider does not make any claims or judgments about the validity of the complaint, beyond whatever technical data the Feedback Provider has themselves included. Every complaint is forwarded to the Feedback Consumer without human review, without any additional application of filters; thus, some individual reports may prove not to be actionable.
反馈消费者有责任在其收到的报告中确定原始信息的来源和性质，并采取任何适当的措施。除反馈提供方自身包含的任何技术数据外，反馈提供方不对投诉的有效性做出任何声明或判断。每个投诉都会转发给反馈消费者，无需人工审核，无需额外应用过滤器；因此，一些个别报告可能被证明是不可采取行动的。
The Feedback Consumer and the Feedback Provider will each evaluate a Spam Complaint for validity and take whatever action deemed necessary from their own perspective and, in most cases, will not communicate with each other which actions were (or were not) taken. Similarly, it is rare for any party to communicate further with the End User who initiated the complaint.
反馈消费者和反馈提供者将各自评估垃圾邮件投诉的有效性，并从各自的角度采取任何必要的措施，在大多数情况下，不会相互沟通采取了（或未采取）哪些措施。同样，很少有任何一方与发起投诉的最终用户进一步沟通。
Wherever possible, these terms are derived from [RFC5598].
在可能的情况下，这些术语源自[RFC5598]。
o Abuse Reporting Format - The standard format for Feedback Messages, defined in Appendix A and [MARF].
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-域密钥识别邮件，在MAAWG电子邮件身份验证白皮书“电子邮件中的信任始于身份验证”[Trust]和[DKIM]中进一步描述。
o End User - A customer of a Mailbox Provider or Access Provider.
o 最终用户-邮箱提供程序或访问提供程序的客户。
o Envelope Sender - The Email Address included as the argument to the [SMTP] "MAIL" command during transfer of a message.
o 信封发件人-在传输邮件期间，作为[SMTP]“MAIL”命令参数包含的电子邮件地址。
o Email Address - A string of the form user@domain, where the domain (after the @ symbol) is used to determine where to transfer an email message so that it may be delivered to the mailbox specified by the username (before the @ symbol). The precise technical format of an Email Address is defined in [SMTP]. Email delivery can be a complex process and is not described further in this document.
o 电子邮件地址-表单的字符串user@domain，其中域（在@符号之后）用于确定在何处传输电子邮件，以便将其发送到用户名指定的邮箱（在@符号之前）。[SMTP]中定义了电子邮件地址的精确技术格式。电子邮件传递可能是一个复杂的过程，本文档将不作进一步描述。
o Email Service Provider (ESP) - A provider of email sending services; the ESP is often a Message Originator working on behalf of a Message Author. MAAWG uses the term "ESP" solely for this definition and does not refer to a Mailbox Provider for End Users as ESPs.
o 电子邮件服务提供商（ESP）-电子邮件发送服务提供商；ESP通常是代表消息作者工作的消息发起人。MAAWG仅在本定义中使用术语“ESP”，并未将终端用户的邮箱提供商称为ESP。
o FBL - The acronym "FBL" (Feedback Loop) is intentionally not used in this document.
o FBL-本文件中故意不使用首字母缩写“FBL”（反馈回路）。
o Feedback or Feedback Stream - A set (often a continuous stream) of Feedback Messages sent from a single Feedback Provider to a single Feedback Consumer.
o 反馈或反馈流-从单个反馈提供者发送到单个反馈消费者的一组反馈消息（通常为连续流）。
o Feedback Consumer - A Recipient of the Feedback Messages, almost always on behalf of or otherwise associated with the Message Originator. Often the Message Originator and Feedback Consumer are the same entity, but we describe them separately in this document because they are each responsible for different parts of the Complaint Feedback Loop process, as demonstrated in the flowchart in the Overview section.
o 反馈消费者-反馈消息的接收者，几乎总是代表消息发起人或以其他方式与消息发起人关联。信息发起人和反馈消费者通常是同一实体，但我们在本文档中分别对其进行了描述，因为他们各自负责投诉反馈循环流程的不同部分，如概述部分的流程图所示。
o Feedback Loop - See Complaint Feedback Loop.
o 反馈回路-参见投诉反馈回路。
o Feedback Message - A single message, often using the Abuse Reporting Format defined above and outlined in Appendix 1, which is part of a Feedback Stream.
o 反馈信息-单个信息，通常使用上文定义和附录1中概述的滥用报告格式，这是反馈流的一部分。
o Feedback Provider - The Sender of the Feedback Messages, almost always on behalf of or associated with the Mailbox Provider. Often the Mailbox Provider and Feedback Provider are the same entity, but we describe them separately in this document because they are each responsible for different parts of the Complaint Feedback Loop process. In some instances, the Feedback Provider may be operating solely on behalf of the Message Recipient, without any direct participation from their Mailbox Provider.
o 反馈提供程序-反馈消息的发件人，几乎总是代表邮箱提供程序或与邮箱提供程序关联。邮箱提供商和反馈提供商通常是同一个实体，但我们在本文档中分别对它们进行了描述，因为它们各自负责投诉反馈循环流程的不同部分。在某些情况下，反馈提供者可能仅代表消息接收者进行操作，而没有邮箱提供者的任何直接参与。
o Full Body - An email message (the "DATA" portion of the [SMTP] conversation) consists of two parts: the header and the body. The "Full Body" is simply the entirety of the body of the message, without modification or truncation. Note that images or other so-called "attachments" are actually part of the body, designated in accordance with the [MIME] standard.
o 全文-电子邮件（SMTP对话的“数据”部分）由两部分组成：标题和正文。“完整正文”只是消息正文的整体，没有修改或截断。请注意，图像或其他所谓的“附件”实际上是身体的一部分，根据[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对话的“数据”部分）由两部分组成：标题和正文。标题包含多个标题字段，每个字段的格式为“标题名称：标题内容”。尽管大多数邮件用户代理（MUA）只显示基本的四个标题字段（From、To、Date和Subject），但每条邮件都包含附加的标题字段，这些字段主要包含用于帮助自动处理的诊断信息或数据。通常非正式地称为“完整标题”。这些字段在[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—Internet服务提供商，在本文中通常称为访问提供商或邮箱提供商。
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 Message ID Header Field（消息ID标题字段）-每条电子邮件中包含的诊断标题字段之一（请参阅上文“完整标题部分”）是消息ID。理论上，它是该单独消息的唯一标识符。
o Message Delivery - The process of transferring a message from one mail transfer agent (MTA) to another. Once the message has been accepted by the MTA operating on behalf of the Recipient, it is considered to be "delivered" regardless of further processing or filtering that may take place after that point.
o 邮件传递-将邮件从一个邮件传输代理（MTA）传输到另一个的过程。一旦邮件被代表收件人的MTA接受，无论在此之后可能进行进一步的处理或过滤，邮件都将被视为“已送达”。
o Message Originator - The Sender, but not necessarily the author or creator, of a message.
o 消息发起人-消息的发送者，但不一定是消息的作者或创建者。
o Message Recipient - The person or mailbox that receives a message as final point of delivery.
o 邮件收件人-作为最终传递点接收邮件的人或邮箱。
o MIME - Multipurpose Internet Mail Extensions refers to a set of standards permitting non-plaintext data to be embedded in the body of a message. Concepts such as file attachments and formatted or "rich" text are all accomplished solely through [MIME].
o MIME-多用途Internet邮件扩展是指允许在邮件正文中嵌入非明文数据的一组标准。文件附件和格式化或“富”文本等概念都是通过[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 邮件用户代理；泛指最终用户用来访问、交互或发送电子邮件的软件。
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 Received Header Field（接收标题字段）-电子邮件中包含的诊断标题字段（请参见上文“完整标题部分”），以“Received:”开头，并记录（从下到上）邮件从发端人到当前位置的路径。
o Recipient - See "Message Recipient" above.
o 收件人-请参阅上面的“邮件收件人”。
o Return-Path - An optional message header field (see "Full Header Section" above) that indicates the Envelope Sender of the message.
o 返回路径-一个可选的邮件标题字段（请参阅上面的“完整标题部分”），用于指示邮件的信封发件人。
o Reverse DNS - The [DNS] name of an IP address, called "reverse" because it is the inverse of the more user-visible query that returns the IP address of a DNS name. Further, a Reverse DNS query returns a PTR record rather than an A record.
o 反向DNS—IP地址的[DNS]名称，称为“反向”，因为它与返回DNS名称IP地址的用户可见查询相反。此外，反向DNS查询返回PTR记录而不是a记录。
o Sender - see "Message Originator" above.
o 发件人-请参阅上面的“邮件发件人”。
o SMTP - Simple Mail Transfer Protocol, the mechanism and language for transferring an email message from one place to another as defined in RFC 5321 [SMTP].
o SMTP-简单邮件传输协议，RFC 5321[SMTP]中定义的将电子邮件从一个地方传输到另一个地方的机制和语言。
o Spam - For the purposes of this document (and for most Complaint Feedback Loops), "spam" is defined as any message that the Recipient chooses to complain about, regardless of the intent of the message's author or Sender.
o 垃圾邮件-在本文档中（以及大多数投诉反馈循环中），“垃圾邮件”定义为收件人选择投诉的任何邮件，无论邮件作者或发件人的意图如何。
o Spam Complaint - See "Complaint" above.
o 垃圾邮件投诉-请参阅上面的“投诉”。
o Spammer - An entity that knowingly, intentionally sends Spam messages (see "Spam" above).
o 垃圾邮件发送者-有意发送垃圾邮件的实体（见上文“垃圾邮件”）。
o Terms of Use - A legal document describing how a particular system or service is to be used.
o 使用条款-描述如何使用特定系统或服务的法律文件。
o VERP - Variable Envelope Return Path [VERP], an informally standardized method for encoding information about the Message Recipient into the return path while delivering a message in order to ensure that any non-delivery notices are processed correctly.
o VERP-可变信封返回路径[VERP]，一种非正式的标准化方法，用于在传递邮件时将有关邮件收件人的信息编码到返回路径中，以确保正确处理任何未送达通知。
In practice, a Mailbox Provider receives complaints from their End Users, and is often also the Feedback Provider for those complaints and is a consumer of feedback from other providers. In this document, we separate the Mailbox Provider and Feedback Provider functions to reduce possible confusion over those cases where they are separate, and we also urge Mailbox Providers to read the "Feedback Consumer" section later in this document.
实际上，邮箱提供商接收来自其最终用户的投诉，通常也是这些投诉的反馈提供商，并且是其他提供商反馈的消费者。在本文档中，我们将邮箱提供程序和反馈提供程序功能分开，以减少在它们分开的情况下可能出现的混淆，我们还敦促邮箱提供程序阅读本文档后面的“反馈消费者”部分。
The decision to provide a Complaint Feedback Loop service should not be taken lightly. The benefits of a Feedback Loop are great, but success depends on a sound plan, organized implementation, and dedication to upkeep.
不应轻视提供投诉反馈环路服务的决定。反馈循环的好处是巨大的，但成功取决于合理的计划、有组织的实施和对维护的投入。
What are some benefits of providing feedback to fellow Mailbox Providers and Access Providers? Primarily, other industry actors are quickly alerted to Spam outbreaks on their networks.
向其他邮箱提供商和访问提供商提供反馈有哪些好处？主要是，其他行业参与者会迅速对其网络上的垃圾邮件爆发发出警报。
End Users are becoming more aware of and comfortable with mechanisms to report Spam, and a Feedback Loop does just what it implies; it closes the loop. The End User's complaint makes its way back to the Message Originator (not necessarily the message Sender, who may be a Spammer), allowing the originator to take appropriate action. In this process, the mail system operator is just a messenger, relieved of the responsibility of reviewing and forwarding complaints manually.
最终用户越来越了解并习惯于报告垃圾邮件的机制，反馈循环正是它所暗示的；它结束了循环。最终用户的投诉会返回给消息发起者（不一定是消息发送者，可能是垃圾邮件发送者），允许发起者采取适当的行动。在此过程中，邮件系统操作员只是一名信使，不再需要手动审查和转发投诉。
Further, because every complaint is sent immediately -- without any review or analysis by the Feedback Provider -- the complaint is received by the Feedback Consumer in near real time. If the Feedback Consumer is paying attention to their Feedback Stream and taking appropriate action on it, the receiving Mailbox Provider receives less Spam, blocks less legitimate mail, and does not have to assign staff to follow up with the originating network. If the Mailbox Provider does not pay attention to its Feedback Stream, and does not take appropriate action, the Feedback Provider may block or otherwise filter the email from that Message Originator, considering the Feedback Messages to be sufficient notice.
此外，由于每个投诉都是立即发送的，反馈提供者没有进行任何审查或分析，因此反馈消费者几乎实时收到投诉。如果反馈消费者注意到他们的反馈流并对其采取适当的措施，则接收邮箱提供商接收的垃圾邮件更少，阻止的合法邮件更少，并且不必指派人员跟踪发起网络。如果邮箱提供程序不注意其反馈流，并且没有采取适当的措施，则反馈提供程序可能会阻止或以其他方式过滤来自该邮件发起人的电子邮件，认为反馈邮件已足够通知。
What are some benefits of providing Feedback Loops to bulk Feedback Consumers? As Message Recipients become more aware of and comfortable with Spam reporting mechanisms, they often prefer this method over the often-confusing and inconsistent "unsubscribe" or "opt-out" mechanisms provided by most legitimate Message Originators or Senders.
向批量反馈消费者提供反馈回路有哪些好处？随着邮件收件人越来越了解并熟悉垃圾邮件报告机制，他们通常更喜欢这种方法，而不是大多数合法邮件发起者或发件人提供的经常混淆和不一致的“取消订阅”或“选择退出”机制。
End Users often do not remember what lists they signed up for or are otherwise not confident in the established relationship they may have with a message Sender. As such, they often choose to report messages as Spam to their Mailbox Providers, considering that to be sufficient notification of their desire not to receive such email in the future.
最终用户通常不记得他们注册了哪些列表，或者对他们与消息发送者建立的关系不信任。因此，他们通常选择将邮件作为垃圾邮件报告给邮箱提供商，因为这足以表明他们希望在将来不再收到此类邮件。
If the Message Originator is paying attention to and taking appropriate action on their Feedback Stream, it will have a happier set of Message Recipients and should receive fewer Spam Complaints (assuming their opt-in processes are sound). If the Message Originator is not paying attention to Feedback and not taking appropriate action, the Mailbox Provider may consider the Feedback Stream sufficient notice that messages from that originator may no longer be accepted in the future.
如果邮件发起者注意到他们的反馈流并采取适当的行动，那么他们将拥有一组更快乐的邮件收件人，并且应该收到更少的垃圾邮件投诉（假设他们的选择加入流程是合理的）。如果消息发送者没有注意反馈而不采取适当的行动，邮箱提供商可能会认为反馈流充分注意到来自该发起者的消息在将来可能不再被接受。
To produce Feedback Messages and to ensure they are useful, the Feedback Provider needs to obtain near real-time complaints from the Mailbox Provider's users. This is typically done by integrating the feedback mechanism with the collection of Spam reports from its users.
为了生成反馈消息并确保它们有用，反馈提供商需要从邮箱提供商的用户那里获得近乎实时的投诉。这通常是通过将反馈机制与其用户收集的垃圾邮件报告集成来实现的。
These reports are typically made using the "Report Spam" buttons integrated into Webmail interfaces, or a proprietary desktop client provided to users. Mailbox Providers may also look at deploying a toolbar or MUA plug-in that provides a "Report Spam" button in the MUA interface.
这些报告通常使用集成到Webmail界面中的“报告垃圾邮件”按钮或提供给用户的专有桌面客户端生成。邮箱提供商还可以考虑部署工具栏或MUA插件，在MUA界面中提供“报告垃圾邮件”按钮。
Usability studies with average users should be performed on all interface changes before implementation. A "help" interface should also be available to educate users about how the Spam button should be used and what it does.
在实施之前，应对所有界面更改进行普通用户可用性研究。还应提供“帮助”界面，指导用户如何使用垃圾邮件按钮及其功能。
If the Mailbox Provider does not offer its customers a mail client with this button, then the Feedback Provider's chances for providing an effective Feedback Loop are slim. While it is possible for the Mailbox Provider to instruct its customers to forward unwanted mail to a central location and for the Mailbox Provider to explain how to ensure the report includes headers and bodies, the success rate of customers doing so tends to be low. Even those complaints that do contain all required information might prove difficult to parse, as variations in formatting and content types will lead to automated tools being consistently updated with new logic blocks for each variation that occurs.
如果邮箱提供商不使用此按钮为其客户提供邮件客户端，则反馈提供商提供有效反馈循环的机会微乎其微。虽然邮箱提供商可以指示其客户将不需要的邮件转发到中心位置，并解释如何确保报告包含标题和正文，但客户这样做的成功率往往较低。即使包含所有必需信息的投诉也可能难以解析，因为格式和内容类型的变化将导致自动工具不断更新，每个变化都有新的逻辑块。
It is recommended that Feedback Messages be sent using the standard Abuse Reporting Format, to facilitate uniformity and ease of processing for all consumers of feedback. This will also enable the Feedback Provider to extensively automate the processes of generating and sending Feedback Messages and of analyzing complaint statistics. This format is described further in Appendix 1.
建议使用标准的滥用报告格式发送反馈信息，以促进所有反馈消费者的一致性和易于处理。这还将使反馈提供者能够广泛地自动化生成和发送反馈信息以及分析投诉统计数据的过程。该格式在附录1中作了进一步说明。
Feedback Loops are usually (but not always) keyed to the "last hop" IP address (i.e., the IP address that passed the unwanted message to the Mailbox Provider's servers). Consequently, the Feedback Provider must be able to process the header from each complaint to determine the IP address for the complaint.
反馈循环通常（但并非总是）键入“最后一跳”IP地址（即，将不需要的消息传递到邮箱提供商服务器的IP地址）。因此，反馈提供者必须能够处理每个投诉的报头，以确定投诉的IP地址。
A Feedback Provider may wish to provide, as part of its Feedback Loop, other information beyond Spam Complaints that Feedback Consumers may find valuable. It might include summary delivery statistics (volume, inbox delivery rate, Spam trap hits, etc.) or other data that the Feedback Provider may deem pertinent to Feedback Consumers.
作为反馈回路的一部分，反馈提供者可能希望提供反馈消费者可能认为有价值的垃圾邮件投诉之外的其他信息。它可能包括摘要传递统计数据（数量、收件箱传递率、垃圾邮件陷阱点击率等）或反馈提供者可能认为与反馈消费者相关的其他数据。
Any mature Feedback Loop system will produce situations in which the Feedback Consumer may have follow-up questions or have other information to provide in regard to the feedback. Feedback Messages should include contact information (typically an Email Address) for the Feedback Consumer to use for such questions, and ideally the contact Email Address will feed into a ticket system or other automated tool used by the Mailbox Provider's postmaster and/or anti-abuse staff for handling general email delivery issues.
任何成熟的反馈回路系统都会产生这样的情况：反馈消费者可能会有后续问题或提供与反馈有关的其他信息。反馈信息应包括反馈消费者用于此类问题的联系信息（通常是电子邮件地址），理想情况下，联系电子邮件地址将输入票证系统或邮箱提供商的邮政局长和/或反滥用工作人员用于处理一般电子邮件传递问题的其他自动化工具。
Feedback Messages provide information relayed by Feedback Providers from a Mailbox Provider's End Users to the Feedback Consumer. There might not be any concerns with relaying non-private data to a third party. However, the information provided in the complaints generated by the user must be evaluated and any data deemed private may need to be removed before distributing to a third party, per local policy. For example, the Recipient's or reporter's Email Address and IP address may be categorized as private data and removed from the feedback report that is provided to the Feedback Consumer. Privacy laws and corporate data classification standards should be consulted when determining what information should be considered private.
反馈消息提供反馈提供程序从邮箱提供程序的最终用户向反馈使用者转发的信息。将非私有数据转发给第三方可能不存在任何问题。但是，根据当地政策，必须对用户投诉中提供的信息进行评估，并且可能需要在向第三方分发之前删除任何被视为隐私的数据。例如，接收者或报告者的电子邮件地址和IP地址可被归类为私人数据，并从提供给反馈消费者的反馈报告中删除。在确定哪些信息应被视为隐私时，应参考隐私法和公司数据分类标准。
Information provided by the Feedback Consumer to the Feedback Provider for the purpose of enrolling in the Feedback Loop should also be kept private. It should only be shared or used for the purposes explicitly agreed to during the enrollment process (see the "Terms of Use" section below).
反馈消费者向反馈提供者提供的信息（用于加入反馈回路）也应保密。它只能用于注册过程中明确同意的用途（请参阅下面的“使用条款”部分）。
Feedback Loops inevitably span country borders. Local laws and regulations regarding distribution of information domestically and internationally need to be considered when implementing a Feedback Loop program. For example, in some European countries, data exchange requires permission from governing bodies. The terms and circumstances surrounding the exchange of data need to be clearly defined and approved.
反馈回路不可避免地跨越国界。在实施反馈回路计划时，需要考虑有关国内外信息分发的当地法律法规。例如，在一些欧洲国家，数据交换需要管理机构的许可。围绕数据交换的条款和情况需要明确定义和批准。
A written Terms of Use agreement should be provided by the Feedback Provider and agreed to by the Feedback Consumer before any feedback is provided. The following concepts should be considered when drafting the terms of use agreement:
在提供任何反馈之前，反馈提供者应提供书面的使用条款协议，并经反馈消费者同意。起草使用条款协议时应考虑以下概念：
o Data provided in Feedback Messages are provided to a specific, approved entity. Information should not be transmitted outside of the intended, approved Recipient. Any inappropriate use of the information can lead to immediate termination from the feedback program.
o 反馈信息中提供的数据将提供给特定的、经批准的实体。信息不得在预期的、经批准的接收人之外传输。信息的任何不当使用都可能导致反馈计划立即终止。
o Consumers of Feedback have a responsibility to keep the information they provide for Feedback Loop purposes -- such as abuse contact information, IP addresses, and other records -- accurate and up to date.
o 反馈的消费者有责任保持他们为反馈循环目的提供的信息（如滥用联系信息、IP地址和其他记录）的准确性和最新性。
o The providing of Feedback information is a privilege and needs to be treated appropriately. It does not entitle the consumer of the feedback to any special sending privileges.
o 提供反馈信息是一种特权，需要适当对待。它不授予反馈消费者任何特殊发送特权。
o Approval and continued enrollment in the program is a privilege that can be denied or revoked for any reason and at any time.
o 批准和继续注册该计划是一项特权，可因任何原因随时拒绝或撤销。
There should be a streamlined application process for receiving feedback and the vetting of such applications. This vetting may be stringent in cases where the Mailbox Provider chooses to tie its Complaint Feedback Loop program to a whitelist. Criteria may involve the following:
应简化申请程序，以接收反馈和审查此类申请。如果邮箱提供商选择将其投诉反馈循环计划与白名单挂钩，则这种审查可能会非常严格。标准可能涉及以下方面：
o Cross-checking that the requestor is indeed authorized to receive feedback for the IP addresses concerned.
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 收集其他信息，如IP是否是ISP smarthost网络、网络主机场、电子邮件营销或邮件列表服务或其他实体。
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.
理想情况下，注册将分两步进行，申请人填写一份表格，并被要求在申请人的请求被放入队列供反馈提供者处理之前接收并确认一封确认电子邮件（最好发送给相关域的滥用职权@或邮政局长@）。
Ownership of IP addresses can and should be cross-checked by means of origin Autonomous System Number (ASN), WHOIS/RWHOIS records, Reverse DNS of the sending hosts, and other sources. This can be automated to some extent, but it often requires some manual processing.
IP地址的所有权可以而且应该通过来源自治系统号（ASN）、WHOIS/RWHOIS记录、发送主机的反向DNS和其他来源进行交叉检查。这可以在某种程度上实现自动化，但通常需要一些手动处理。
Applications for Feedback Loops can be accepted on a stand-alone web site or can be part of the Mailbox Provider's postmaster site. Regardless, the web site for the Complaint Feedback Loop program should contain other content specific to the Feedback Loop, including FAQs for the Feedback Loop program, the Terms of Service for the Feedback Loop, and perhaps a method for enrolled parties to modify their existing enrollments.
反馈循环的应用程序可以在独立网站上接受，也可以是邮箱提供商邮局主管网站的一部分。无论如何，投诉反馈环路计划的网站应包含反馈环路特定的其他内容，包括反馈环路计划的常见问题解答、反馈环路的服务条款，以及注册方修改其现有注册的方法。
The web site should also provide the Feedback Consumer with general information on how the feedback will be sent, including:
网站还应向反馈消费者提供有关如何发送反馈的一般信息，包括：
o Report Format (ARF or otherwise)
o 报告格式（ARF或其他）
o Sending IP addresses and/or DKIM "d=" string
o 发送IP地址和/或DKIM“d=”字符串
o "From" Email Address
o “发件人”电子邮件地址
Denial of a Feedback Loop application may be appropriate in certain cases such as:
在某些情况下，拒绝反馈回路应用程序可能是合适的，例如：
o Where the Feedback Provider suspects "gaming" of delivery policies via the Feedback received, with attempts to pollute Feedback Loop metrics by, for example, creating bogus accounts and reporting false negatives with these, to offset the negative reputation caused by high complaint rates.
o 反馈提供者通过收到的反馈怀疑交付政策存在“博弈”，试图通过创建虚假账户和报告虚假否定等方式污染反馈循环指标，以抵消高投诉率造成的负面声誉。
o Where the Feedback Provider has decided to block the Message Originator's IP space for which feedback has been requested on the grounds that email from that originator has a sufficiently negative reputation that it will not be delivered at all. This is somewhat on the lines of a global unsubscribe of the Message Provider's users from the originator's lists, which would make rendering additional feedback unnecessary.
o 反馈提供者已决定阻止请求反馈的消息发端人的IP空间，理由是该发端人的电子邮件具有足够的负面声誉，根本不会发送。这在某种程度上与消息提供者的用户从发端人列表中全局取消订阅类似，这将使提供额外反馈变得不必要。
It is recommended that the Feedback Provider send notification if an application is denied. Additionally, they should maintain a documented, clear, and transparent appeals process for denial of requests. This process can be as simple as the prospective Feedback Consumer replying to the denial email requesting review or escalation to a team lead, which also cites reasons the application should be reviewed.
如果应用程序被拒绝，建议反馈提供程序发送通知。此外，他们还应维持一个记录在案、清晰透明的拒绝请求上诉程序。这个过程可以很简单，因为潜在的反馈消费者回复拒绝电子邮件，请求审查或上报给团队负责人，这还引用了应该审查应用程序的原因。
For a Feedback Loop to be cost-effective and usable for large Feedback Consumers and Feedback Providers, it must be possible for reports to be generated and processed automatically without any human interaction. On the other hand, it should be possible for small Feedback Consumers to handle a low volume of reports manually, without requiring any automation.
为了使反馈回路具有成本效益并可用于大型反馈消费者和反馈提供者，必须能够在无需任何人工交互的情况下自动生成和处理报告。另一方面，小型反馈消费者应该可以手动处理少量报告，而不需要任何自动化。
In automating the feedback process, the consumer of the Feedback Stream must receive enough information about the report that it can take appropriate action, typically to remove the Recipient from the Mailing List about which it is sending a report. The Recipient's Email Address is not enough, as the Recipient may be on several Mailing Lists managed by the Feedback Loop consumer and only need to be removed from the particular list reported.
在自动化反馈过程中，反馈流的使用者必须收到有关报告的足够信息，以便能够采取适当的行动，通常是从其发送报告的邮件列表中删除收件人。收件人的电子邮件地址不够，因为收件人可能在反馈循环消费者管理的多个邮件列表中，只需要从报告的特定列表中删除。
Also, some producers of Feedback Loops might redact the Recipient's Email Address for privacy reasons. Effective implementation of a Complaint Feedback Loop requires that the Feedback Provider put in
此外，出于隐私原因，一些反馈循环的制作者可能会修改收件人的电子邮件地址。投诉反馈回路的有效实施要求反馈提供者投入
place as many automated processes and tools as feasible to handle all aspects of the process. Feedback Providers should seek to automate or script the following:
放置尽可能多的自动化流程和工具，以处理流程的各个方面。反馈提供者应设法自动化或编写以下脚本：
o Accepting and validating Feedback Loop Applications from prospective Feedback Consumers.
o 接受并验证来自潜在反馈消费者的反馈回路应用程序。
o Processing requests to determine whether or not they meet the Feedback Provider's criteria for enrollment in the program.
o 处理请求，以确定它们是否符合反馈提供者的计划注册标准。
o Accepting Spam Complaints from End Users; this will form the bulk (and perhaps sole) component of the feedback sent by the Feedback Provider.
o 接受终端用户的垃圾邮件投诉；这将构成反馈提供者发送的反馈的大部分（可能是唯一的）组成部分。
o Production of Feedback Messages from Spam Complaints.
o 从垃圾邮件投诉中生成反馈消息。
o Production of other Feedback Loop artifacts as chosen by the Feedback Provider.
o 由反馈提供者选择的其他反馈循环工件的生成。
o Optionally, provision of a mechanism for Feedback Consumers to further engage a Feedback Provider about a given Feedback Message.
o 可选地，提供一种机制，用于反馈消费者进一步与反馈提供者就给定的反馈消息进行接触。
o Ongoing validation of Feedback Loop enrollments to determine if a currently enrolled IP address or network merits continued inclusion in the Feedback Loop.
o 正在进行的反馈环路注册验证，以确定当前注册的IP地址或网络是否值得继续包含在反馈环路中。
o Optional periodic emails to Feedback Consumers to determine if their enrolled Email Addresses are still valid.
o 向反馈消费者发送可选的定期电子邮件，以确定其注册的电子邮件地址是否仍然有效。
It is recommended that self-service maintenance be offered to Feedback Consumers, to the extent practicable. The more they can do themselves, the less you have to do.
建议尽可能向反馈用户提供自助维护。他们自己能做的越多，你所需要做的就越少。
The criteria that a Feedback Provider uses to validate a Feedback Loop application may change over time. It is a near certainty at least some subset of Feedback Consumers enrolled to receive feedback will at some point after enrollment fail to meet those criteria, regardless of whether or not the criteria change.
反馈提供者用于验证反馈循环应用程序的标准可能会随时间而变化。几乎可以肯定的是，至少一些注册接收反馈的反馈消费者在注册后的某个时候会不符合这些标准，无论标准是否改变。
The Feedback Provider should put in place tools to periodically re-validate all Feedback Consumers enrolled in its Feedback Loop system against its current criteria. Additionally, the Feedback
反馈提供者应提供工具，根据其当前标准定期重新验证其反馈回路系统中注册的所有反馈使用者。此外，反馈
Provider will likely have objective criteria for remaining in the Feedback Loop for enrolled Feedback Consumers; the enrolled consumers should be validated against those criteria as well.
供应商可能会有客观的标准，以保持在已登记反馈消费者的反馈回路中；登记的消费者也应该根据这些标准进行验证。
Just as some Mailing List software has the built-in ability to send periodic "probe" emails to subscribed addresses to validate them, so too should the Feedback Provider develop tools to send similar emails to the addresses receiving Feedback Messages to ensure that they are valid. This is especially true for the addresses that are not the abuse@ and postmaster@ addresses originally used as part of the enrollment acknowledgment step. Over time, people may change employers, or at least roles, and validating the Email Addresses associated with an IP is one way for the Feedback Provider to ensure that Feedback Messages are still being accepted and acted upon by the Feedback Consumer.
正如某些邮件列表软件具有向订阅地址发送定期“探测”电子邮件以验证其有效性的内置功能一样，反馈提供者也应开发工具，向接收反馈消息的地址发送类似的电子邮件，以确保其有效性。对于不是最初用作注册确认步骤一部分的滥用@和邮局主管@地址的地址，尤其如此。随着时间的推移，人们可能会更换雇主，或者至少更换角色，而验证与IP相关联的电子邮件地址是反馈提供者确保反馈消息仍被反馈消费者接受并采取行动的一种方法。
Updating Feedback Consumers when one's own IP addresses are changing is an important aspect of Feedback Loop maintenance. The exact format, automation, and other considerations of these updates are outside the scope of this document, but are topics worthy of further discussion and eventual documentation.
在自己的IP地址发生变化时更新反馈消费者是反馈环路维护的一个重要方面。这些更新的确切格式、自动化和其他注意事项不在本文档的范围内，但值得进一步讨论和最终文档化。
A Feedback Consumer receives its Feedback Messages after its submitted Application for a Complaint Feedback Loop is approved. A Feedback Consumer will usually have Complaint Feedback Loop subscriptions set up with multiple Feedback Providers. Different Feedback Streams may be in different formats or include different information, and the Feedback Consumer should identify a process to organize the data received and take appropriate action.
反馈消费者在其提交的投诉反馈回路申请获得批准后收到反馈消息。反馈消费者通常会与多个反馈提供者建立投诉反馈循环订阅。不同的反馈流可能采用不同的格式或包含不同的信息，反馈消费者应确定一个流程来组织接收到的数据并采取适当的措施。
A Feedback Consumer, Mailbox Provider, or Access Provider (i.e., a hosting company or ISP) will use this Feedback to identify network compromises, fraudulent accounts, policy violations, and other concerns. The Feedback Loop provides real-time visibility into Spam Complaints from Message Recipients, greatly enabling these Mailbox Providers to mitigate Spam propagating from their networks.
反馈消费者、邮箱提供商或访问提供商（即托管公司或ISP）将使用此反馈识别网络泄露、欺诈帐户、违反策略和其他问题。反馈回路提供了对来自邮件收件人的垃圾邮件投诉的实时可视性，使这些邮箱提供商能够大大减少从其网络传播的垃圾邮件。
Senders of bulk email should use the complaints to make decisions regarding future mailings. Such decisions may include one or more of the following: modification of email frequency, branding, opt-in practices, or list management.
批量电子邮件的发件人应使用投诉来决定未来的邮件。此类决策可能包括以下一项或多项：修改电子邮件频率、品牌、选择加入实践或列表管理。
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. “角色”电子邮件地址，如滥用@和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.
* 请求的IP的WHOIS信息显然与域名相关。
4. Contact information such as name, Email Address, phone number, and other relevant information.
4. 联系人信息，如姓名、电子邮件地址、电话号码和其他相关信息。
5. The knowledge that if the application form asks for your credit card number or other financial information, it is assuredly a scam.
5. 知道如果申请表要求提供你的信用卡号码或其他财务信息，那肯定是骗局。
Once a Feedback Consumer has signed up to receive feedback from a Feedback Provider, it may also receive several other sorts of delivery-related reports. This includes Feedback Messages, administrative messages, and other messages.
一旦反馈消费者注册接收反馈提供者的反馈，它还可能会收到其他几种与交付相关的报告。这包括反馈消息、管理消息和其他消息。
Feedback Messages are the main emails generally associated with a Feedback Loop. Each time a Recipient hits the "This Is Spam" button, the Feedback Loop system creates a boilerplate report with a copy of the original email attached and sends it to the consumer of the Feedback Loop.
反馈信息是通常与反馈循环相关联的主要电子邮件。每次收件人点击“这是垃圾邮件”按钮时，反馈循环系统都会创建一份样板报告，并附上原始电子邮件的副本，并将其发送给反馈循环的消费者。
The handling of feedback reports is discussed in the next section.
下一节将讨论反馈报告的处理。
Administrative messages will typically be sent to the Email Address provided for contacting the person who originally applied for the Feedback Loop, rather than to the address provided for handling the Feedback Messages. These messages are likely to be sent infrequently and irregularly, but it is important they are seen by the person managing the Feedback Stream processor in a timely manner. It is usually a poor idea to have these sent to an individual's Email Address since they may be lost if that person is on vacation, changes position within the company, or leaves the company.
管理消息通常会发送到为联系最初申请反馈循环的人员而提供的电子邮件地址，而不是发送到为处理反馈消息而提供的地址。这些消息可能不经常和不定期地发送，但重要的是，管理反馈流处理器的人员能够及时看到这些消息。将这些邮件发送到个人的电子邮件地址通常不是一个好主意，因为如果此人正在休假、在公司内更换职位或离开公司，这些邮件可能会丢失。
Instead, they should be sent to a role account that goes to a ticketing system or "exploded" to multiple responsible parties within the organization. If there is not already an appropriate role account such as support@ or noc@ that reaches the right team, it may be a good idea to set up a dedicated alias such as fblmaster@ to sign up for all Feedback Loops.
相反，它们应该被发送到一个角色帐户，该帐户进入票务系统或“分解”到组织内的多个负责方。如果还没有合适的角色帐户（如support@或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:
发送反馈的邮箱提供商可能已经发布了有关他们期望反馈消费者如何使用反馈消息的策略，或者可能期望反馈消费者只是“停止问题”。实际上，这主要归结为三件事：
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.
如果反馈消费者是与消息发起人分开的实体，则这两个实体应共同解决任何问题。
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".
这在事务性邮件的情况下变得更加复杂，事务性邮件与其他服务（如购票确认或账单）相关联。在这种情况下，反馈消费者必须再次根据具体情况做出最佳判断。在某些情况下，正确的做法可能是通过另一个渠道与接收者进行沟通，例如服务网站上的消息；i、 例如，“您报告您的通知邮件为垃圾邮件，因此我们不会再向您发送任何邮件，除非您另行通知。”。
In some cases, the best thing to do may be to ignore the Feedback Message. For example, if your customer has reported as Spam the airline tickets he purchased and you emailed him, he probably did not mean it and he is going to be very annoyed if you do not send him the other tickets he has ordered. In rare cases, it might be appropriate to suppress email to the Recipient, but also to suspend access to a service he or she uses until the Recipient confirms a desire to receive the associated email. In all these cases, the important goal is to keep the customer happy and reduce future complaints, even in the apparently paradoxical situations where the way to do that is to ignore their Feedback. In the real world, however, these are a small minority of cases.
在某些情况下，最好的做法可能是忽略反馈信息。例如，如果你的客户报告说他购买的机票是垃圾邮件，而你给他发了电子邮件，他可能不是故意的，如果你不给他发送他订购的其他机票，他会非常恼火。在极少数情况下，禁止向收件人发送电子邮件可能是合适的，但也可以暂停对他或她使用的服务的访问，直到收件人确认希望接收相关电子邮件。在所有这些情况下，重要的目标是让客户满意并减少未来的投诉，即使在明显矛盾的情况下，这样做的方法是忽略他们的反馈。然而，在现实世界中，这些只是少数情况。
Counting the Feedback Messages received over regular time periods can provide much useful information to ISPs, ESPs, and other Feedback Consumers, especially when broken down appropriately.
统计定期收到的反馈信息可以为ISP、ESP和其他反馈消费者提供非常有用的信息，特别是在适当细分时。
An ISP (Mailbox Provider or Access Provider) might want to count the number of Feedback Messages a particular customer or IP address causes in a given day. If there is a sudden increase from a particular customer or server, it may be a sign that a Spammer has signed up or a system has been compromised. If there is a high level of complaints about a particular customer, it may be worth investigating to see if there is a reason for that. For example, 10 Feedback Messages a day would be a sign of serious problems in some cases, but might be perfectly reasonable "background" levels for a Message Originator that sends 300,000 emails a month. If the count shows there may be a problem, the ISP can dig down and look at the emails that are being reported to determine the underlying cause.
ISP（邮箱提供商或访问提供商）可能希望统计特定客户或IP地址在给定日期内导致的反馈消息数。如果某个特定客户或服务器的数量突然增加，则可能表明垃圾邮件发送者已注册或系统已被破坏。如果对某个特定客户的投诉程度很高，那么可能需要进行调查，看看是否有原因。例如，在某些情况下，每天10条反馈信息可能是严重问题的标志，但对于每月发送30万封电子邮件的消息发起人来说，这可能是完全合理的“背景”水平。如果计数显示可能存在问题，ISP可以深入查看报告的电子邮件，以确定根本原因。
An ESP can do similar things but can also break the data down in more ways: by customer, by Mailing List, by campaign. An ESP also has access to more information; it knows how many emails were delivered to the receiving Mailbox Provider over a given time period. As a result, it can estimate the number of complaints divided by the number of emails sent, which is often a more useful metric than the absolute number of reports. This is critical data for ESPs to track over time because it can help identify and quantify problem customers.
ESP可以做类似的事情，但也可以用更多的方式分解数据：按客户、按邮件列表、按活动。ESP还可以访问更多信息；它知道在给定的时间段内向接收邮箱提供商发送了多少封电子邮件。因此，它可以估计投诉数量除以发送的电子邮件数量，这通常比报告的绝对数量更有用。这是ESP随时间跟踪的关键数据，因为它可以帮助识别和量化问题客户。
An individual Feedback Consumer, whether sending their own email or using an ESP, can acquire at least some information from complaint rates. A spike in complaints on an otherwise stable list might be a sign there is a problem with address acquisition, if the spike is due to reports from new subscribers. If it came from older subscribers, it might be attributable to content of a particular mailing that was not well received. Perhaps the branding was not recognized or the content was offensive or inappropriate for the list.
个人反馈消费者，无论是发送自己的电子邮件还是使用ESP，都可以从投诉率中获得至少一些信息。如果投诉数量激增是由于来自新订户的报告造成的，则其他稳定列表上的投诉数量激增可能表明地址获取存在问题。如果它来自较老的订阅者，则可能是由于某个特定邮件的内容不受欢迎。可能是该品牌未被认可，或其内容令人反感或不适合该列表。
The complaint rate is determined by the number of Feedback Messages received over a given time period divided by the number of emails delivered to the associated Mailbox Provider over the same period. It is an obvious and useful metric to track, but there are a few subtle issues to be aware of.
投诉率由给定时间段内收到的反馈邮件数除以同一时间段内发送给相关邮箱提供商的电子邮件数确定。这是一个显而易见且有用的指标，但有一些微妙的问题需要注意。
One issue is that Feedback Messages tend to be counted on the day the complaint was sent, which is the day the original message was read by the Recipient. That may not be the same day that the message was sent. A simple example is the fact that a Message Originator that
一个问题是，反馈信息往往在投诉发出的当天计算，也就是收件人阅读原始信息的当天。这可能不是消息发送的同一天。一个简单的例子是，消息发起人
sends email regularly Monday through Friday will often see a high complaint rate on Saturday. The absolute number of Feedback Messages sent by people catching up with the week's email over the weekend may not be that high. However, since hardly any email is sent on Saturday, a fairly reasonable number of complaints end up being divided by a very small number of total sent emails, possibly even zero, which would break the reporting engine. This can lead to a complaint rate that seems to range anywhere from suspicious to ridiculous. Consequently, large Mailing Lists that are virtually silent on the weekend could end up receiving more complaints on a Saturday than email they sent that day, leading to complaint rates of well over 100%.
周一至周五定期发送电子邮件，周六的投诉率通常很高。周末收到本周电子邮件的人发送的反馈信息的绝对数量可能不会太高。然而，由于周六几乎没有发送任何电子邮件，因此相当合理的投诉数量最终被发送的电子邮件总数除以非常小的数量，甚至可能为零，这将破坏报告引擎。这可能导致投诉率从可疑到荒谬不等。因此，周末几乎沉默的大型邮件列表可能会在周六收到比当天发送的电子邮件更多的投诉，导致投诉率远远超过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.
另一个要考虑的算术问题是收件箱、大容量文件夹和“这是Spam”按钮之间的交互。如果一个组织发送了大量声誉不佳的电子邮件，那么它可能会在10000封邮件中有500封在收件箱中，其余9500封在大容量文件夹中。如果它收到10条反馈信息，并将其除以发送的10000封电子邮件，它将获得非常可观的0.1%投诉率。然而，邮箱提供商可能会通过除以发送到收件箱的电子邮件数量来计算投诉率——给出2%的投诉率，这可能是立即阻止的理由。因此，如果你看到邮箱提供商或其他声誉系统报告的投诉率与根据原始投递数量计算的投诉率之间存在很大差异，那么仔细查看数据是很重要的。
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，应该能够处理反馈报告，自动化程度很低或没有自动化，因为ARF消息在大多数邮件客户端中都应该是可读的。可能值得向入站反馈消息添加一些非常轻量级的处理，以便于从其他电子邮件客户端对其进行分类。例如，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，就可以使用混合方法，将不同的数据位分开存储，但某些数据段可以进行加密或模糊处理。这可以提供一个很好的折衷方案，其中大多数数据对第三方来说并不明显，但其中的模式可以通过肉眼识别。例如，消息ID为“esp-423-27-42460@example.com“对于第三方来说是不透明的，但是熟悉该格式的人可以看出它是系统添加的消息ID。在本例中，它以“esp”开头，后面是三个用破折号分隔的数字，这意味着它来自客户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字符串相同的格式，则反馈处理器可以创建“假”硬反弹并将其发送到现有反弹处理器，从而抑制发送到该地址的邮件。
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地址以及哪个客户发送了消息更感兴趣。在大多数情况下，可以很容易地从ARF元数据中提取IP地址；然而，在其他情况下，可能需要从包含的原始消息中嵌入的接收头中提取。然后，如果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.福尔克和琳达·马库斯编辑。在Barry Leiba和Murray Kucherawy的建议下，J.D.Falk对IETF发布的本版本进行了进一步的编辑和格式化。
[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] 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.translate error, please retry
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，“域密钥识别邮件（DKIM）签名”，RFC 63762011年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 48702007年5月。
[MAAWG] Messaging Anit-Abuse Working Group, <http://www.maawg.org/>.
[MAAWG]反信息技术滥用工作组<http://www.maawg.org/>.
[MAAWG-BCP] MAAWG, "MAAWG Sender Best Communications Practices Executive Summary and MAAWG Sender Best Communications Practices Version 2.0a-Updated", September 2011, <http://www.maawg.org/sites/maawg/files/news/ MAAWG_Senders_BCP_Ver2.pdf>.
[MAAWG-BCP]MAAWG，“MAAWG发送方最佳通信实践执行摘要和MAAWG发送方最佳通信实践版本2.0a-更新”，2011年9月<http://www.maawg.org/sites/maawg/files/news/ MAAWG_Senders_BCP_Ver2.pdf>。
[MARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, August 2010.
[MARF]Shafranovich，Y.，Levine，J.，和M.Kucherawy，“电子邮件反馈报告的可扩展格式”，RFC 59652010年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.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[RFC5598]Crocker，D.，“互联网邮件体系结构”，RFC5598，2009年7月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP]Klensin，J.，“简单邮件传输协议”，RFC 53212008年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.，“电子邮件中的信任始于身份验证”，由消息传递反滥用工作组（MAAWG）发布，2008年6月<http://www.maawg.org/sites/maawg/files/news/ MAAWG_电子邮件(Email)认证(Paper)文件(2008-07.pdf)。
[VERP] Wikipedia, "Variable Envelope Return Path", <https://secure.wikimedia.org/wikipedia/en/wiki/ Variable_envelope_return_path>.
[VERP]维基百科，“可变信封返回路径”<https://secure.wikimedia.org/wikipedia/en/wiki/ 变量\信封\返回\路径>。
[Wise] "arffilter - rewrite ARF reports", <http://wordtothewise.com/products/arffilter.html>.
[Wise]“arffilter-重写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.
如今，MAAWG内部和外部的几乎所有反馈提供者都使用ARF，构成了全球产生的绝大多数反馈信息。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报告（反馈消息）通过电子邮件发送，每个垃圾邮件报告发送一条消息。它由三个部分组成，采用称为multipart/report的标准[MIME]消息格式。
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
第二部分包含一些机器可读的信息，包括所使用的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.
消息的处理方式相同。因此，这一部分往往被那些喜欢自己处理第三部分的反馈消费者完全忽略。
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.
报告的第三部分包括报告所涉及的原始电子邮件的副本，作为标准[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]
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]
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签名头字段中的“d=”值。
In a social or policy context, applying a DKIM signature to a message is tantamount to stating, "I take responsibility for this message". The DKIM signature is most often applied by the author or originator of a message, which may be far upstream of the "last hop" MTA. This is true particularly in cases where the originator's intended Recipient Email Address is configured to forward to another Recipient Email Address. Stories of users who have strung together multiple forwarding accounts are not uncommon, and these users are unable to complain effectively about Spam because their Mailbox Providers cannot easily or reliably follow the path of a message back to the initial originator.
在社会或政策背景下，将DKIM签名应用于消息等于声明“我对此消息负责”。DKIM签名通常由消息的作者或发起者应用，该消息可能远位于“最后一跳”MTA的上游。这一点在发起人的预期收件人电子邮件地址被配置为转发到另一个收件人电子邮件地址的情况下尤其如此。将多个转发帐户串在一起的用户的故事并不少见，而且这些用户无法有效地投诉垃圾邮件，因为他们的邮箱提供商无法轻松或可靠地跟踪邮件返回初始发件人的路径。
A single DKIM "d=" value may be used across multiple servers with multiple IP addresses. Servers may be added or removed at any time without changing the dynamics of the DKIM signature. When a Feedback Loop is based on the IP address, the Feedback Consumer must contact the Feedback Provider to change its subscription options every time an IP address needs to be added or removed. However, when a Feedback Loop uses DKIM, no reconfiguration is necessary because the signing domain does not change.
单个DKIM“d=”值可在具有多个IP地址的多台服务器上使用。可以随时添加或删除服务器，而无需更改DKIM签名的动态。当反馈循环基于IP地址时，每次需要添加或删除IP地址时，反馈消费者必须联系反馈提供商以更改其订阅选项。但是，当反馈循环使用DKIM时，无需重新配置，因为签名域不会更改。
One recurring concern with DKIM, however, is that ESPs often send messages addressed with hundreds or thousands of customer domains, yet they want to receive Feedback Messages for all of these domains. This was particularly difficult with [DomainKeys] (the predecessor to DKIM), which tied the "d=" to the "From" header field. DKIM removed this tie, so it is simple for an ESP to use a domain of its own to sign the message and sign up for Feedback regarding all messages signed with that domain. Such a signature may be in addition to, or instead of, signatures from the various client domains. While there are still many unknowns related to reputation (which will be addressed in a future MAAWG document), this is clearly an appropriate use of DKIM to take responsibility (and receive Feedback) for a message.
然而，DKIM的一个反复出现的问题是ESP经常发送数百或数千个客户域的消息，但他们希望接收所有这些域的反馈消息。这对于[DomainKeys]（DKIM的前身）尤其困难，因为它将“d=”绑定到“From”头字段。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.
也就是说，如果反馈提供者选择发送反馈而不首先被询问，则应遵循某些准则。一般来说，it部门应做出谨慎的决策，以尽量减少对邮箱提供商和访问提供商的负面影响。
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. Falk（编辑）消息反滥用工作组旧金山要塞公园邮政信箱29920号572 B B路旧金山，CA 94129- 0920美国
EMail: ietf@cybernothing.org
URI: http://www.maawg.org/
EMail: ietf@cybernothing.org
URI: http://www.maawg.org/