RFC 6449

Complaint Feedback Loop Operational Recommendations

📅 published November 2011, from ietf

Complaint Feedback Loop Operational Recommendations 💌

🎀 Okay bestie, this one is RFC 6449, and it's giving best practices 💅. It's an Informational RFC, not a Standards Track spec. The author is J. Falk, Ed., it came from the Messaging Anti-Abuse WG, and it's dated November 2011. The ISSN is 2070-1721. The title block doesn't list any Obsoletes or Updates entries, so this doc doesn't replace or change any other RFC 🦋.

Abstract

✨ So basically, Complaint Feedback Loops (CFLs) have been around for more than a decade, and they've picked up a ton of de facto standards and best practices along the way 🌸. This document is a cute little attempt to write all that down and make it clear how both the providers and the consumers of these feedback mechanisms plan to use the feedback. It also describes some industry practices that are already super common 💜.

This doc is the product of teamwork inside the Messaging Anti-Abuse Working Group, which is a trade organization that's separate from the IETF 🤝. The original MAAWG document it's built on came out in April 2010. Important: this document does not represent IETF consensus 🙈. It's published as an Informational RFC so the whole Internet community can get it easily, and so IETF work can cite it without any drama 🧚.

Status of This Memo

🍓 This document is not an Internet Standards Track specification. It's published just for info, okay?

It's a product of the Internet Engineering Task Force (IETF), and the Internet Engineering Steering Group (IESG) has approved it for publication. Not every IESG-approved document is eligible for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 👀.

If you want the latest on this document's status, any errata, or how to send feedback, head to http://www.rfc-editor.org/info/rfc6449 🔗.

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc 📜. Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, just like the Simplified BSD License says 🫶.

This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English 💖.

   1. Overview ........................................................4
   2. Glossary of Standard Terms ......................................5
   3. Mailbox Providers and Feedback Providers ........................9
      3.1. Benefits of Providing Feedback .............................9
      3.2. Collecting Complaints .....................................10
      3.3. Creating Reports ..........................................11
      3.4. Policy Concerns ...........................................11
           3.4.1. Privacy and Regulatory Compliance ..................11
           3.4.2. Terms of Use .......................................12
      3.5. Handling Requests to Receive Feedback .....................12
           3.5.1. Application Web Site ...............................13
           3.5.2. Saying No ..........................................14
           3.5.3. Automation .........................................14
      3.6. Ongoing Maintenance .......................................15
           3.6.1. IP Validation ......................................15
           3.6.2. Email Address Validation ...........................16
           3.6.3. Feedback Production Changes ........................16
   4. Feedback Consumers .............................................16
      4.1. Preparation ...............................................17
      4.2. What You'll Receive .......................................18
           4.2.1. Feedback Reports ...................................18
           4.2.2. Administrative Messages ............................18
           4.2.3. Report Cards .......................................18
      4.3. Handling Feedback Messages ................................19
           4.3.1. Unsubscription or Suppression ......................20
           4.3.2. Trending and Reporting .............................21
      4.4. Automatically Handling an Incoming Feedback Stream ........22
   5. Conclusion .....................................................25
   6. Acknowledgments ................................................26
      6.1. About MAAWG ...............................................26
   7. Security Considerations ........................................26
   8. Informative References .........................................26
   Appendix A. Abuse Reporting Format (ARF) ..........................28
     A.1. A Brief History ............................................28
     A.2. Structure of an ARF Message ................................28
   Appendix B. Using DKIM to Route Feedback ..........................29
   Appendix C. Unsolicited Feedback ..................................30
     C.1. Guidelines .................................................30
     C.2. Pros .......................................................30
     C.3. Cons .......................................................31

1. Overview 🦋

Okay so the whole point of a Complaint Feedback Loop is to give Feedback Consumers the info they need to cut down on Spam, or at least the perception of Spam 🙈. Feedback was originally only offered to mailbox, access, and network providers (basically ISPs) 🌐. Those providers used it to spot network compromises and fraudulent accounts, or to let a downstream customer know there might be a problem 🔍.

Senders of bulk, transactional, social, or other kinds of email can use this feedback too 💌. They can treat Spam Complaints as a signal of whether the Recipient still wants to get email from them. People often respond by tightening up their opt-in practices, changing how often they mail, cleaning up their lists, tweaking message content, and taking other steps 🧹. Over time this has become the Feedback Consumer use case that gets talked about most at MAAWG meetings and other industry events 🎤. Just know that it's not the only use for feedback, so don't sleep on the rest 👑.

                              [ Feedback Consumer Database ]
                                            |
                                            V
   [  User   ]    [ Mailbox  ]         [ Feedback ]
   [ Reports ]--->[ Provider ]--SMTP-->[ Provider ]
   [  Spam   ]         |                    |
                       V                    V               [ Feedback ]
             [Spam Filter Rules]    [ ARF Message ]--SMTP-->[ Consumer ]

                                 Figure 1

💅 So here's the flow: when an End User of a Mailbox Provider files a Spam Complaint, the Feedback Provider sends a report over to the Feedback Consumer ✨. That report might include the Full Body of the original email, or (less often) just the full header 📨. Some Feedback Providers redact stuff they consider private, like the Message Recipient's Email Address 🔒.

Making sure Feedback Messages only go to authorized Feedback Consumers is the Feedback Provider's job 🛡️. The identity of each message Sender is generally figured out from the connecting IP address of the SMTP session, or from the DomainKeys Identified Mail (DKIM) signature domain on the message. Both are hard to forge, which is the whole point 🔐. This matters a lot, because Spammers and other miscreants might try to sign up for Feedback Loops on networks that don't belong to them, just so they can steal Email Addresses and other private personal or corporate info 😤.

It's on the Feedback Consumer to figure out where the original message came from and what kind of message it was, based on the reports they get, and then take whatever action is appropriate 🕵️‍♀️. The Feedback Provider doesn't make any claims or judgments about whether a complaint is valid, apart from whatever technical data the Feedback Provider included themselves 🤷‍♀️. Every complaint gets forwarded to the Feedback Consumer with no human review and no extra filtering, so some individual reports might turn out to be not actionable 🙃.

The Feedback Consumer and the Feedback Provider each judge a Spam Complaint for validity and take whatever action they think is needed from their own point of view 🧠. In most cases they won't tell each other which actions were taken (or not taken) 🤐. It's also rare for either party to reach out to the End User who made the complaint 📵. Iykyk 💀.

2. Glossary of Standard Terms 📖✨

Okay bestie, the glossary is where all the vocab lives 💅 Wherever possible, these terms come straight from [RFC5598], so we're all speaking the same language.

Abuse Reporting Format - The standard format for Feedback Messages, defined in Appendix A and [MARF]. 📝
Access Provider - Any company or organization that gives End Users access to the Internet. 🌐 It might or might not be the same entity the End User uses as a Mailbox Provider.
Application for Feedback Loop - The process, manual or online, where a prospective Feedback Consumer asks to receive a Feedback Loop from a particular Feedback Provider. 🙋‍♀️
ARF -- See "Abuse Reporting Format".
ARF Report -- See "Feedback Message".
Body - See "Full Body".
Complaint or Complaint Message - See "Feedback Message".
Complaint Feedback Loop - See Overview and Taxonomy section. 🔁
Complaint Stream - See "Feedback Stream".
Delivery - See "Message Delivery".
DKIM - DomainKeys Identified Mail. It's further described in the MAAWG email authentication white paper "Trust in Email Begins with Authentication" [Trust] and in [DKIM]. 🔐
End User - A customer of a Mailbox Provider or Access Provider. 🧑‍💻
Envelope Sender - The Email Address included as the argument to the [SMTP] "MAIL" command during transfer of a message. 📮
Email Address - A string of the form user@domain. The domain (after the @ symbol) is used to figure out where to transfer an email message so it can be delivered to the mailbox named by the username (before the @ symbol). The precise technical format of an Email Address is defined in [SMTP]. Email delivery can be a complex process, and this document doesn't go into it any further. 💌
Email Service Provider (ESP) - A provider of email sending services. The ESP is often a Message Originator working on behalf of a Message Author. MAAWG uses the term "ESP" only for this definition and does not refer to a Mailbox Provider for End Users as ESPs. 📤
FBL - The acronym "FBL" (Feedback Loop) is intentionally not used in this document. 🙅‍♀️ Not using it on purpose, so no sneaky abbreviations here!
Feedback or Feedback Stream - A set (often a continuous stream) of Feedback Messages sent from a single Feedback Provider to a single Feedback Consumer. 🌊
Feedback Consumer - A Recipient of the Feedback Messages, almost always on behalf of or otherwise associated with the Message Originator. Often the Message Originator and Feedback Consumer are the same entity, but this document describes them separately because each one handles different parts of the Complaint Feedback Loop process, as shown in the flowchart in the Overview section. 📥
Feedback Loop - See Complaint Feedback Loop. 🔁
Feedback Message - A single message, often using the Abuse Reporting Format defined above and outlined in Appendix 1. It's part of a Feedback Stream. 🧾
Feedback Provider - The Sender of the Feedback Messages, almost always on behalf of or associated with the Mailbox Provider. Often the Mailbox Provider and Feedback Provider are the same entity, but this document describes them separately because each one is responsible for different parts of the Complaint Feedback Loop process. Sometimes the Feedback Provider may be operating solely on behalf of the Message Recipient, without any direct participation from their Mailbox Provider. 🫶
Full Body - An email message (the "DATA" portion of the [SMTP] conversation) has two parts: the header and the body. The "Full Body" is simply the entirety of the body of the message, without modification or truncation. Images and other so-called "attachments" are actually part of the body, designated under the [MIME] standard. 🖼️
Full Header Section - An email message (the "DATA" portion of the [SMTP] conversation) has two parts: the header and the body. The header contains multiple header fields, each formatted as Header-Name: header contents. Most Mail User Agents (MUAs) only show the basic four header fields (From, To, Date, and Subject), but every message includes extra header fields that mostly hold diagnostic information or data meant to help automatic processing. These are often informally called "Full Headers". These fields are fully defined in [RFC5322] 🕵️‍♀️
Header - See "Full Header Section" above.
ISP - Internet Service Provider. This paper usually refers to it as either an Access Provider or a Mailbox Provider. 🛜
Mail Abuse Reporting Format (MARF) - See "Abuse Reporting Format" above.
Mailbox Provider - A company or organization that hosts email mailboxes for End Users and/or organizations. Many Mailbox Providers are also Access Providers. 📬
Mailing List - A set of Email Addresses that will receive specific messages according to the policies of that particular list. 📣
Message-ID Header Field - One of the diagnostic header fields included in every email message (see "Full Header Section" above) is the Message-ID. In theory, it's a unique identifier for that individual message. 🆔
Message Delivery - The process of moving a message from one mail transfer agent (MTA) to another. Once the MTA operating on behalf of the Recipient has accepted the message, it counts as "delivered", no matter what filtering or processing happens after that point. ✅
Message Originator - The Sender of a message, but not necessarily its author or creator. ✍️
Message Recipient - The person or mailbox that receives a message as its final point of delivery. 💖
MIME - Multipurpose Internet Mail Extensions. It's a set of standards that lets non-plaintext data be embedded in the body of a message. File attachments and formatted or "rich" text are all done solely through [MIME]. 🎨
MUA - Mail User Agent. Loosely, it refers to the software an End User uses to access, interact with, or send email messages. 📱
Provider - See "Feedback Provider" above.
Received Header Field - Diagnostic header fields included in an email message (see "Full Header Section" above) that start with Received:. They record (from bottom to top) the path a message took from its originator to where it is now. 🛤️
Recipient - See "Message Recipient" above.
Return-Path - An optional message header field (see "Full Header Section" above) that shows the Envelope Sender of the message. ↩️
Reverse DNS - The [DNS] name of an IP address. It's called "reverse" because it's the inverse of the more user-visible query that returns the IP address of a DNS name. A Reverse DNS query also returns a PTR record instead of an A record. 🔄
Sender - See "Message Originator" above.
SMTP - Simple Mail Transfer Protocol. It's the mechanism and language for moving an email message from one place to another, as defined in RFC 5321 [SMTP]. 🚚
Spam - For this document (and for most Complaint Feedback Loops), "spam" means any message that the Recipient chooses to complain about, no matter what the intent of the message's author or Sender was. 🗑️
Spam Complaint - See "Complaint" above.
Spammer - An entity that knowingly and intentionally sends Spam messages (see "Spam" above). 😈
Terms of Use - A legal document that describes how a particular system or service is to be used. ⚖️
VERP - Variable Envelope Return Path [VERP], an informally standardized method for encoding information about the Message Recipient into the return path while a message is delivered. The point is to make sure any non-delivery notices get processed correctly. 🧩

3. Mailbox Providers and Feedback Providers 📬💕

Real talk, in practice a Mailbox Provider gets complaints from its End Users. It's often also the Feedback Provider for those complaints, and it consumes feedback from other providers too. This document keeps the Mailbox Provider and Feedback Provider jobs separate so nobody gets confused in the cases where they're different. And I really want Mailbox Providers to read the "Feedback Consumer" section later in this document 🥺

3.1. Benefits of Providing Feedback 🌈

Setting up a Complaint Feedback Loop service is a big deal, so don't do it lightly 💅 The benefits of a Feedback Loop are huge, but they only work out with a solid plan, organized implementation, and real dedication to upkeep.

So what are the perks of giving feedback to fellow Mailbox Providers and Access Providers? Mainly, other industry players hear about Spam outbreaks on their networks super fast 🚨

End Users are getting more aware of and comfortable with ways to report Spam, and a Feedback Loop does exactly what its name says: it closes the loop 🔁✨ The End User's complaint travels back to the Message Originator (not necessarily the message Sender, who might be a Spammer), so the originator can take action. In all this, the mail system operator is just a messenger, and doesn't have to review and forward complaints by hand. Iconic behaviour 👑

Also, every complaint is sent right away, with no review or analysis by the Feedback Provider, so the Feedback Consumer gets it in near real time ⏱️ If the Feedback Consumer keeps an eye on their Feedback Stream and acts on it, the receiving Mailbox Provider gets less Spam, blocks less legitimate mail, and doesn't need staff chasing down the originating network 🙌 But if the Mailbox Provider ignores its Feedback Stream and doesn't act on it, the Feedback Provider may block or otherwise filter email from that Message Originator, since it considers the Feedback Messages to be sufficient notice. 😬

Now for bulk Feedback Consumers: what are the perks of providing Feedback Loops to them? As Message Recipients get more comfortable with Spam reporting, they often prefer it over the confusing and inconsistent "unsubscribe" or "opt-out" mechanisms that most legitimate Message Originators or Senders offer 🙃

Honestly, End Users often can't remember which lists they signed up for, or they just aren't sure about the relationship they have with a message Sender. So they often report messages as Spam to their Mailbox Providers, figuring that's enough to say "I don't want this email anymore" 💌

If the Message Originator pays attention to its Feedback Stream and acts on it, it'll have happier Message Recipients and should get fewer Spam Complaints (assuming its opt-in processes are sound) 🥰 If the Message Originator ignores Feedback and doesn't act on it, the Mailbox Provider may treat the Feedback Stream as sufficient notice that messages from that originator may no longer be accepted in the future. 🚫💀

3.2. Collecting Complaints 📬

Okay so, to make Feedback Messages that are actually useful 💅, the Feedback Provider needs near real-time complaints from the Mailbox Provider's users. The usual move is to plug the feedback system right into the collection of Spam reports from users. Main character energy for the data pipeline 🎀✨

These reports are usually made with the "Report Spam" buttons built into Webmail interfaces, or with a proprietary desktop client that users get. Mailbox Providers can also look into a toolbar or MUA plug-in that adds a "Report Spam" button to the MUA interface 🦋

Usability studies with average users should be run on all interface changes before they go live 🧪 And there should be a "help" interface too, so people actually understand how the Spam button works and what it does. Educating your users is iconic 🫶

Now the tea 🍵: if the Mailbox Provider doesn't give customers a mail client with this button, the Feedback Provider's chances of running an effective Feedback Loop are slim 😭💀 Sure, the Mailbox Provider can tell customers to forward unwanted mail to a central spot, and explain how to make sure the report includes headers and bodies. But the success rate of customers actually doing that tends to be low 🙈 And even the complaints that do have all the required info can be a nightmare to parse, because variations in formatting and content types keep forcing the automated tools to get new logic blocks for each variation that shows up 🌀

3.3. Creating Reports 🧾

It's recommended that Feedback Messages be sent using the standard Abuse Reporting Format, so everyone consuming feedback gets uniformity and easy processing 💖 It also lets the Feedback Provider automate a lot of the work, both generating and sending Feedback Messages and analyzing complaint stats. This format is described further in Appendix 1 📖

Feedback Loops are usually (but not always) keyed to the "last hop" IP address, meaning the IP address that passed the unwanted message to the Mailbox Provider's servers 🔑 So the Feedback Provider has to be able to process the header from each complaint to figure out the IP address for that complaint 🧠

A Feedback Provider might want to include other info in its Feedback Loop, beyond Spam Complaints, that Feedback Consumers may find valuable ✨ That could be summary delivery stats (volume, inbox delivery rate, Spam trap hits, etc.), or any other data the Feedback Provider considers pertinent to Feedback Consumers 📊

Any mature Feedback Loop system is going to end up with situations where the Feedback Consumer has follow-up questions or more info to share about the feedback 💬 So Feedback Messages should include contact information (typically an Email Address) for the Feedback Consumer to use. Ideally that contact Email Address feeds into a ticket system or another automated tool that the Mailbox Provider's postmaster and/or anti-abuse staff use for general email delivery issues 🎫🌸

3.4. Policy Concerns ⚖️

3.4.1. Privacy and Regulatory Compliance 🔒

Feedback Messages carry info that Feedback Providers pass along from a Mailbox Provider's End Users to the Feedback Consumer 💌 There might not be any concerns with relaying non-private data to a third party. But the info in the complaints users generate has to be evaluated, and any data deemed private may need to be removed before it goes to a third party, per local policy 🛡️ For example, the Recipient's or reporter's Email Address and IP address may be classed as private data and stripped from the feedback report given to the Feedback Consumer 🙈 Privacy laws and corporate data classification standards should be consulted to decide what counts as private.

Info the Feedback Consumer gives the Feedback Provider to enroll in the Feedback Loop should also be kept private 🤫 It should only be shared or used for the purposes explicitly agreed to during enrollment (see the "Terms of Use" section below).

Feedback Loops inevitably cross country borders 🌍 Local laws and regulations about sharing info domestically and internationally need to be considered when running a Feedback Loop program. For example, in some European countries, data exchange requires permission from governing bodies 🇪🇺 The terms and circumstances around exchanging data need to be clearly defined and approved.

3.4.2. Terms of Use 📜

A written Terms of Use agreement should be provided by the Feedback Provider, and agreed to by the Feedback Consumer, before any feedback is provided ✍️ These concepts should be considered when drafting it:

Data provided in Feedback Messages goes to a specific, approved entity. Information should not be transmitted outside of the intended, approved Recipient. Any inappropriate use of the information can lead to immediate termination from the feedback program 🚫
Consumers of Feedback have a responsibility to keep the information they provide for Feedback Loop purposes (such as abuse contact information, IP addresses, and other records) accurate and up to date 🗂️
Providing Feedback information is a privilege and needs to be treated appropriately. It does not entitle the consumer of the feedback to any special sending privileges 👑
Approval and continued enrollment in the program is a privilege that can be denied or revoked for any reason and at any time 💅

3.5. Handling Requests to Receive Feedback 📥

There should be a streamlined application process for receiving feedback, and a vetting process for those applications 🧐 Vetting may be stringent when the Mailbox Provider ties its Complaint Feedback Loop program to a whitelist. Criteria may involve the following:

Cross-checking that the requestor is actually authorized to receive feedback for the IP addresses concerned 🔍
Gathering other info, like whether the IPs belong to an ISP smarthost network, a webhosting farm, an email marketing or Mailing List service, or some other entity 🏢
Requesting info such as a link to the requestor's policies, contacts to send Feedback Messages to, and escalation points of contact 📇

Ideally, enrollment is a two-step process. The applicant fills out a form, then has to receive and acknowledge a confirmation email (best sent to abuse@ or postmaster@ the domain in question) before the request is even put in the queue for the Feedback Provider to process ✅

Ownership of IP addresses can and should be cross-checked using origin Autonomous System Number (ASN), WHOIS/RWHOIS records, Reverse DNS of the sending hosts, and other sources 🕵️‍♀️ This can be automated to some extent, but it often needs some manual processing too 🫠

3.5.1. Application Web Site 🌐

Applications for Feedback Loops can be accepted on a stand-alone web site, or as part of the Mailbox Provider's postmaster site 💻 Either way, the web site for the Complaint Feedback Loop program should have other Feedback Loop content, including FAQs for the program, the Terms of Service for the Feedback Loop, and maybe a way for enrolled parties to modify their existing enrollments 📝

The web site should also give the Feedback Consumer general info on how the feedback will be sent, including:

Report Format (ARF or otherwise)
Sending IP addresses and/or DKIM "d=" string
"From" Email Address

3.5.2. Saying No 🙅‍♀️

Denying a Feedback Loop application may be appropriate in certain cases, such as:

When the Feedback Provider suspects "gaming" of delivery policies through the Feedback received, like attempts to pollute Feedback Loop metrics by creating bogus accounts and reporting false negatives with them, to offset the negative reputation caused by high complaint rates 🕵️
When the Feedback Provider has decided to block the Message Originator's IP space for which feedback has been requested, on the grounds that email from that originator has a sufficiently negative reputation that it won't be delivered at all 🚫 This is kind of like a global unsubscribe of the Message Provider's users from the originator's lists, which would make extra feedback unnecessary 💤

It's recommended that the Feedback Provider send a notification if an application is denied. The Feedback Provider should also keep a documented, clear, and transparent appeals process for denials 📣 This can be as simple as the prospective Feedback Consumer replying to the denial email to ask for review or escalation to a team lead, and citing reasons the application should be reviewed 🙏

3.5.3. Automation 🤖

For a Feedback Loop to be cost-effective and usable for large Feedback Consumers and Feedback Providers, reports must be generated and processed automatically, with no human interaction ⚙️ On the flip side, small Feedback Consumers should be able to handle a low volume of reports manually, without needing any automation 🧁

When automating the feedback process, the consumer of the Feedback Stream has to get enough info about the report to take appropriate action, typically removing the Recipient from the Mailing List that the report is about 📋 The Recipient's Email Address alone isn't enough. The Recipient may be on several Mailing Lists run by the Feedback Loop consumer and only need to be removed from the particular list reported 🎯

Also, some producers of Feedback Loops might redact the Recipient's Email Address for privacy reasons 🔐 Running a Complaint Feedback Loop well means the Feedback Provider puts in as many automated processes and tools as feasible to handle every part of the process 🧩 Feedback Providers should aim to automate or script the following:

Accepting and validating Feedback Loop Applications from prospective Feedback Consumers 📨
Processing requests to determine whether or not they meet the Feedback Provider's criteria for enrollment in the program 🔎
Accepting Spam Complaints from End Users. This will form the bulk (and perhaps sole) component of the feedback sent by the Feedback Provider 🗑️
Producing Feedback Messages from Spam Complaints 🏭
Producing other Feedback Loop artifacts as chosen by the Feedback Provider 🎨
Optionally, providing a mechanism for Feedback Consumers to further engage a Feedback Provider about a given Feedback Message 💬
Ongoing validation of Feedback Loop enrollments to determine whether a currently enrolled IP address or network still merits inclusion in the Feedback Loop 🔄
Optional periodic emails to Feedback Consumers to determine whether their enrolled Email Addresses are still valid 📬

3.6. Ongoing Maintenance 🧹

It's recommended that self-service maintenance be offered to Feedback Consumers, to the extent practicable 🌷 The more they can do themselves, the less you have to do 💜

3.6.1. IP Validation 💅

Okay so the criteria a Feedback Provider uses to check a Feedback Loop application can change over time 👀. And it's basically a near-guarantee that at least some of the Feedback Consumers signed up to receive feedback will stop meeting those criteria after enrollment, even if the criteria never change 😭. The Feedback Provider should put tools in place that periodically re-validate every enrolled Feedback Consumer against the current criteria. The Feedback Provider will also probably have objective criteria for staying in the Feedback Loop, and enrolled consumers should be checked against those too 🫶.

3.6.2. Email Address Validation 📬

Mailing list software can send periodic "probe" emails to subscribers to check that their addresses still work, and the Feedback Provider should develop tools that do something similar 🧚. Those emails go to the addresses receiving Feedback Messages, to make sure they're still valid. This matters most for addresses other than the abuse@ and postmaster@ ones used in the enrollment acknowledgment step. People change jobs, or at least roles, over time. Validating the Email Addresses tied to an IP is how the Feedback Provider makes sure Feedback Messages are still being accepted and acted on by the Feedback Consumer 💖.

3.6.3. Feedback Production Changes 🌸

Updating Feedback Consumers when your own IP addresses change is a big deal for Feedback Loop maintenance 🔥. The exact format, automation, and other considerations for those updates are outside the scope of this document, but they're definitely worth more discussion and eventual documentation 🍓.

4. Feedback Consumers ✨

A Feedback Consumer starts receiving its Feedback Messages once its submitted Application for a Complaint Feedback Loop is approved 🎀. It'll usually have Complaint Feedback Loop subscriptions set up with multiple Feedback Providers. Different Feedback Streams may come in different formats or include different information, so the Feedback Consumer should identify a process to organize the data it gets and take appropriate action 💅.

A Feedback Consumer, Mailbox Provider, or Access Provider (aka a hosting company or ISP) uses this Feedback to spot network compromises, fraudulent accounts, policy violations, and other concerns 🕵️. The Feedback Loop gives real-time visibility into Spam Complaints from Message Recipients, which is a huge help for these Mailbox Providers in stopping Spam from spreading out of their networks 🚫.

Senders of bulk email should use the complaints to make decisions about future mailings 💌. Those decisions may include one or more of the following: changing email frequency, branding, opt-in practices, or list management 🧹.

The authors of this document really want anyone who is only a Feedback Consumer to also read the earlier sections for Mailbox Providers and Feedback Providers. That gives you the proper context for the recommendations below 📖.

Further recommendations for bulk senders may be found in the MAAWG Sender Best Communications Practices [MAAWG-BCP] 🦋.

4.1. Preparation 🎀

Feedback Consumers need to get ready to process and act on feedback before asking to receive it. At a minimum, make sure you have:

The "Role" Email Addresses such as abuse@ and postmaster@. The person applying for the Feedback needs to make sure they have access to these Email Addresses. Feedback Providers often send a confirmation link to those accounts, so that End Users, Spammers, or competitors can't sign up for Feedback they aren't authorized to get 🙈.
A dedicated Email Address to receive the Feedback Messages, such as fbl@example.com or isp-feedback@example.com. It's not required, but it'll make it way easier to process the reports you get 🫶.
A list of IP addresses you want Feedback Messages for, making sure you can prove ownership of those IP addresses and the associated domains. Feedback Providers often require that:
- Reverse DNS for each IP shares the domain of either the applicant's Email Address or the Email Address that will be receiving the Feedback Messages.
- WHOIS information for the IPs requested is obviously associated with the domain name.
Contact information such as name, Email Address, phone number, and other relevant info 📇.
The knowledge that if the application form asks for your credit card number or other financial information, it is assuredly a scam 🚨💀.

4.2. What You'll Receive 📦

Once a Feedback Consumer has signed up to receive feedback from a Feedback Provider, it may also get several other sorts of delivery-related reports. That includes Feedback Messages, administrative messages, and other messages 💌.

4.2.1. Feedback Reports 💖

Feedback Messages are the main emails people generally associate with a Feedback Loop 📨. Each time a Recipient hits the "This Is Spam" button, the Feedback Loop system creates a boilerplate report with a copy of the original email attached and sends it to the consumer of the Feedback Loop.

How feedback reports get handled is covered in the next section 🙌.

4.2.2. Administrative Messages 🗂️

Administrative messages will typically go to the Email Address provided for contacting the person who originally applied for the Feedback Loop, rather than the address provided for handling Feedback Messages. They're likely to show up infrequently and irregularly, but it's important that the person managing the Feedback Stream processor sees them in a timely manner ⏰. It's usually a poor idea to send them to an individual's Email Address, since they can get lost if that person is on vacation, changes position, or leaves the company 😩.

Instead, send them to a role account that goes to a ticketing system, or that gets "exploded" out to multiple responsible parties in the organization 🎟️. If there isn't already an appropriate role account, such as support@ or noc@, that reaches the right team, it may be a good idea to set up a dedicated alias such as fblmaster@ to sign up for all Feedback Loops 🧚.

4.2.3. Report Cards 📇

The detail in a report card can vary greatly 😭. Feedback Providers might send a regular summary of traffic levels and complaint rates, perhaps just an overview or possibly broken down by source IP address or some other identifier. Sometimes these get sent only when some metric (typically a complaint rate) reaches a level that makes the Mailbox Provider notify the Feedback Consumer that a problem may be developing and needs investigating and addressing. At the other extreme, some report cards contain almost no useful data at all, just a warning that the Message Originator is causing complaints, with the implication that its email will be blocked unless it improves 🚫.

Report cards are human readable, since there aren't currently any standard machine-readable formats, and the information they include (both the provided metrics and their semantics) varies widely from one Mailbox Provider to another 🤷. They're useful reference overviews for a Message Originator monitoring the overall perceived quality of the email it sends and, in the case of ESPs, maybe which customers are causing higher-than-expected complaint rates 👀. They can also be the only warning of serious problems before email gets blocked altogether by the receiving Mailbox Provider 😱. It's critical that someone handling delivery issues for the Message Originator sees them, so again, they should go to an email alias that is always read 📬.

Report cards also contain useful data to track mechanically and perhaps report on trends. But since their content varies, it's hard to generalize what use might be made of them 🧐. At the very least, the "warning" report cards should be visible on an ESP's business intelligence or delivery dashboard 📊.

4.3. Handling Feedback Messages 🧹

Mailbox Providers sending feedback may have published policies on how they expect a Feedback Consumer to use Feedback Messages, or they may just expect the consumer to "make the problem stop" 🙏. In practice, this mostly boils down to three things:

First, where the consumer of the feedback has some specific control over sending the email, it is expected not to send email of the same type to the same Recipient again 🚫.
Second, it should identify the underlying problem (if any) and fix it so that it receives fewer reports of that type in the future 🔧.
Third, it is not necessary to inform the Mailbox Provider or Feedback Provider, or their End User(s), of which actions have been or will be taken in response to automated complaint feedback 🤐.

If the Feedback Consumer is a separate entity from the Message Originator, the two entities are expected to work together to resolve any problem 🤝.

4.3.1. Unsubscription or Suppression ✨

okay bestie, so if you're a Sender (whether you wrote the mail or just sent it on someone's behalf) of commercial email, you should treat the Feedback Message like an unsubscribe request 💌 Make sure that no more email from that list goes to that Recipient, either by removing the address from the list or by adding it to the associated suppression list. You get to use your best judgment here, keeping in mind the goal of reducing future complaints, to figure out how broadly to apply that unsubscribe. Suppressing the address across an entire ESP is likely too broad 🙅‍♀️ But if a single Feedback Consumer (or an ESP customer) has multiple segmented lists, then suppressing them across all of those lists is probably a good idea 💜

Not every complaint is intentional, and everyone knows it 🙈 Recipients might accidentally hit the wrong button, or mark a whole mailbox as Spam by mistake. Still, it's best for Feedback Consumers to assume the Recipient does not want more email and to suppress mail to that Recipient in all but fairly extreme cases, like a Mailing List the Recipients pay to receive, email from a genuine company to its valid employees, or email from an Access Provider or Mailbox Provider to its users 🫶

It gets messier with transactional mail, which is mail tied to some other service, like ticket purchase confirmations or billing statements 😩 Again, the Feedback Consumer has to use its best judgment based on the specific situation. Sometimes the right move is to reach out through another channel, like a message on the web site used for the service. For example: "You reported your notification mail as Spam so we are not going to send you any more messages unless you tell us otherwise" 🎀

Sometimes the best thing to do is actually to ignore the Feedback Message 👀 Say your customer reported as Spam the airline tickets he bought, and you emailed him. He probably didn't mean it, and he's going to be so annoyed if you don't send the other tickets he ordered 💀 In rare cases, it might make sense to suppress email to the Recipient and also suspend their access to a service they use until they confirm they want the associated email. In all of these cases the big goal is to keep the customer happy and reduce future complaints, even in the totally paradoxical situations where the way to do that is to ignore their Feedback 🧚 In the real world, though, these are a small minority of cases.

Counting the Feedback Messages you receive over regular time periods can give ISPs, ESPs, and other Feedback Consumers so much useful info, especially when you break it down properly 🌈

An ISP (Mailbox Provider or Access Provider) might want to count how many Feedback Messages a particular customer or IP address causes in a given day. If there's a sudden jump from one customer or server, it could mean a Spammer signed up or a system got compromised 😱 If there's a high level of complaints about a particular customer, it may be worth investigating to see if there's a reason for it. For example, 10 Feedback Messages a day would be a sign of serious problems in some cases, but could be perfectly reasonable "background" levels for a Message Originator that sends 300,000 emails a month 🍓 If the count shows there might be a problem, the ISP can dig down and look at the emails being reported to figure out the underlying cause 🔍

An ESP can do similar things but can also slice the data in more ways: by customer, by Mailing List, and by campaign 💅 An ESP also has access to more information. It knows how many emails were delivered to the receiving Mailbox Provider over a given time period. So it can estimate the number of complaints divided by the number of emails sent, which is often a much more useful metric than the raw number of reports 🔥 This is critical data for ESPs to track over time, because it helps them identify and quantify problem customers 👑

An individual Feedback Consumer, whether they send their own email or use an ESP, can still learn at least something from complaint rates 🦋 A spike in complaints on an otherwise stable list might mean there's a problem with address acquisition, if the spike is from new subscribers. If it came from older subscribers, it might be because of the content of a particular mailing that didn't land well. Maybe the branding wasn't recognized, or the content was offensive or inappropriate for the list 😬

The complaint rate is the number of Feedback Messages received over a given time period divided by the number of emails delivered to the associated Mailbox Provider over the same period. It's an obvious and super useful metric to track, but there are a few subtle issues to be aware of 🧐

One issue is that Feedback Messages tend to be counted on the day the complaint was sent, which is the day the Recipient read the original message. That might not be the same day the message was sent! A simple example: a Message Originator that sends email regularly Monday through Friday will often see a high complaint rate on Saturday 😭 The absolute number of Feedback Messages from people catching up on the week's email over the weekend may not be that high. But since hardly any email gets sent on Saturday, a fairly reasonable number of complaints end up being divided by a very small number of total sent emails, possibly even zero, which would break the reporting engine 💥 This can make the complaint rate look anywhere from suspicious to downright ridiculous. So large Mailing Lists that are basically silent on the weekend could end up receiving more complaints on a Saturday than email they sent that day, leading to complaint rates of well over 100% 🙃

Another arithmetic thing to watch is how the inbox, the bulk folder, and the "This Is Spam" button all interact 🎭 Say an organization sends a high volume of email that has a terrible reputation. It might end up with maybe 500 of its 10,000 mails in the inbox and the other 9,500 in the bulk folder. If it gets 10 Feedback Messages and divides that by the 10,000 emails it sent, it gets a very respectable 0.1% complaint rate ✨ But the Mailbox Provider is probably going to calculate the complaint rate by dividing by the number of emails delivered to the inbox instead, which gives a 2% complaint rate. That's probably grounds for immediate blocking 🚫 So if you see a big difference between a complaint rate reported by a Mailbox Provider or other reputation system and the rate you calculate from raw delivery numbers, it's really important to look closely at the data 👀💖

4.4. Automatically Handling an Incoming Feedback Stream ✨

Okay so even when signing up for a Feedback Loop is partly automated, changes to it usually get handled by hand 😭. Even something as small as switching the address that Feedback Messages get sent to can eat up time and cause real overhead for the Feedback Provider. Multiply that by a dozen Feedback Loops and getting it right the first time saves a ton of energy 💅.

Even the smallest users should make a unique email alias for each Feedback Loop 🎀. This is iconic for a few reasons, even if they all land in the same person's inbox at first. A unique address makes it instantly clear which Feedback Provider a report came from, even if the From address is inconsistent. It makes it easy to add lightweight pre-processing for one particular Feedback Stream if you need it. It makes it easy to throw away Feedback Messages when needed, though only temporarily, because missing a changing trend could be really bad for your reputation 💀. And if a Feedback Consumer needs to scale up, it's easy to point the existing aliases at a Feedback Loop processing engine 🚀.

If an organization might seriously scale up in the future, or might outsource its Feedback Loop processing to a third-party Feedback Consumer, it may be even better to set up a subdomain just for handling Feedback Streams 🧚. For example, example.com might use fbl-aol@fbl.example.com to accept its AOL Feedback Loop. That way it can hand the whole of @fbl.example.com over to a Feedback Loop handling appliance or service if the need ever comes up.

Small Feedback Consumers, with lists of no more than a few thousand Recipients, or small ISPs with no real history of problems, should be able to handle feedback reports with little or no automation 🌸. An ARF message should be readable in most mail clients, so it's giving "manageable." It may still be worth adding some very lightweight processing to inbound Feedback Messages so they're easier to triage from another email client 🦋. For example, arffilter.c [Wise] can annotate the Subject line of inbound Feedback Messages with the IP address being reported. That makes it way easier to spot patterns of problems by sorting the messages by Subject line in the mail client. To figure out which Recipient is causing the feedback to be sent, small Feedback Consumers should add some of the automation described below that is meant for larger Feedback Consumers ✨.

Larger Feedback Consumers need to automate handling of Feedback, because the volume grows past what one person can manage by hand pretty quickly 📈. The main thing a Feedback Loop processor needs to do is pull out the relevant data from the report, reliably 🔍. The most important bits of data tend to be these:

The Recipient of the original email
The Mailbox Provider originating sending the Feedback Message (some Feedback Providers operate on behalf of multiple Mailbox Providers)
The customer who sent the original email (in the case of an ESP or Mailbox Provider)
The campaign and Mailing List that the original email belonged to, if any
(Possibly) the IP address from which the original email was sent and any [DKIM] signature domain

The last one isn't vital, but it can be a useful piece of data when you're diagnosing delivery problems 🧐.

Getting some of this data can be really tricky without doing some upfront work before the email is sent 😩. Some Feedback Providers redact the Email Address in the To: header or the Recipient Email Addresses anywhere in the message. Some delete any identifying information they can find. It might be possible to identify the End User from the Message-ID, the Subject line, and Received header timestamps, if you have access to the mail server logs. But at best it's painful and time-consuming, so it's only worth doing in an exceptional case 🙃.

The solution is similar to the one used for automated bounce handling with VERP. The idea is to embed the information in the email in a way that Feedback Providers are unlikely to remove, but that is still easy to recognize 👀. That information may already be there, in a form like VERP if the Return-Path header is included in the embedded email, or in one-click unsubscribe links in the body of the email. If it isn't already there, a good spot to add it is the local part of the Message-ID, since that's often used to track the progress of an email through delivery 🛤️. It's also often available from log files, as well as in the headers of the original message included in the Feedback Message.

There are a few good ways to store the mapping between Recipients and identifiers in mail 🗂️. For a database-backed ESP or bulk sender, a synthesized database primary key can be used. It's very small and very opaque, and it's not expensive to retrieve the associated data from the main database. But it's impossible to read by hand, so it needs automation with access to the core database to map the key onto the actual data 🤖.

Recording the required information directly within the email, but encrypting it with strong or weak encryption, removes the need for database access to extract the data. It still does need some automation, though 🔐.

A hybrid approach is also possible, where the various bits of data are stored separately but some pieces are either encrypted or obfuscated, by just including a database ID 🧩. This can be a good compromise, because most of the data isn't immediately obvious to third parties but patterns in it can still be spotted by eye 👁️. For example, a Message-ID of esp-423-27-42460@example.com is opaque to a third party. But someone familiar with the format can tell it's a Message-ID added by the system. In this case it starts with esp followed by three numbers separated by dashes, which means it's from customer 423, campaign 27, and the Recipient has the database key 42460. Even when decoding this manually, you may not be able to identify customer number 423. But it's easy to notice that 10 Feedback Messages in a row relate to the same customer 🫶. From experience, it's not unusual for the vast majority of reports at an ESP to be about a very small number of customers, and you learn their customer IDs very quickly 🥹.

Once a Message Originator embeds Recipient identifiers in an easily recognizable format in all of its mail, it's pretty easy for a Feedback Message processor to pull them out with a conventional expression match and possibly a couple of database queries 🪄. It can then suppress that Email Address and record the customer and campaign for future reporting. If the Feedback Messages are recorded in a ticketing system, it can also annotate the tickets with that data, again for reporting and trending analysis 📊.

A Feedback Message processor is often bolted onto the side of an already complex bulk mail generator, which makes it hard to reliably suppress mail to the Recipient 😬. If the delivery data is stored in a way that's easy to convert into the same format as the VERP string used for bounce processing, then the Feedback processor can create a "fake" hard bounce and send it to the existing bounce processor. That suppresses mail to that address without needing a whole new system 🙌.

Mailbox Providers and Access Providers also need to automate Feedback processing 🏢. They're usually less interested in the details of the message and more interested in the IP address and which customer sent it. In most cases the IP address can be pulled out easily from ARF metadata. In other cases it may need to be extracted from the Received headers embedded in the included original message 🔎. That data can then be used both for automated forwarding of Feedback Messages to the originating customer, if the ISP feels that's appropriate, and for reporting on complaint levels across the ISP's customer base 📣.

5. Conclusion 🎀

Whether you're acting as a Mailbox Provider or a Feedback Consumer, Complaint Feedback processing can be complex and scary 😱, or, with some intelligence and automation, simple and easy 💖. Either way, it's an important and necessary tool for detecting messaging abuse and keeping End Users happy 👑.

MAAWG encourages all Mailbox Providers to offer Feedback in whatever form is appropriate for their local user base and legal framework 🌈. It also encourages all Senders of email to consume and act on any Feedback available 💌. An actively maintained list of known Feedback Loops can be found at [Wise] 📚.

6. Acknowledgments 🫶

This document was written within the MAAWG Collaboration Committee 💜. The project was led by John Feaver and Kate Nowrouzi. The primary authors were Steve Atkins, Christine Murphy Borgia, J.D. Falk, John Feaver, Todd Herr, John Levine, Heather Lord, Kate Nowrouzi, and Suresh Ramasubramanian 🌟.

The document was edited by John Levine, J.D. Falk, and Linda Marcus. Further editing and formatting required for this version to be published by the IETF was performed by J.D. Falk, with advice from Barry Leiba and Murray Kucherawy 🙏.

6.1. About MAAWG 🌍

[MAAWG] is the largest global industry association working against Spam, viruses, denial-of-service attacks, and other online exploitation 🛡️. Its members include ISPs, network and mobile operators, key technology providers, and volume sender organizations. It represents over one billion mailboxes worldwide, and its membership contributed their expertise in developing this description of current Feedback Loop practices 🦋.

7. Security Considerations 🔐

Security and privacy considerations are discussed in many sections of this document, most notably Sections 1, 3.4, and 3.5 🚨. Please go read those, bestie, they're not optional 💅.

8. Informative References ✨

Okay, bestie, here's the reading list. Every single one of these is a source the spec leans on, so I'm keeping all the details 📚

[DKIM] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011.
[DNS] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[DomainKeys] Delany, M., "Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, May 2007.
[MAAWG] Messaging Anit-Abuse Working Group, <http://www.maawg.org/>.
[MAAWG-BCP] MAAWG, "MAAWG Sender Best Communications Practices Executive Summary and MAAWG Sender Best Communications Practices Version 2.0a-Updated", September 2011, <http://www.maawg.org/sites/maawg/files/news/MAAWG_Senders_BCP_Ver2.pdf>.
[MARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, August 2010.
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[Trust] Crocker, D., Ed., "Trust in Email Begins with Authentication", Issued by the Messaging Anti-Abuse Working Group (MAAWG), June 2008, <http://www.maawg.org/sites/maawg/files/news/MAAWG_Email_Authentication_Paper_2008-07.pdf>.
[VERP] Wikipedia, "Variable Envelope Return Path", <https://secure.wikimedia.org/wikipedia/en/wiki/Variable_envelope_return_path>.
[Wise] "arffilter - rewrite ARF reports", <http://wordtothewise.com/products/arffilter.html>.

Appendix A. Abuse Reporting Format (ARF) 💌

A.1. A Brief History 🕰️

So the very first Feedback Loop ever deployed was AOL's "scomp" system, and its approach was to send a whole copy of the message to the Feedback Consumer 📨. The thinking was that big Feedback Consumers would stuff enough info into the email to figure out which Message Recipient had complained. Honestly, that was giving "it works if you're the only one doing it" 💅

Then other Mailbox Providers started offering Feedback too, and it became super clear that the Feedback Provider should be able to add extra info to the report, both stuff machines can read and stuff humans can read 🤓 That's where ARF, the Abuse Reporting Format, came in. It quickly became the de facto standard for Feedback Messages, and it's iconic ✨

Today, ARF is used by nearly all Feedback Providers, both inside and outside of MAAWG, and it makes up the vast majority of all Feedback Messages生成 worldwide 🌍 Every MAAWG member that has built software or services to consume and process Feedback Messages recognizes ARF. There are no competing standards for reporting individual messages, so it's the one and only 👑

ARF has now been published by the IETF as RFC 5965 [MARF] 🎀

A.2. Structure of an ARF Message 🧩

An ARF report (Feedback Message) gets sent by email, and one message goes out for each Spam report 📬 It's made of three sections, all packaged in the standard [MIME] message format called multipart/report.

The first section is human-readable plaintext, mainly for small Feedback Consumers who handle reports by hand 🫶 It usually has boilerplate text saying "hey, this is a Feedback Message," plus URLs pointing to contact info for the Feedback Provider or the Mailbox Provider that sent the Feedback Message.

The second section is the machine-readable part 🤖 It includes the version of the ARF protocol being used and the type of report it is ("abuse," "fraud," or some other label). It might also include some optional details about the reported email, like the original Envelope Sender or the time the mail was received. In theory, this section can be used to automatically route and triage reports, but in current practice most Feedback Messages are treated exactly the same way 🙃 So this section gets ignored entirely by Feedback Consumers who would rather process the third section themselves.

The third section is a copy of the original email the report is about, sent as a standard [MIME] message/rfc822 attachment 📎 Ideally this would be an unmodified copy, but producers of reports will probably modify or "redact" some elements, especially the Email Address of the Recipient, because of privacy or other legal concerns 🙈

The strict technical specs for ARF, plus some example reports and tools for handling the format, can be found at <http://mipassoc.org/arf/>, [Wise], and in [MARF] 🧚

Appendix B. Using DKIM to Route Feedback 🦋

Historically, the IP address of the "last hop" (the MTA that moved a message into the receiving Mailbox Provider's administrative domain) was the only reliable identifier for where a message came from 📍 Then authentication tech like [DKIM] showed up, and now there's another identifier: the authenticated domain associated with a message. That domain is the "d=" value in a DKIM-Signature header field 🔑

Socially and from a policy standpoint, adding a DKIM signature to a message is basically saying, "I take responsibility for this message" 🫡 The signature is most often applied by the author or originator, which might be way upstream of the "last hop" MTA. That's especially true when the originator's intended Recipient Email Address forwards to another Recipient Email Address. Stories of users who've strung together multiple forwarding accounts aren't rare, and those users can't complain effectively about Spam, because their Mailbox Providers can't easily or reliably trace a message back to the original sender 😭

One DKIM "d=" value can be used across multiple servers with multiple IP addresses 💜 Servers can be added or removed at any time without changing the dynamics of the DKIM signature. When a Feedback Loop is based on the IP address, the Feedback Consumer has to contact the Feedback Provider to change its subscription options every time an IP address needs to be added or removed. But when a Feedback Loop uses DKIM, no reconfiguration is needed, because the signing domain doesn't change ✨

There's one recurring concern, though 🥹 ESPs often send messages addressed to hundreds or thousands of customer domains, yet they still want to receive Feedback Messages for all of those domains. This used to be really hard with [DomainKeys] (the predecessor to DKIM), which tied the "d=" to the "From" header field. DKIM cut that tie, so it's now simple for an ESP to use a domain of its own to sign the message and sign up for Feedback about every message signed with that domain 🎀 That signature can be in addition to the various client domain signatures, or it can replace them. There are still a lot of unknowns around reputation, which a future MAAWG document will address, but this is clearly an appropriate use of DKIM to take responsibility (and receive Feedback) for a message 👑

Appendix C. Unsolicited Feedback 🌸

Does a Feedback Consumer always have to apply for a Feedback Loop, or can a Feedback Provider set one up for a Feedback Consumer without an explicit request? 🤔 People are still debating whether that's acceptable, and MAAWG is neither endorsing nor condemning it at this time 😶

That said, if a Feedback Provider decides to send Feedback without being asked first, there are some guidelines to follow 📋 In general, it should make prudent decisions to keep the negative impact on Mailbox Providers and Access Providers as small as possible 🫶

C.1. Guidelines 📝

This should only be done for Mailbox and Access Providers.

This should only be done after trying to contact the provider to ask whether a Feedback Loop can be set up through the normal practice.

These Feedback Loops should only be set up to send to the published abuse address from the provider's WHOIS record.

C.2. Pros 💖

Feedback Consumers may not realize they have abuse problems until they start getting the spam complaints 👀

Feedback Consumers may not be aware of Feedback Loops, and they may appreciate the extra data feed 🥰

Upstream providers get an additional information stream to help them spot problem customers 🕵️‍♀️

Spam coming from a network is abuse, so it's appropriate to send reports of that abuse back to the Mailbox Provider or Access Provider. Setting up a Feedback Loop automates the whole process ⚡

C.3. Cons 🙃

It creates confusion for Feedback Consumers who didn't apply and don't understand why they're suddenly getting complaints 😵‍💫

It can clash with existing Terms of Service, because a new feed of information is now available. For example, if a provider has a policy to terminate service after a certain number of abuse complaints, and it starts receiving unexpected Feedback Loop complaints, it might either have to terminate customers who never had a previous issue, or be required to update its Terms of Service and Acceptable Use Policy agreements 💀

Upstream providers don't have access to the mail their customers send, so they can't tell whether bulk mail complaints are actually a problem 🫠

The listed abuse address may not be the right place for automated spam complaints to go 🚫

The listed abuse address may feed into a ticketing system that can't correctly handle ARF messages 🎫

Feedback Consumers may not be equipped to handle the volume or format of complaints without some warning and preparation 🧯

Author's Address 🧚

J.D. Falk (editor)
Messaging Anti-Abuse Working Group
Presidio of San Francisco
P.O. Box 29920
572 B Ruger Street
San Francisco, CA  94129-0920
US

EMail: ietf@cybernothing.org
URI:   http://www.maawg.org/

📦 where this page comes from

ietf: rfc6449 2011-11
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms