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/