idnits 2.17.1
draft-jdfalk-maawg-cfblbcp-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
-- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i)
Publication Limitation clause.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (October 25, 2011) is 4567 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
-- Obsolete informational reference (is this intentional?): RFC 4870 (ref.
'DomainKeys') (Obsoleted by RFC 4871)
-- Obsolete informational reference (is this intentional?): RFC 4871 (ref.
'DKIM') (Obsoleted by RFC 6376)
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group J. Falk, Ed.
3 Internet-Draft Messaging Anti-Abuse Working
4 Intended status: Informational Group
5 Expires: April 27, 2012 October 25, 2011
7 Complaint Feedback Loop Operational Recommendations
8 draft-jdfalk-maawg-cfblbcp-03
10 Abstract
12 Complaint Feedback Loops similar to those described herein have
13 existed for more than a decade, resulting in many de facto standards
14 and best practices. This document is an attempt to codify, and thus
15 clarify, the ways that both providers and consumers of these feedback
16 mechanisms intend to use the feedback, describing some already-common
17 industry practices.
19 This paper is the result of cooperative efforts within the Messaging
20 Anti-Abuse Working Group, a trade organization separate from the
21 IETF. The original MAAWG document upon which this document is based
22 was published in April, 2010. This document is being published as an
23 Informational RFC to make it widely available to the Internet
24 community and simplify reference to this material from IETF work.
26 Status of this Memo
28 This Internet-Draft is submitted in full conformance with the
29 provisions of BCP 78 and BCP 79. This document may not be modified,
30 and derivative works of it may not be created, except to format it
31 for publication as an RFC or to translate it into languages other
32 than English.
34 Internet-Drafts are working documents of the Internet Engineering
35 Task Force (IETF). Note that other groups may also distribute
36 working documents as Internet-Drafts. The list of current Internet-
37 Drafts is at http://datatracker.ietf.org/drafts/current/.
39 Internet-Drafts are draft documents valid for a maximum of six months
40 and may be updated, replaced, or obsoleted by other documents at any
41 time. It is inappropriate to use Internet-Drafts as reference
42 material or to cite them other than as "work in progress."
44 This Internet-Draft will expire on April 27, 2012.
46 Copyright Notice
48 Copyright (c) 2011 IETF Trust and the persons identified as the
49 document authors. All rights reserved.
51 This document is subject to BCP 78 and the IETF Trust's Legal
52 Provisions Relating to IETF Documents
53 (http://trustee.ietf.org/license-info) in effect on the date of
54 publication of this document. Please review these documents
55 carefully, as they describe your rights and restrictions with respect
56 to this document. Code Components extracted from this document must
57 include Simplified BSD License text as described in Section 4.e of
58 the Trust Legal Provisions and are provided without warranty as
59 described in the Simplified BSD License.
61 Table of Contents
63 1. Glossary of Standard Terms . . . . . . . . . . . . . . . . . . 4
64 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
65 3. Mailbox Providers and Feedback Providers . . . . . . . . . . . 10
66 3.1. Benefits of Providing Feedback . . . . . . . . . . . . . . 10
67 3.2. Collecting Complaints . . . . . . . . . . . . . . . . . . 11
68 3.3. Creating Reports . . . . . . . . . . . . . . . . . . . . . 12
69 3.4. Policy Concerns . . . . . . . . . . . . . . . . . . . . . 12
70 3.4.1. Privacy & Regulatory Compliance . . . . . . . . . . . 12
71 3.4.2. Terms of Use . . . . . . . . . . . . . . . . . . . . . 13
72 3.5. Handling Requests to Receive Feedback . . . . . . . . . . 13
73 3.5.1. Application Web Site . . . . . . . . . . . . . . . . . 14
74 3.5.2. Saying No . . . . . . . . . . . . . . . . . . . . . . 14
75 3.5.3. Automation . . . . . . . . . . . . . . . . . . . . . . 15
76 3.6. Ongoing Maintenance . . . . . . . . . . . . . . . . . . . 16
77 3.6.1. IP Validation . . . . . . . . . . . . . . . . . . . . 16
78 3.6.2. Email Address Validation . . . . . . . . . . . . . . . 16
79 3.6.3. Feedback Production Changes . . . . . . . . . . . . . 17
80 4. Feedback Consumers . . . . . . . . . . . . . . . . . . . . . . 18
81 4.1. Preparation . . . . . . . . . . . . . . . . . . . . . . . 18
82 4.2. What You'll Receive . . . . . . . . . . . . . . . . . . . 19
83 4.2.1. Feedback Reports . . . . . . . . . . . . . . . . . . . 19
84 4.2.2. Administrative Messages . . . . . . . . . . . . . . . 19
85 4.2.3. Report Cards . . . . . . . . . . . . . . . . . . . . . 20
86 4.3. Handling Feedback Messages . . . . . . . . . . . . . . . . 20
87 4.3.1. Unsubscription or Suppression . . . . . . . . . . . . 21
88 4.3.2. Trending and Reporting . . . . . . . . . . . . . . . . 22
89 4.4. Automatically Handling an Incoming Feedback Stream . . . . 23
90 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 27
91 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
92 6.1. About MAAWG . . . . . . . . . . . . . . . . . . . . . . . 28
93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
94 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
95 9. Informative References . . . . . . . . . . . . . . . . . . . . 31
96 Appendix A. Abuse Reporting Format (ARF) . . . . . . . . . . . . 32
97 A.1. A Brief History . . . . . . . . . . . . . . . . . . . . . 32
98 A.2. Structure of an ARF Message . . . . . . . . . . . . . . . 32
99 Appendix B. Using DKIM to Route Feedback . . . . . . . . . . . . 34
100 Appendix C. Unsolicited Feedback . . . . . . . . . . . . . . . . 35
101 C.1. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 35
102 C.2. Pros . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
103 C.3. Cons . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
104 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37
106 1. Glossary of Standard Terms
108 Wherever possible, these terms are derived from [RFC 5598].
110 o Abuse Reporting Format - The standard format for Feedback
111 Messages, defined in Appendix A and [MARF].
113 o Access Provider - Any company or organization that provides End
114 Users with access to the Internet. May or may not be the same
115 entity which the End User uses as a Mailbox Provider.
117 o Application for Feedback Loop - the process, manual or online, by
118 which a prospective Feedback Consumer requests to receive a
119 feedback loop from a particular Feedback Provider.
121 o ARF -- See "Abuse Reporting Format."
123 o ARF Report -- See "Feedback Message."
125 o Body - See "Full Body."
127 o Complaint or Complaint Message - See "Feedback Message."
129 o Complaint Feedback Loop - See Overview and Taxonomy section.
131 o Complaint Stream - See "Feedback Stream."
133 o Delivery - See "Message Delivery."
135 o DKIM - DomainKeys Identified Mail, further described in the MAAWG
136 email authentication white paper "Trust in Email Begins with
137 Authentication" [1] and [DKIM].
139 o End User - A customer of a Mailbox Provider or Access Provider.
141 o Envelope Sender - The Email Address included as the argument to
142 the [SMTP] "MAIL" command during transfer of a message.
144 o Email Address - A string of the form user@domain, where the domain
145 (after the @ symbol) is used to determine where to transfer an
146 email message so that it may be delivered to the mailbox specified
147 by the user name (before the @ symbol). The precise technical
148 format of an email address is defined in [SMTP]. Email delivery
149 can be a complex process and is not described further in this
150 document.
152 o Email Service Provider (ESP) - A provider of email sending
153 services; the ESP is often a Message Originator working on behalf
154 of a Message Author. MAAWG uses the term "ESP" solely for this
155 definition and does not refer to a Mailbox Provider for End Users
156 as an ESP.
158 o FBL - The acronym "FBL" is intentionally not used in this
159 document.
161 o Feedback or Feedback Stream - A set (often a continuous stream) of
162 Feedback Messages sent from a single Feedback Provider to a single
163 Feedback Consumer.
165 o Feedback Consumer - A Recipient of the Feedback Messages, almost
166 always on behalf of or otherwise associated with the Message
167 Originator. Often the Message Originator and Feedback Consumer
168 are the same entity, but we describe them separately in this
169 document because they are each responsible for different parts of
170 the Complaint Feedback Loop process, as demonstrated in the
171 flowchart in the Overview section.
173 o Feedback Loop - See Complaint Feedback Loop.
175 o Feedback Message - A single message, often using the Abuse
176 Reporting Format defined above and outlined in Appendix 1, which
177 is part of a Feedback Stream.
179 o Feedback Provider - The Sender of the Feedback Messages, almost
180 always on behalf of or associated with the Mailbox Provider.
181 Often the Mailbox Provider and Feedback Provider are the same
182 entity, but we describe them separately in this document because
183 they are each responsible for different parts of the Complaint
184 Feedback Loop process. In some instances the Feedback Provider
185 may be operating solely on behalf of the Message Recipient,
186 without any direct participation from their Mailbox Provider.
188 o Full Body - An email message (the "DATA" portion of the [SMTP]
189 conversation) consists of two parts: the header and the body. The
190 "Full Body" is simply the entirety of the body of the message,
191 without modification or truncation. Note that images or other so-
192 called "attachments" are actually part of the body, designated in
193 accordance with the [MIME] standard.
195 o Full Header Section - An email message (the "DATA" portion of the
196 [SMTP] conversation) consists of two parts: the header and the
197 body. The header contains multiple header fields, each formatted
198 as "Header-Name: header contents." Although most MUAs only show
199 the basic four header fields From, To, Date, and Subject, every
200 message includes additional header fields that primarily contain
201 diagnostic information or data intended to assist automatic
202 processing. Often informally called "Full Headers." These fields
203 are fully defined in [RFC 5322]
205 o Header - See "Full Header Section" above.
207 o ISP - Internet Service Provider, usually referred to as either an
208 Access Provider or a Mailbox Provider in this paper.
210 o Mail Abuse Reporting Format (MARF) - See "Abuse Reporting Format"
211 above.
213 o Mailbox Provider - A company or organization that provides email
214 mailbox hosting services for End Users and/or organizations. Many
215 Mailbox Providers are also Access Providers.
217 o Mailing List - A set of email addresses which will receive
218 specific messages in accordance with the policies of that
219 particular list.
221 o Message-ID Header Field - One of the diagnostic header fields
222 included in every email message (see "Full Header Section" above)
223 is the Message-ID. Theoretically, it is a unique identifier for
224 that individual message.
226 o Message Delivery - The process of transferring a message from one
227 mail transfer agent (MTA) to another. Once the message has been
228 accepted by the MTA operating on behalf of the Recipient, it is
229 considered to be "delivered" regardless of further processing or
230 filtering that may take place after that point.
232 o Message Originator - The Sender, but not necessarily the author or
233 creator, of a message.
235 o Message Recipient - The person or mailbox that receives a message
236 as final point of delivery.
238 o MIME - Multipurpose Internet Mail Extensions refers to a set of
239 standards permitting non-plain-text data to be embedded in the
240 body of a message. Concepts such as file attachments and
241 formatted or "rich" text are all accomplished solely through
242 [MIME].
244 o MUA - Mail User Agent; loosely referring to the software used by
245 an End User to access, interact with, or send email messages.
247 o Provider - See "Feedback Provider" above.
249 o Received Header Field - Diagnostic header fields included in an
250 email message (see "Full Header Section" above) that start with
251 "Received:" and document (from bottom to top) the path a message
252 traversed from the originator to its current position.
254 o Recipient - See "Message Recipient" above.
256 o Return-Path - An optional message header field (see "Full Header
257 Section" above) that indicates the Envelope Sender of the message.
259 o Reverse DNS - The [DNS] name of an IP address, called "reverse"
260 because it is the inverse of the more user-visible query that
261 returns the IP address of a DNS name. Further, a reverse DNS
262 query returns a PTR record rather than an A record.
264 o Sender - see "Message Originator" above.
266 o SMTP - Simple Mail Transfer Protocol, the mechanism and language
267 for transferring an email message from one place to another as
268 defined in IETF RFC 5321 [SMTP].
270 o Spam - For the purposes of this document (and for most Complaint
271 Feedback Loops) "spam" is defined as any message which the
272 Recipient chooses to complain about, regardless of the intent of
273 the message's author or Sender.
275 o Spam Complaint - See "Complaint" above.
277 o Spammer - An entity that knowingly, intentionally sends Spam
278 messages (see "Spam" above).
280 o Terms of Use - A legal document describing how a particular system
281 or service is to be used.
283 o VERP - Variable Envelope Return Path [2], an informally
284 standardized method for encoding information about the Message
285 Recipient into the return path while delivering a message in order
286 to ensure that any non-delivery notices are processed correctly.
288 2. Overview
290 The intent of a Complaint Feedback Loop is to provide Feedback
291 Consumers with information necessary to mitigate Spam or the
292 perception of Spam. Thus, feedback was originally only offered to
293 mailbox, access and network providers - in other words, to ISPs - who
294 would use the feedback to identify network compromises and fraudulent
295 accounts, or to notify their downstream customer that there may be a
296 problem.
298 Senders of bulk, transactional, social or other types of email can
299 also use this feedback to adjust their mailing practices, using Spam
300 Complaints as an indicator of whether the Recipient wishes to
301 continue receiving email. Common reactions often include refining
302 opt-in practices, mailing frequency, list management, message content
303 and other measures. Over time, this has become the Feedback Consumer
304 use case most often discussed at MAAWG meetings and other industry
305 events - but readers are cautioned that it is not the sole use for
306 feedback.
308 [ Feedback Consumer Database ]
309 |
310 V
311 [ User ] [ Mailbox ] [ Feedback ]
312 [ Reports ]--->[ Provider ]--SMTP-->[ Provider ]
313 [ Spam ] | |
314 V V [ Feedback ]
315 [Spam Filter Rules] [ ARF Message ]--SMTP-->[ Consumer ]
317 Figure 1
319 When an End User of a Mailbox Provider issues a Spam complaint, the
320 Feedback Provider sends a report to the Feedback Consumer. This
321 report may include the Full Body of the original email, or (less
322 commonly) only the full header of the original email. Some Feedback
323 Providers will redact information deemed private, such as the Message
324 Recipient's Email Address.
326 Ensuring that Feedback Messages are only sent to authorized Feedback
327 Consumers is the responsibility of the Feedback Provider, with the
328 identity of each message Sender generally determined from the SMTP
329 session's connecting IP address or a message's DKIM signature domain,
330 both of which are hard to forge. This is important because Spammers
331 and other miscreants may also attempt to apply for Feedback Loops on
332 networks not belonging to them, in an attempt to steal Email
333 Addresses and other private personal or corporate information.
335 It is the responsibility of the Feedback Consumer to identify the
336 source and nature of the original message in the reports they receive
337 and take any appropriate action. The Feedback Provider does not make
338 any claims or judgments about the validity of the complaint, beyond
339 whatever technical data the Feedback Provider has themselves
340 included. Every complaint is forwarded to the Feedback Consumer
341 without human review, without any additional application of filters -
342 thus, some individual reports may prove to not be actionable.
344 The Feedback Consumer and the Feedback Provider will each evaluate a
345 Spam Complaint for validity and take whatever action deemed necessary
346 from their own perspective, and in most cases will not communicate
347 with each other which actions were (or were not) taken. Similarly,
348 it is rare for any party to communicate further with the End User who
349 initiated the complaint.
351 3. Mailbox Providers and Feedback Providers
353 In practice, a Mailbox Provider receives complaints from their End
354 Users, and is often also the Feedback Provider for those complaints
355 and is a consumer of feedback from other providers. In this document
356 we separate the Mailbox Provider and Feedback Provider functions to
357 reduce possible confusion over those cases where they are separate,
358 and we urge Mailbox Providers to also read the Feedback Consumer
359 section later in this document.
361 3.1. Benefits of Providing Feedback
363 The decision to provide a Complaint Feedback Loop service should not
364 be taken lightly. The benefits of a Feedback Loop are great, but
365 success depends on a sound plan, organized implementation, and
366 dedication to upkeep.
368 What are some benefits of providing feedback to fellow Mailbox
369 Providers and Access Providers? Primarily, other industry actors are
370 quickly alerted to Spam outbreaks on their networks.
372 End Users are becoming more aware of and comfortable with mechanisms
373 to report Spam, and a Feedback Loop does just what it implies; it
374 closes the loop. The End User's complaint makes its way back to the
375 Message Originator (not necessarily the message Sender, who may be a
376 Spammer), allowing the originator to take appropriate action. In
377 this process the mail system operator is just a messenger, relieved
378 of the responsibility of reviewing and forwarding complaints
379 manually.
381 Further, because every complaint is sent immediately - without any
382 review or analysis by the Feedback Provider - the complaint is
383 received by the Feedback Consumer in near-real-time. If the Feedback
384 Consumer is paying attention to their Feedback Stream and taking
385 appropriate action on it, the receiving Mailbox Provider receives
386 less Spam, blocks less legitimate mail, and does not have to assign
387 staff to follow up with the originating network. If the Mailbox
388 Provider does not pay attention to its Feedback Stream, and does not
389 take appropriate action, the Feedback Provider may block or otherwise
390 filter the email from that Message Originator, considering the
391 Feedback Messages to be sufficient notice.
393 What are some benefits of providing Feedback Loops to bulk Feedback
394 Consumers? As Message Recipients become more aware of and
395 comfortable with Spam reporting mechanisms, they often prefer this
396 method over the often-confusing and inconsistent "unsubscribe" or
397 "opt out" mechanisms provided by most legitimate Message Originators
398 or Senders.
400 End Users often do not remember what lists they signed up for or are
401 otherwise not confident in the established relationship they may have
402 with a Message Sender. As such, they often choose to report messages
403 as Spam to their Mailbox Providers, considering that to be sufficient
404 notification of their desire not to receive such email in the future.
406 If the Message Originator is paying attention to and taking
407 appropriate action on their Feedback Stream, it will have a happier
408 set of Message Recipients and should receive fewer Spam complaints
409 (assuming their opt-in processes are sound). If the Message
410 Originator is not paying attention to Feedback and not taking
411 appropriate action, the Mailbox Provider may consider the Feedback
412 Stream sufficient notice that messages from that originator may no
413 longer be accepted in the future.
415 3.2. Collecting Complaints
417 To produce Feedback Messages and to ensure they are useful, the
418 Feedback Provider needs to obtain near real-time complaints from the
419 Mailbox Provider's users. This is typically done by integrating the
420 feedback mechanism with the collection of Spam reports from its
421 users.
423 These reports are typically made using the "Report Spam" buttons
424 integrated into Webmail interfaces, or a proprietary desktop client
425 provided to users. Mailbox Providers may also look at deploying a
426 toolbar or MUA plug-in that provides a "Report Spam" button in the
427 MUA interface.
429 Usability studies with average users should be performed on all
430 interface changes before implementation. A "help" interface should
431 also be available to educate users about how the Spam button should
432 be used and what it does.
434 If the Mailbox Provider does not offer its customers a mail client
435 with this button, then the Feedback Provider's chances for providing
436 an effective Feedback Loop are slim. While it is possible for the
437 Mailbox Provider to instruct its customers to forward unwanted mail
438 to a central location and for the Mailbox Provider to explain how to
439 ensure the report includes headers and bodies, the success rate of
440 customers doing so tends to be low. Even those complaints that do
441 contain all required information might prove difficult to parse, as
442 variations in formatting and content types will lead to automated
443 tools being consistently updated with new logic blocks for each
444 variation that occurs.
446 3.3. Creating Reports
448 It is recommended that Feedback Messages be sent using the standard
449 Abuse Reporting Format, to facilitate uniformity and ease of
450 processing for all consumers of feedback. This will also enable the
451 Feedback Provider to extensively automate the processes of generating
452 and sending Feedback Messages and of analyzing complaint statistics.
453 This format is described further in Appendix 1.
455 Feedback Loops are usually (but not always) keyed to the "last hop"
456 IP address (i.e., the IP address that passed the unwanted message to
457 the Mailbox Provider's servers). Consequently, the Feedback Provider
458 must be able to process the header from each complaint to determine
459 the IP address for the complaint.
461 A Feedback Provider may wish to provide as part of its Feedback Loop
462 other information beyond Spam complaints that Feedback Consumers may
463 find valuable. It might include summary delivery statistics (volume,
464 inbox delivery rate, Spam trap hits, etc.) or other data that the
465 Feedback Provider may deem pertinent to Feedback Consumers.
467 Any mature Feedback Loop system will produce situations in which the
468 Feedback Consumer may have follow-up questions or have other
469 information to provide in regards to the feedback. Feedback Messages
470 should include contact information (typically an Email Address) for
471 the Feedback Consumer to use for such questions, and ideally the
472 contact Email Address will feed into a ticket system or other
473 automated tool used by the Mailbox Provider's postmaster and/or anti-
474 abuse staff for handling general email delivery issues.
476 3.4. Policy Concerns
478 3.4.1. Privacy & Regulatory Compliance
480 Feedback Messages provide information relayed by Feedback Providers
481 from a Mailbox Provider's End Users to the Feedback Consumer. There
482 might not be any concerns with relaying non-private data to a third
483 party. However, the information provided in the complaints generated
484 by the user must be evaluated and any data deemed private may need to
485 be removed before distributing to a third party, per local policy.
486 For example, the Recipient's or reporter's Email Address and IP
487 address may be categorized as private data and removed from the
488 feedback report that is provided to the Feedback Consumer. Privacy
489 laws and corporate data classification standards should be consulted
490 when determining what information should be considered private.
492 Information provided by the Feedback Consumer to the Feedback
493 Provider for the purpose of enrolling in the Feedback Loop should
494 also be kept private. It should only be shared or used for the
495 purposes explicitly agreed to during the enrollment process (see
496 Terms of Use below.)
498 Feedback Loops inevitably span country borders. Local laws and
499 regulations regarding distribution of information domestically and
500 internationally need to be considered when implementing a Feedback
501 Loop program. For example, in some European countries, data exchange
502 requires permission from governing bodies. The terms and
503 circumstances surrounding the exchange of data need to be clearly
504 defined and approved.
506 3.4.2. Terms of Use
508 A written Terms of Use agreement should be provided by the Feedback
509 Provider and agreed to by the Feedback Consumer before any feedback
510 is provided. The following concepts should be considered when
511 drafting the terms of use agreement:
513 o Data provided in Feedback Messages are provided to a specific,
514 approved entity. Information should not be transmitted outside of
515 the intended, approved Recipient. Any inappropriate use of the
516 information can lead to immediate termination from the feedback
517 program.
519 o Consumers of Feedback have a responsibility to keep the
520 information they provide for Feedback Loop purposes-such as abuse
521 contact information, IP addresses and other records-accurate and
522 up to date.
524 o The providing of Feedback information is a privilege and needs to
525 be treated appropriately. It does not entitle the consumer of the
526 feedback to any special sending privileges.
528 o Approval and continued enrollment in the program is a privilege
529 that can be denied or revoked for any reason and at any time.
531 3.5. Handling Requests to Receive Feedback
533 There should be a streamlined application process for receiving
534 feedback and the vetting of such applications. This vetting may be
535 stringent in cases where the Mailbox Provider chooses to tie its
536 Complaint Feedback Loop program to a whitelist. Criteria may involve
537 the following:
539 o Cross checking that the requestor is indeed authorized to receive
540 feedback for the IP addresses concerned.
542 o Gathering other information such as whether the IPs are an ISP
543 smarthost network, a webhosting farm, an email marketing or
544 Mailing List service or other entity.
546 o Requesting information such as a link to the policies of the
547 requestor, contacts to send Feedback Messages, and escalation
548 points of contact.
550 Ideally, enrollment will be a two step process, with the applicant
551 filling out a form and being required to receive and acknowledge a
552 confirmation email (best sent to abuse@ or postmaster@ the domain in
553 question) before the applicant's request is even put into the queue
554 for the Feedback Provider to process.
556 Ownership of IP addresses can and should be crosschecked by means of
557 origin ASN, whois/rwhois records, Reverse DNS of the sending hosts,
558 and other sources. This can be automated to some extent, but often
559 requires some manual processing.
561 3.5.1. Application Web Site
563 Applications for Feedback Loops can be accepted on a stand-alone
564 website or can be part of the Mailbox Provider's postmaster site.
565 Regardless, the website for the Complaint Feedback Loop program
566 should contain other content specific to the Feedback Loop, including
567 FAQs for the Feedback Loop program, the Terms of Service for the
568 Feedback Loop, and perhaps a method for enrolled parties to modify
569 their existing enrollments.
571 The website should also provide the Feedback Consumer with general
572 information on how the feedback will be sent, including:
574 o Report Format (ARF or otherwise)
576 o Sending IP addresses and/or DKIM "d=" string
578 o "From" email address
580 3.5.2. Saying No
582 Denial of a feedback loop application may be appropriate in certain
583 cases such as:
585 o Where the Feedback Provider suspects "gaming" of delivery policies
586 via the Feedback received, with attempts to pollute Feedback Loop
587 metrics by, for example, creating bogus accounts and reporting
588 false negatives with these, to offset the negative reputation
589 caused by high complaint rates.
591 o In the case where the Feedback Provider has decided to block the
592 Message Originator's IP space for which feedback has been
593 requested on the grounds that email from that originator has a
594 sufficiently negative reputation that it will not be delivered at
595 all. This is somewhat on the lines of a global unsubscribe of the
596 Message Provider's users from the originator's lists, which would
597 make rendering additional feedback unnecessary.
599 It is recommended that the Feedback Provider send notification if an
600 application is denied. Additionally, they should maintain a
601 documented, clear and transparent appeals process for denial of
602 requests. This process can be as simple as the prospective Feedback
603 Consumer replying to the denial email requesting review or escalation
604 to a team lead, which also cites reasons why the application should
605 be reviewed.
607 3.5.3. Automation
609 For a Feedback Loop to be cost-effective and usable for large
610 Feedback Consumers and Feedback Providers, it must be possible for
611 reports to be generated and processed automatically without any human
612 interaction. On the other hand, it should be possible for small
613 Feedback Consumers to handle a low volume of reports manually,
614 without requiring any automation.
616 In automating the feedback process, the consumer of the Feedback
617 Stream must receive enough information about the report that it can
618 take appropriate action, typically to remove the Recipient from the
619 Mailing List it is sending a report about. The Recipient's Email
620 Address is not enough, as the Recipient may be on several Mailing
621 Lists managed by the Feedback Loop consumer and only need to be
622 removed from the particular list reported.
624 Also, some producers of Feedback Loops might redact the Recipient's
625 Email Address for privacy reasons. Effective implementation of a
626 Complaint Feedback Loop requires that the Feedback Provider put in
627 place as many automated processes and tools as feasible to handle all
628 aspects of the process. Feedback Providers should seek to automate
629 or script the following:
631 o Accepting and validating Feedback Loop Applications from
632 prospective Feedback Consumers.
634 o Processing requests to determine whether or not they meet the
635 Feedback Provider's criteria for enrollment in the program.
637 o Accepting Spam complaints from End Users; this will form the bulk
638 (and perhaps sole) component of the feedback sent by the Feedback
639 Provider.
641 o Production of Feedback Messages from Spam complaints.
643 o Production of other Feedback Loop artifacts as chosen by the
644 Feedback Provider.
646 o Optionally, provision of a mechanism for Feedback Consumers to
647 further engage a Feedback Provider about a given feedback message.
649 o Ongoing validation of Feedback Loop enrollments to determine if a
650 currently enrolled IP address or network merits continued
651 inclusion in the Feedback Loop.
653 o Optional periodic emails to Feedback Consumers to determine if
654 their enrolled Email Addresses are still valid.
656 3.6. Ongoing Maintenance
658 It is recommended that self-service maintenance be offered to
659 Feedback Consumers, to the extent practicable. The more they can do
660 themselves, the less you have to do.
662 3.6.1. IP Validation
664 The criteria that a Feedback Provider uses to validate a Feedback
665 Loop application may change over time. It is a near certainty at
666 least some subset of Feedback Consumers enrolled to receive feedback
667 will at some point after enrollment fail to meet those criteria,
668 regardless of whether or not the criteria change.
670 The Feedback Provider should put in place tools to periodically re-
671 validate all Feedback Consumers enrolled in its Feedback Loop system
672 against its current criteria. Additionally, the Feedback Provider
673 will likely have objective criteria for remaining in the Feedback
674 Loop for enrolled Feedback Consumers, and so the enrolled consumers
675 should be validated against those criteria, as well.
677 3.6.2. Email Address Validation
679 Just as some Mailing List software has built into it the ability to
680 send periodic "probe" emails to subscribed addresses to validate
681 them, so too should the Feedback Provider develop tools to send
682 similar emails to the addresses receiving Feedback Messages to ensure
683 that they are valid. This is especially true for the addresses that
684 are not the abuse@ and postmaster@ addresses originally used as part
685 of the enrollment acknowledgment step. Over time, people may change
686 employers, or at least roles, and validating the Email Addresses
687 associated with an IP is one way for the Feedback Provider to ensure
688 that Feedback Messages are still being accepted and acted upon by the
689 Feedback Consumer.
691 3.6.3. Feedback Production Changes
693 Updating Feedback Consumers when one's own IP addresses are changing
694 is an important aspect of Feedback Loop maintenance. The exact
695 format, automation, and other considerations of these updates are
696 outside the scope of this document, but are topics worthy of further
697 discussion and eventual documentation.
699 4. Feedback Consumers
701 A Feedback Consumer receives its Feedback Messages after its
702 submitted Application for a Complaint Feedback Loop is approved. A
703 Feedback Consumer will usually have Complaint Feedback Loop
704 subscriptions set up with multiple Feedback Providers. Different
705 Feedback Streams may be in different formats or include different
706 information, and the Feedback Consumer should identify a process to
707 organize the data received and take appropriate action.
709 A Feedback Consumer, Mailbox Provider or Access Provider (i.e., a
710 hosting company or ISP) will use this Feedback to identify network
711 compromises, fraudulent accounts, policy violations and other
712 concerns. The Feedback Loop provides real-time visibility into Spam
713 complaints from Message Recipients, greatly enabling these Mailbox
714 Providers to mitigate Spam propagating from their networks.
716 Senders of bulk email should use the complaints to make decisions
717 regarding future mailings. Such decisions may include one or more of
718 the following: modification of email frequency, branding, opt-in
719 practices, or list management.
721 The authors of this document urge those who are solely Feedback
722 Consumers to also read the previous sections for Mailbox Providers
723 and Feedback Providers. This will provide the proper context of the
724 recommendations included below.
726 Further recommendations for bulk senders may be found in the MAAWG
727 Sender Best Communications Practices [3].
729 4.1. Preparation
731 Feedback Consumers need to prepare to process and act on feedback
732 before asking to receive it. At a minimum, make sure to have:
734 1. "Role" Email Addresses such as abuse@ and postmaster@. The
735 person who applies for the Feedback needs to make sure they have
736 access to these Email Addresses. Feedback Providers often send a
737 confirmation link to those accounts to prevent End Users,
738 Spammers or competitors from signing up for Feedback for which
739 they are not authorized.
741 2. A dedicated Email Address to receive the Feedback Messages, such
742 as fbl@example.com or isp-feedback@example.com. While not
743 required, this will make it easier for you to process the reports
744 you receive.
746 3. A list of IP addresses that you want to receive Feedback Messages
747 for, making sure you can prove the ownership of the IP addresses
748 and associated domains. Feedback Providers often require that:
750 * Reverse DNS for each IP shares the domain of either the
751 applicant's Email Address or the Email Address that will be
752 receiving the Feedback Messages.
754 * WHOIS information for the IPs requested is obviously
755 associated with the domain name.
757 4. Be prepared to provide contact information such as name, Email
758 Address, phone number and other relevant information.
760 5. If the application form asks for your credit card number or other
761 financial information, it is assuredly a scam.
763 4.2. What You'll Receive
765 Once a Feedback Consumer has signed up to receive feedback from a
766 Feedback Provider it may also receive several other sorts of
767 delivery-related reports. This includes Feedback Messages,
768 administrative messages and other messages.
770 4.2.1. Feedback Reports
772 Feedback Messages are the main emails generally associated with a
773 Feedback Loop. Each time a Recipient hits the "This is Spam" button,
774 the Feedback Loop system creates a boilerplate report with a copy of
775 the original email attached and sends it to the consumer of the
776 Feedback Loop.
778 We'll discuss handling feedback reports in the next section.
780 4.2.2. Administrative Messages
782 Administrative messages will typically be sent to the Email Address
783 provided for contacting the person who originally applied for the
784 Feedback Loop, rather than to the address provided for handling the
785 Feedback Messages. These messages are likely to be sent infrequently
786 and irregularly, but it is important they are seen by the person
787 managing the Feedback Stream processor in a timely manner. It is
788 usually a poor idea to have these sent to an individual's Email
789 Address since they may be lost if that person is on vacation, changes
790 position within the company or leaves the company.
792 Instead they should be sent to a role account that goes to a
793 ticketing system or "exploded" to multiple responsible parties within
794 the organization. If there is not already an appropriate role
795 account such as support@ or noc@ that reaches the right team, it may
796 be a good idea to set up a dedicated alias such as fblmaster@ to sign
797 up for all Feedback Loops.
799 4.2.3. Report Cards
801 The detail in a Report Card can vary greatly. Feedback Providers
802 might send a regular summary of traffic levels and complaint rates
803 seen, perhaps just an overview or possibly broken down by source IP
804 address or some other identifier. Sometimes these may be sent just
805 when some metric (typically a complaint rate) reaches a level that
806 causes the Mailbox Provider to notify the Feedback Consumer there may
807 be a problem developing that needs to be investigated and addressed.
808 At the other extreme, some report cards will contain almost no useful
809 data at all, just a warning that the Message Originator is causing
810 complaints-with the implication that its email will be blocked unless
811 it is improved.
813 Report cards are human readable, since there are not currently any
814 standard machine readable formats and the information they include,
815 both the provided metrics and their semantics, vary widely from one
816 Mailbox Provider to another. They are useful reference overviews for
817 a Message Originator to monitor the overall perceived quality of the
818 email it sends and, in the case of ESPs, perhaps which customers are
819 causing higher than expected rates of complaints. They can also be
820 the only warning of serious problems prior to email being blocked
821 altogether by the receiving Mailbox Provider. It is critical they be
822 are seen by someone handling delivery issues for the Message
823 Originator, so again, they should be handled by an email alias that
824 is always read.
826 Report cards also contain useful data to track mechanically and
827 perhaps report on trends, though as their contents vary it is hard to
828 generalize what use might be made of them. At the very least the
829 "warning" report cards are something that should be visible on an
830 ESP's business intelligence or delivery dashboard.
832 4.3. Handling Feedback Messages
834 Mailbox Providers sending feedback may have published policies as to
835 how they expect a Feedback Consumer to use Feedback Messages or may
836 expect the Feedback Consumer to simply "make the problem stop." In
837 practice, this mostly boils down to three things:
839 o First, where the consumer of the feedback has some specific
840 control over sending the email, it is expected not to send email
841 of the same type to the same Recipient again.
843 o Second, it should identify the underlying problem (if any) and fix
844 it so that it receives fewer reports of that type in the future.
846 o Third, it is not necessary to inform the Mailbox Provider,
847 Feedback Provider or their End User(s) of which actions have been
848 or will be taken in response to automated complaint feedback.
850 If the Feedback Consumer is a separate entity from the Message
851 Originator, the two entities are expected to work together to resolve
852 any problem.
854 4.3.1. Unsubscription or Suppression
856 A Sender (whether author or originator) of commercial email should
857 treat the Feedback Message similarly to an unsubscribe request,
858 ensuring that no further email from that list is sent to that
859 Recipient, either by removing the email from that list or adding it
860 to the associated suppression list. It needs to use its best
861 judgment, keeping in mind the goal of reducing future complaints, as
862 to how broadly to apply that unsubscribe. Suppressing the address
863 across an entire ESP is likely too broad. But if a single Feedback
864 Consumer (or customer of an ESP) has multiple segmented lists, then
865 suppressing them across all those lists is probably a good idea.
867 It is universally acknowledged that not all complaints are
868 intentional; for example, Recipients might accidentally hit the wrong
869 button or mark an entire mailbox as Spam. However, it is best for
870 Feedback Consumers to assume the Recipient does not want more email
871 and to suppress mail to the Recipient in all but fairly extreme cases
872 such as a Mailing List the Recipients pay to receive, email from a
873 genuine company to its valid employees or email from an Access
874 Provider or Mailbox Provider to its users.
876 This gets more complex in the case of transactional mail-mail that is
877 tied to some other service, such as ticket purchase confirmations or
878 billing statements. In that case the Feedback Consumer has to,
879 again, use its best judgment based on the specific situation. In
880 some cases the right thing to do may be to communicate with the
881 Recipient via another channel, such as a message on a website used
882 for the service; i.e., "You reported your notification mail as Spam
883 so we are not going to send you any more messages unless you tell us
884 otherwise."
886 In some cases the best thing to do may be to ignore the Feedback
887 Message. For example, if your customer has reported as Spam the
888 airline tickets he purchased and you emailed him, he probably did not
889 mean it and he is going to be very annoyed if you do not send him the
890 other tickets he has ordered. In rare cases it might be appropriate
891 to suppress email to the Recipient, but also to suspend access to a
892 service he or she uses until the Recipient confirms a desire to
893 receive the associated email. In all these cases the important goal
894 is to keep the customer happy and reduce future complaints, even in
895 the apparently paradoxical situations where the way to do that is to
896 ignore their Feedback. In the real world, however, these are a small
897 minority of cases.
899 4.3.2. Trending and Reporting
901 Counting the Feedback Messages received over regular time periods can
902 provide much useful information to ISPs, ESPs and other Feedback
903 Consumers, especially when broken down appropriately.
905 An ISP (Mailbox Provider or Access Provider) might want to count the
906 number of Feedback Messages a particular customer or IP address
907 causes in a given day. If there is a sudden increase from a
908 particular customer or server it may be a sign that a Spammer has
909 signed up or a system has been compromised. If there is a high level
910 of complaints about a particular customer it may be worth
911 investigating to see if there is a reason for that. For example, ten
912 feedback messages a day would be a sign of serious problems in some
913 cases, but might be perfectly reasonable "background" levels for a
914 Message Originator that sends 300,000 emails a month. If the count
915 shows there may be a problem, the ISP can dig down and look at the
916 emails that are being reported to determine the underlying cause.
918 An ESP can do similar things but can also break the data down in more
919 ways-by customer, by Mailing List, by campaign. An ESP also has
920 access to more information; it knows how many emails were delivered
921 to the receiving Mailbox Provider over a given time period. As a
922 result, it can estimate the number of complaints divided by the
923 number of emails sent, which is often a more useful metric than the
924 absolute number of reports. This is critical data for ESPs to track
925 over time because it can help identify and quantify problem
926 customers.
928 An individual Feedback Consumer, whether sending their own email or
929 using an ESP, can acquire at least some information from Complaint
930 rates. A spike in complaints on an otherwise stable list might be a
931 sign there is a problem with address acquisition, if the spike is due
932 to reports from new subscribers. If it came from older subscribers,
933 it might be attributable to content of a particular mailing that was
934 not well received. Perhaps the branding was not recognized or the
935 content was offensive or inappropriate for the list.
937 The Complaint rate is determined by the number of Feedback Messages
938 received over a given time period divided by the number of emails
939 delivered to the associated Mailbox Provider over the same period.
940 It is an obvious and useful metric to track but there are a few
941 subtle issues to be aware of.
943 One issue is that Feedback Messages tend to be counted on the day the
944 complaint was sent, which is the day the original message was read by
945 the Recipient. That may not be the same day that the message was
946 sent. A simple example is a Message Originator that sends email
947 regularly Monday through Friday will often see a high complaint rate
948 on Saturday. The absolute number of Feedback Messages sent by people
949 catching up with the week's email over the weekend may not be that
950 high. But since hardly any email is sent on Saturday, a fairly
951 reasonable number of complaints ends up being divided by a very small
952 number of total sent emails, possibly even zero, which would break
953 the reporting engine. This can lead to a complaint rate that seems
954 to range anywhere from suspicious to ridiculous. Consequently, large
955 Mailing Lists that are virtually silent on the weekend could end up
956 receiving more complaints on a Saturday than email they sent that
957 day, leading to complaint rates of well over 100%.
959 Another arithmetic issue to consider is the interaction between the
960 inbox, the bulk folder and the "This Is Spam" button. If an
961 organization sends a high volume of email that has a terrible
962 reputation, it may end up with perhaps 500 of its 10,000 mails in the
963 inbox and the remaining 9,500 in the bulk folder. If it gets 10
964 Feedback Messages and divides that by the 10,000 emails it sent, it
965 will get a very respectable 0.1% complaint rate. But the Mailbox
966 Provider is probably going to calculate the Complaint rate by
967 dividing the number of emails delivered to the inbox instead-giving a
968 2% Complaint rate which is probably grounds for immediate blocking.
969 So if one sees a large difference between a Complaint rate as
970 reported by a Mailbox Provider or other reputation system and the
971 rate calculated from raw delivery numbers, it is important to look
972 closely at the data.
974 4.4. Automatically Handling an Incoming Feedback Stream
976 Even when signing up for a Feedback Loop is partly automated,
977 modifications to it tend to be handled manually. Even something as
978 trivial as changing the Email Address that the Feedback Messages are
979 sent to can be time consuming and can cause significant overhead to
980 the Feedback Provider. Multiply that by a dozen Feedback Loops and
981 getting it right the first time can save a lot of time and energy.
983 Even the smallest of users should create a unique email alias for
984 each Feedback Loop. There are several advantages to this, even if
985 they all deliver to the same person's inbox at first. Sending each
986 Feedback Loop to a unique address makes it immediately clear which
987 Feedback Provider was the source of any given report, even if it is
988 sent from an inconsistent From address. It makes it easy to put
989 lightweight pre-processing in place for a particular Feedback Stream,
990 if needed. And it makes it easy to discard Feedback Messages if
991 needed (though only temporarily, as it could be very bad for one's
992 reputation to miss a changing trend.) If a Feedback Consumer needs
993 to scale up, it is easy to point the existing aliases at a Feedback
994 Loop processing engine.
996 If an organization might possibly scale up appreciably in the future
997 or consider outsourcing its Feedback Loop processing to a third party
998 Feedback Consumer, it may be even better to create a subdomain for
999 handling Feedback Streams. For example, example.com might use
1000 fbl-aol@fbl.example.com to accept its AOL Feedback Loop, allowing it
1001 to delegate the whole of @fbl.example.com to a Feedback Loop handling
1002 appliance or service, should the need arise.
1004 Small Feedback Consumers, with lists of no more than a few thousand
1005 Recipients, or small ISPs with no particular history of problems
1006 should be able to handle feedback reports with little or no
1007 automation, as an ARF message should be readable in most mail
1008 clients. It may be worthwhile to add some very lightweight
1009 processing to the inbound Feedback Messages to make them easier to
1010 triage from other email client. For example, arffilter.c [4] can
1011 annotate the subject line of inbound Feedback Messages with the IP
1012 address being reported, making it easier to see patterns of problems
1013 by sorting the messages by subject line in the mail client. To
1014 identify which Recipient is causing the feedback to be sent, small
1015 Feedback Consumers should add some of the automation mentioned below
1016 that is intended for larger Feedback Consumers.
1018 Larger Feedback Consumers need to be able to automate the handling of
1019 Feedback, as it scales beyond the ability of someone to manage
1020 manually quite quickly. The main capability a Feedback Loop
1021 processor needs is to extract some relevant data from the report,
1022 reliably. The most important bits of data tend to be:
1024 o The Recipient of the original email
1026 o The Mailbox Provider originating sending the Feedback Message
1027 (some Feedback Providers operate on behalf of multiple Mailbox
1028 Providers)
1030 o The customer who sent the original email (in the case of an ESP or
1031 Mailbox Provider)
1033 o The campaign and Mailing List that the original email belonged to,
1034 if any
1036 o (Possibly) the IP address from which the original email was sent
1037 from, and any [DKIM] signature domain
1039 The last isn't vital, but may be a useful piece of data in diagnosing
1040 delivery problems.
1042 It can be very difficult to extract some of this data without some
1043 upfront work before email is sent. Some Feedback providers will
1044 redact the Email Address in the To: header or Recipient Email
1045 Addresses anywhere within the message. Some will delete any
1046 identifying information they can. It may be possible to identify the
1047 End User based on the Message-ID, Subject line and Received header
1048 timestamps, if there is access to the mail server logs, but at best
1049 it is painful and time-consuming, and only worth doing in an
1050 exceptional case.
1052 The solution is similar to the one used for automated bounce handling
1053 using VERP -- embed the information in the email in a way that it is
1054 unlikely to be removed by Feedback providers but is easy to recognize
1055 in the email. That information may already be there in a form such
1056 as VERP if the Return-Path header is included in the embedded email,
1057 or included in one-click unsubscribe links included in the body of
1058 the email. If it is not already there, a good place to add the
1059 information is in the local part of the Message-ID as that is often
1060 used to track the progress of email through Delivery. It is often
1061 available from log files as well as in the headers of the original
1062 message included in the Feedback Message.
1064 There are several good ways to store the mapping between Recipients
1065 and identifiers in mail. For a database backed ESP or bulk sender, a
1066 synthesized database primary key can be used. It is very small, and
1067 very opaque, and it is not expensive to retrieve the associated data
1068 from the main database-but it is impossible to read by hand.
1069 Therefore, it needs automation with access to the core database to
1070 map the key onto the actual data.
1072 Recording the required information directly within the email but
1073 encrypting it with strong or weak encryption, removes the need for
1074 database access to extract the data. However, it still does need
1075 some automation.
1077 A hybrid approach with the various bits of data stored separately but
1078 having some pieces either encrypted or obfuscated is possible by just
1079 including a database ID. This can provide a good compromise where
1080 most of the data is not immediately obvious to third parties but
1081 patterns in it can be recognized by eye. For example, a Message ID
1082 of "esp-423-27-42460@example.com" is opaque to a third party, but
1083 someone familiar with the format can tell that it is a Message ID
1084 added by the system. In this case it starts with "esp" followed by
1085 three numbers separated by dashes, meaning it is from customer 423,
1086 campaign 27 and the Recipient has the database key 42460. Even
1087 decoding this manually, while it may not be possible to identify
1088 customer number 423, it is easy to recognize that 10 Feedback
1089 Messages in a row relate to the same customer. From experience, it
1090 is not unusual for the vast majority of reports at an ESP to be about
1091 a very small number of customers, and one learns their customer IDs
1092 very quickly.
1094 Once a Message Originator embeds Recipient identifiers in an easily
1095 recognizable format in all its mail, it is quite easy for a Feedback
1096 Message processor to extract that with a conventional expression
1097 match and possibly a couple of database queries. It can then
1098 suppress that Email Address and record the customer and campaign for
1099 future reporting. In the case where the Feedback Messages are
1100 recorded in a ticketing system, it can also annotate the tickets with
1101 that data (again, for reporting and trending analysis).
1103 A Feedback Message processor is often bolted onto the side of an
1104 already complex bulk mail generator, making it difficult to reliably
1105 suppress mail to the Recipient. If the delivery data is stored in a
1106 way that makes it easy to convert into the same format as the VERP
1107 string used for bounce processing then the Feedback processor can
1108 create a "fake" hard bounce and send it to the existing bounce
1109 processor, suppressing mail to that address.
1111 Mailbox Providers and Access Providers also need to automate Feedback
1112 processing. They are usually less interested in the details about
1113 the message and more interested in the IP address and which customer
1114 sent it. In most cases the IP address can be extracted easily from
1115 ARF metadata, while in other cases it may need to be extracted from
1116 the Received: headers embedded in the included original message.
1117 That data can then be used both for automated forwarding of Feedback
1118 Messages to the originating customer, if the ISP feels that is
1119 appropriate, and also for reporting on complaint levels across the
1120 ISP's customer base.
1122 5. Conclusion
1124 Whether you are acting as a Mailbox Provider or a Feedback Consumer,
1125 Complaint Feedback processing can be complex and scary - or, with
1126 some intelligence and automation, simple and easy. In either case,
1127 it is an important and necessary tool for detecting messaging abuse
1128 and ensuring end-user satisfaction.
1130 MAAWG encourages all Mailbox Providers to offer Feedback of whatever
1131 form is appropriate for their local user base and legal framework,
1132 and encourages all Senders of email to consume and act upon any
1133 Feedback available. An actively maintained list of known Feedback
1134 Loops can be found at
1135 .
1137 6. Acknowledgments
1139 This document was written within the MAAWG Collaboration Committee.
1140 The project was led by John Feaver and Kate Nowrouzi. The primary
1141 authors were Steve Atkins, Christine Murphy Borgia, J.D. Falk, John
1142 Feaver, Todd Herr, John Levine, Heather Lord, Kate Nowrouzi, and
1143 Suresh Ramasubramanian.
1145 The document was edited by John Levine, J.D. Falk, and Linda Marcus.
1146 Further editing and formatting required for this version to be
1147 published by the IETF was performed by J.D. Falk, with advice from
1148 Barry Leiba and Murray Kucherawy.
1150 6.1. About MAAWG
1152 MAAWG [5] is the largest global industry association working against
1153 Spam, viruses, denial-of-service attacks and other online
1154 exploitation. Its' members include ISPs, network and mobile
1155 operators, key technology providers and volume sender organizations.
1156 It represents over one billion mailboxes worldwide and its membership
1157 contributed their expertise in developing this description of current
1158 Feedback Loop practices.
1160 7. Security Considerations
1162 Security and privacy considerations are discussed in many sections of
1163 this document, most notably Section 2, Section 3.4, and Section 3.5.
1165 8. IANA Considerations
1167 None.
1169 RFC Editor: Please remove this section before publication.
1171 9. Informative References
1173 [DNS] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
1174 RFC 1034, November 1987.
1176 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1177 Extensions (MIME) Part One: Format of Internet Message
1178 Bodies", RFC 2045, November 1996.
1180 [DomainKeys]
1181 Delany, M., "Domain-Based Email Authentication Using
1182 Public Keys Advertised in the DNS (DomainKeys)", RFC 4870,
1183 May 2007.
1185 [DKIM] Allman, E., Callas, J., Delany, M., Cisco Systems, Inc.,
1186 and M. Thomas, "DomainKeys Identified Mail (DKIM)
1187 Signatures", RFC 4871, May 2007.
1189 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
1190 October 2008.
1192 [RFC 5322]
1193 Resnick, P., Ed., "Internet Message Format", RFC 5322,
1194 October 2008.
1196 [RFC 5598]
1197 Crocker, D., "Internet Mail Architecture", RFC 5598,
1198 July 2009.
1200 [MARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An
1201 Extensible Format for Email Feedback Reports", RFC 5965,
1202 August 2010.
1204 [1]
1207 [2]
1210 [3]
1213 [4]
1215 [5]
1217 Appendix A. Abuse Reporting Format (ARF)
1219 A.1. A Brief History
1221 The approach used by the first Feedback Loop to be deployed -- the
1222 "scomp" system at AOL -- was to send an entire copy of the message to
1223 the consumer of the Feedback Loop. It expected that large Feedback
1224 Consumers would embed sufficient information in the email so they
1225 could identify which Message Recipient had complained.
1227 That worked well enough when there was only a single entity providing
1228 feedback, but as other Mailbox Providers started to offer Feedback it
1229 became clear that it would be useful for the Feedback Provider to be
1230 able to add some additional information, both machine readable and
1231 human readable, to the report. This led to ARF, the Abuse Reporting
1232 Format, which quickly became the de facto standard for Feedback
1233 Messages.
1235 Today ARF is used by nearly all Feedback Providers, both within MAAWG
1236 and without, constituting the vast majority of all Feedback Messages
1237 generated worldwide. ARF is recognized by all MAAWG members that
1238 have developed software or services that consume and process Feedback
1239 Messages. There are no competing standards for reporting individual
1240 messages.
1242 ARF has now been published by the IETF as RFC 5965 [MARF].
1244 A.2. Structure of an ARF Message
1246 An ARF report (Feedback Message) is sent by email, with one message
1247 sent for each Spam report made. It consists of three sections, in a
1248 standard [MIME] message format called multipart/report.
1250 The first section contains human-readable plain text, primarily for
1251 the benefit of small Feedback Consumers who are handling reports
1252 manually. It typically contains boilerplate text explaining that
1253 this is a Feedback Message and providing URLs to other data such as
1254 contact information for the Feedback Provider or Mailbox Provider
1255 that originated the feedback message.
1257 The second section contains some machine readable information,
1258 including the version of the ARF protocol used and the type of report
1259 it is ("abuse," "fraud," or other label). It also might include some
1260 optional information about the email being reported, such as the
1261 original Envelope Sender or the time the mail was received. In
1262 theory the information in this section can be used to mechanically
1263 route and triage the report, though in current practice most Feedback
1264 Messages are treated identically. As a result, this section is often
1265 ignored entirely by Feedback Consumers who prefer to process the
1266 third section themselves.
1268 The third section of the report consists of a copy of the original
1269 email that the report is about, as a standard [MIME] message/rfc822
1270 attachment. While ideally this would be an unmodified copy of the
1271 original email it is likely that many producers of reports will
1272 modify or "redact" some elements of the report, especially the Email
1273 Address of the Recipient, due to privacy or other legal concerns.
1275 The strict technical specifications of ARF, as well as some example
1276 reports and tools to handle the format, can be found at
1277 ,
1278 , and in [MARF]
1280 Appendix B. Using DKIM to Route Feedback
1282 Historically, the IP address of the "last hop" - the MTA that
1283 transferred a message into the receiving Mailbox Provider's
1284 administrative domain - was the sole reliable identifier used to
1285 denote the source of a message. With the emergence of authentication
1286 technologies such as [DKIM], another identifier can now be used;
1287 specifically, the authenticated domain associated with a message.
1288 This domain is the "d=" value in a DKIM-Signature header field.
1290 In a social or policy context, applying a DKIM signature to a message
1291 is tantamount to stating, "I take responsibility for this message."
1292 The DKIM signature is most often applied by the author or originator
1293 of a message, which may be far upstream of the "last hop" MTA. This
1294 is true particularly in cases where the originator's intended
1295 Recipient email address is configured to forward to another Recipient
1296 email address. Stories of users who have strung together multiple
1297 forwarding accounts are not uncommon, and these users are unable to
1298 complain effectively about Spam because their Mailbox Providers
1299 cannot easily or reliably follow the path of a message back to the
1300 initial originator.
1302 A single DKIM "d=" value may be used across multiple servers with
1303 multiple IP addresses. Servers may be added or removed at any time
1304 without changing the dynamics of the DKIM signature. When a Feedback
1305 Loop is based on the IP address, the Feedback Consumer must contact
1306 the Feedback Provider to change its subscription options every time
1307 an IP address needs to be added or removed. But when a Feedback Loop
1308 uses DKIM, no reconfiguration is necessary because the signing domain
1309 does not change.
1311 One recurring concern with DKIM, however, is that ESPs often send
1312 messages addressed with hundreds or thousands of customer domains yet
1313 want to receive Feedback Messages for all of these domains. This was
1314 particularly difficult with [DomainKeys] (the predecessor to DKIM),
1315 which tied the "d=" to the "From" header field. DKIM removed this
1316 tie, so it is simple for an ESP to use a domain of its own to sign
1317 the message and sign up for Feedback regarding all messages signed
1318 with that domain. Such a signature may be in addition to, or instead
1319 of, signatures from the various client domains. While there are
1320 still many unknowns related to reputation (which will be addressed in
1321 a future MAAWG document), this is clearly an appropriate use of DKIM
1322 to take responsibility (and receive Feedback) for a message.
1324 Appendix C. Unsolicited Feedback
1326 Is it always necessary for a Feedback Consumer to apply for a
1327 Feedback Loop or is it permissible for a Feedback Provider to
1328 configure a Feedback Loop for a Feedback Consumer without an explicit
1329 request? There is continuing debate about whether this is an
1330 acceptable practice, and MAAWG is neither endorsing nor condemning
1331 such activity at this time.
1333 That said, if a Feedback Provider chooses to send Feedback without
1334 being asked first, certain guidelines should be followed. In
1335 general, it should make prudent decisions to minimize the negative
1336 impact on Mailbox Providers and Access Providers.
1338 C.1. Guidelines
1340 This should only be done for Mailbox and Access Providers.
1342 This should only be done after attempting to contact the provider to
1343 ask if it is possible to set up a Feedback Loop via the normal
1344 practice.
1346 These Feedback Loops should only be set up to send to the published
1347 abuse address from the provider's WHOIS record.
1349 C.2. Pros
1351 Feedback Consumers may not realize they have abuse problems until
1352 they begin receiving the spam complaints.
1354 Feedback Consumers may not be aware of Feedback Loops and may
1355 appreciate the additional data feed.
1357 Upstream providers have an additional information stream to help them
1358 identify problem customers.
1360 Spam coming from a network is abuse; therefore it is appropriate to
1361 send reports of the abuse back to the Mailbox Provider or Access
1362 Provider. Setting up a Feedback Loop automates the process.
1364 C.3. Cons
1366 Creates confusion for Feedback Consumers if they did not apply and do
1367 not understand why they are suddenly receiving complaints.
1369 It can conflict with existing Terms of Service because a new feed of
1370 information is available. For example, if a provider has a policy to
1371 terminate service after a certain number of abuse complaints and it
1372 starts receiving unexpected Feedback Loop complaints, it may either
1373 be forced to terminate customers that did not have a previous issue
1374 or may be required to update its TOS and AUP agreements.
1376 Upstream providers do not have access to the mail being sent by their
1377 customers, so they cannot tell whether bulk mail complaints
1378 constitute a problem.
1380 The listed abuse address may not be the correct place for automated
1381 spam complaints to be sent.
1383 The listed abuse address may feed into a ticketing system which is
1384 not capable of correctly handling ARF messages.
1386 Feedback Consumers may not be equipped to handle the volume or format
1387 of complaints without some warning and preparation.
1389 Author's Address
1391 J.D. Falk (editor)
1392 Messaging Anti-Abuse Working Group
1393 Presidio of San Francisco
1394 P.O. Box 29920
1395 572 B Ruger Street
1396 San Francisco, CA 94129-0920
1397 US
1399 Email: ietf@cybernothing.org
1400 URI: http://www.maawg.org/