RFC 9477

Complaint Feedback Loop Address Header

📅 published September 2023, from ietf

RFC 9477: Complaint Feedback Loop Address Header 💌

okay bestie, here's the title block tea ☕ 🧚

  • Number: RFC 9477
  • Title: Complaint Feedback Loop Address Header
  • Author: J. Benecke, CleverReach GmbH & Co. KG
  • Stream: Independent Submission
  • Category: Experimental
  • Date: September 2023
  • ISSN: 2070-1721
  • Obsoletes/Updates: the header doesn't list anything it obsoletes or updates 🫶

Abstract 💖

okay so this doc is about letting a Message Originator (the person or system sending the email) name a Complaint Feedback Loop (CFBL) address right in a message header field 📨. It also spells out how a complaint gets processed and forwarded 💅.

Why does this matter? Right now there's no standard, automated way for Mailbox Providers (the companies running the inboxes) to get that address. Setting it up and keeping it updated is manual and time-consuming for both sides 😭.

This mechanism is being published as an experiment to collect feedback and see who's actually interested in implementing and deploying it 🔬. It comes through the Independent RFC Stream, so it was not subject to the IETF's approval process 🌈.

Status of This Memo 🎀

This isn't an Internet Standards Track spec. It's published for examination, experimental implementation, and evaluation 🧪.

It defines an Experimental Protocol for the Internet community. It's a contribution to the RFC Series, independent of any other RFC stream ✨. The RFC Editor picked it to publish at their discretion and makes no statement about whether it's worth implementing or deploying 🤷‍♀️. Anything the RFC Editor approves for publication can't become any level of Internet Standard, see Section 2 of RFC 7841 💀.

For the current status, any errata, and how to give feedback, check https://www.rfc-editor.org/info/rfc9477 🔗.

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved 💜.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stood on the publication date. Please read those carefully, because they spell out your rights and restrictions for this document 📜.

Table of Contents 🧚

1.  Introduction and Motivation
  1.1.  Scope of this Experiment
  1.2.  How CFBL Differs from One-Click-Unsubscribe
2.  Conventions Used in This Document
3.  Requirements
  3.1.  Received Message
    3.1.1.  Strict
    3.1.2.  Relaxed
    3.1.3.  Third Party Address
    3.1.4.  DKIM Signature
  3.2.  Multiple CFBL-Address Header Fields
  3.3.  CFBL-Feedback-ID Header Field
  3.4.  Receiving Report Address
  3.5.  Feedback Message
    3.5.1.  XARF Report
4.  Implementation
  4.1.  Message Originator
  4.2.  Mailbox Provider
5.  Header Field Syntax
  5.1.  CFBL-Address
  5.2.  CFBL-Feedback-ID
6.  Security Considerations
  6.1.  Attacks on the Feedback Loop Address
  6.2.  Automatic Suspension of an Account
  6.3.  Enumeration Attacks / Provoking Unsubscription
  6.4.  Data Privacy
  6.5.  Abusing for Validity and Existence Queries
7.  IANA Considerations
  7.1.  CFBL-Address
  7.2.  CFBL-Feedback-ID
8.  Examples
  8.1.  Simple
  8.2.  Data Privacy Safe Report
  8.3.  Data Privacy Safe Report with HMAC
9.  References
  9.1.  Normative References
  9.2.  Informative References
Acknowledgments
Author's Address

1. Introduction and Motivation ✨

This memo extends the CFBL recommendations in [RFC6449] with an automated way for the Message Originator to hand the needed info over to Mailbox Providers 🎁. You should be familiar with the terms and concepts in that doc. Any capitalised terms in this memo are explained there too 📚.

So, per [RFC6449], registering a CFBL is currently a manual job that a human has to do at every Mailbox Provider offering one 😩. The big idea behind [RFC6449] is that getting into the CFBL is a privilege, and Mailbox Providers won't send feedback to anyone they can't reasonably believe is legit 🔐. But manual registration gets really time-consuming when new feedback loops pop up, or when a Message Originator wants to add new IP addresses, DomainKeys Identified Mail (DKIM) domains, or change their complaint address 🫠. Plus, a manual process just isn't a great fit (or even feasible) for smaller Mailbox Providers 🥺.

So here's the plan: Message Originators add a header field, and they don't have to manually register with every Feedback Provider 🙌. Mailbox Providers that are willing can then use that field to send Feedback Messages to the complaint address it names. Cutting out the manual registration and verification is a win for Mailbox Providers too 💅.

Why a message header and not a new DNS record? It makes it easy to tell apart multiple Message Originators without needing any user or admin to step in 🧩. Like, if a company runs several systems, each one can set this header field on its own, and nobody has to touch DNS 🙌. Also, the Mailbox Provider side doesn't need any extra DNS lookup to get the complaint address 🌈.

This mechanism can be run in line with data privacy laws, like the EU's General Data Protection Regulation (GDPR) or the California Consumer Privacy Act (CCPA) 🔒. As Section 6.4 explains, a Feedback Message might contain personal data. This doc describes a way to leave that personal data out of the Feedback Message and just send back a header field 🫶.

⚠️ Real talk: the mechanism below could potentially allow a kind of person-in-the-middle attack between the domain owner and the recipient 😱. A bad actor can craft forged reports that look like they're "from" a domain they're attacking, then send them to the CFBL address 💀. Those fake messages can cause all sorts of trouble, like blocking accounts or deactivating recipient addresses 🚨. This harm, plus others, is described along with possible countermeasures in Section 6 🛡️.

So, the objectives of this doc:

  • Let Message Originators signal that a complaint address exists, without manually registering with every provider 📣.
  • Let Mailbox Providers get a complaint address without building their own manual registration process 🛠️.
  • Give a complaint address to smaller Mailbox Providers who don't have a feedback loop set up yet 🐣.
  • Offer a data privacy safe option for a CFBL 🔐.

1.1. Scope of this Experiment 🧪

The CFBL-Address header field and the CFBL-Feedback-ID header field make up an experiment 🔬. Joining in means either adding the CFBL-Address header field on the Message Originator side, or using the CFBL-Address header field to send Feedback Messages to the address provided on the Mailbox Provider side 💌. Feedback on the results can be emailed to the author, raised as an issue at https://github.com/jpbede/rfc-cfbl-address-header/, or emailed to the IETF cfbl mailing list (cfbl@ietf.org) 📬.

The goal is to answer these questions using real-world deployments 👀:

  • Is there interest among Message Originators and Mailbox Providers?
  • If the Mailbox Provider adds this capability, will Message Originators use it?
  • If the Message Originator adds this capability, will Mailbox Providers use it?
  • Does having the CFBL-Address and CFBL-Feedback-ID header fields introduce extra security issues?
  • What extra security measures or checks need to happen at the Mailbox Provider before a Feedback Message gets sent?
  • What extra security measures or checks need to happen at the Message Originator after a Feedback Message comes in?

This experiment counts as a success if a leading Mailbox Provider uses the CFBL-Address header field, and at least two Message Originators do too, within the next two years 🏆. It's also a success if those parties successfully use the address from the header field to swap Feedback Messages 🥳.

If the experiment works out and these header fields prove valuable and popular, they might get taken to the IETF for further discussion and revision 🌟.

1.2. How CFBL Differs from One-Click-Unsubscribe 🆚

For good reasons, the One-Click-Unsubscribe [RFC8058] signaling already exists, and it might share some interests with this doc 🤝. But this header field requires the List-Unsubscribe header field 😤. The List-Unsubscribe header field's whole purpose is to provide the link to unsubscribe from a list 📋. Because of that, this header field is only used by operators of broadcast marketing lists or mailing lists, and not in normal email traffic 📭.

2. Conventions Used in This Document 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🎯.

In this document, "CFBL" is the abbreviation for "Complaint Feedback Loop", and that's how it'll be referred to from here on 💅.

Syntax descriptions use ABNF [RFC5234] [RFC7405] 🧩.

3. Requirements 📋

3.1. Received Message 📨

This section describes the requirements that must be met for three things: a received message, the message that gets sent from the Message Originator to the Mailbox Provider, and a report that gets sent later 🔍.

3.1.1. Strict 💪

Okay, this is the strict case 🧐. If the domain in the RFC5322.From and the domain in the CFBL-Address header fields are identical, that domain MUST be matched by a valid [DKIM] signature. In that case, the DKIM "d=" parameter and the RFC5322.From field have identical domains 🔗. And that signature MUST meet the requirements described in Section 3.1.4 ✅.

Here's an example that meets this case ✨:

Return-Path: <sender@mailer.example.com>
From: Awesome Newsletter <newsletter@example.com>
To: receiver@example.org
Subject: Super awesome deals for you
CFBL-Address: fbl@example.com; report=arf
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
       h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;

This is a super awesome newsletter.

3.1.2. Relaxed 🦋

okay so if the domain in the CFBL-Address header field is a child domain of RFC5322.From, the RFC5322.From domain MUST be matched by a valid [DKIM] signature 🔐. In this case, the DKIM "d=" parameter and the RFC5322.From domain have an identical domain (Example 1) or a parent domain (Example 2). This signature MUST meet the requirements described in Section 3.1.4 💅.

Example 1:

Return-Path: <sender@mailer.example.com>
From: Awesome Newsletter <newsletter@mailer.example.com>
To: receiver@example.org
Subject: Super awesome deals for you
CFBL-Address: fbl@mailer.example.com; report=arf
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=example.com;
      h=Content-Type:Subject:From:To:Message-ID:
      CFBL-Feedback-ID:CFBL-Address;

This is a super awesome newsletter.

Example 2:

Return-Path: <sender@mailer.example.com>
From: Awesome Newsletter <newsletter@example.com>
To: receiver@example.org
Subject: Super awesome deals for you
CFBL-Address: fbl@mailer.example.com; report=arf
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=example.com;
      h=Content-Type:Subject:From:To:Message-ID:
      CFBL-Feedback-ID:CFBL-Address;

This is a super awesome newsletter.

3.1.3. Third Party Address 🌸

so if the domain in RFC5322.From is different from the domain in the CFBL-Address header field, an extra valid [DKIM] signature MUST be added that matches the domain in the CFBL-Address header field. The other existing valid [DKIM] signature MUST match the domain in the RFC5322.From header field. This double DKIM signature makes sure that both the domain owner of the RFC5322.From domain and the domain owner of the CFBL-Address domain agree on who should receive the Feedback Messages 🫶. Both signatures MUST meet the requirements described in Section 3.1.4.

The following example meets this case:

Return-Path: <sender@saas-mailer.example>
From: Awesome Newsletter <newsletter@example.com>
To: receiver@example.org
Subject: Super awesome deals for you
CFBL-Address: fbl@saas-mailer.example; report=arf
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@example.com>
Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=saas-mailer.example; s=system;
      h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
      h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;

This is a super awesome newsletter.

An Email Service Provider may accept pre-signed messages from its Message Authors, which makes it impossible for it to apply the double signature described above. In that case, the double signature MUST be omitted and the Email Service Provider MUST sign with its domain. Therefore, the pre-signed message MUST NOT include "CFBL-Address" and "CFBL-Feedback-ID" in its "h=" tag 🙈.

This way, the Email Service Provider has the possibility to accept the pre-signed messages and can inject their own CFBL-Address ✨.

The following example meets this case:

Return-Path: <newsletter@example.com>
From: Awesome Newsletter <newsletter@example.com>
To: receiver@example.org
Subject: Super awesome deals for you
CFBL-Address: fbl@saas-mailer.example; report=arf
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@example.com>
Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
      h=Subject:From:To:Message-ID;
DKIM-Signature: v=1; a=rsa-sha256; d=saas-mailer.example; s=system;
      h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;

This is a super awesome newsletter.

3.1.4. DKIM Signature 🔐

When present, CFBL-Address and CFBL-Feedback-ID header fields MUST be included in the "h=" tag of the aforementioned valid DKIM signature 💖.

If the domain is not matched by a valid DKIM signature, or the header field is not covered by the "h=" tag, the Mailbox Provider SHALL NOT send a report message 🚫.

3.2. Multiple CFBL-Address Header Fields 🧚

A Message can contain multiple CFBL-Address header fields. These multiple header fields MUST be treated as a list of addresses, each of which should receive a report 📬.

3.3. CFBL-Feedback-ID Header Field 🎀

The Message Originator MAY include a CFBL-Feedback-ID header field in its messages for various reasons, e.g., their feedback loop processing system can't do anything with the Message-ID header field 🤷‍♀️.

It is RECOMMENDED that the header field include a hard-to-forge protection component, such as an [HMAC] using a secret key, instead of a plaintext string 🔑.

3.4. Receiving Report Address 📥

The receiving report address provided in the CFBL-Address header field MUST accept [ARF] reports.

It is OPTIONAL for the Message Originator to request a [XARF] report, as described in Section 3.5.1 🌈.

3.5. Feedback Message 💌

The Feedback Message (sent by Mailbox Provider to the address provided in the CFBL-Address header field) MUST have a valid [DKIM] signature. This signature MUST match the RFC5322.From domain of the Feedback Message 👑.

If the message does not have the required valid [DKIM] signature, the Message Originator SHALL NOT process this Feedback Message 💀.

The Feedback Message MUST be an [ARF] or [XARF] report. If the Message Originator requests it (described in Section 3.5.1) and it is technically possible for the Mailbox Provider to do so, the Feedback Message MUST be a [XARF] report. Otherwise, the Feedback Message MUST be an [ARF] report.

The third MIME part of the [ARF] or the "Samples" section of the [XARF] report MUST contain the Message-ID [RFC5322] of the received message. If present, the CFBL-Feedback-ID header field of the received message MUST be added to the third MIME part of the [ARF] or to the "Samples" section of the [XARF] report 🧾.

The Mailbox Provider MAY omit or redact all further header fields and/or body to comply with any data regulation laws as described in [RFC6590] 🛡️.

3.5.1. XARF Report 🍓

A Message Originator wishing to receive a [XARF] report MUST append "report=xarf" to the CFBL-Address header field (Section 5.1). The report parameter is separated from the report address by a ";" 🎯.

The resulting header field would appear as shown below.

CFBL-Address: fbl@example.com; report=xarf

4. Implementation ✨

4.1. Message Originator 💅

A Message Originator who wishes to use this new mechanism to receive Feedback Messages MUST include a CFBL-Address header field in their messages 💜.

It is RECOMMENDED that these Feedback Messages be processed automatically. Each Message Originator must decide for themselves what action to take after receiving a Feedback Message 🤔.

The Message Originator MUST take action to address the described requirements in Section 3 🔥.

4.2. Mailbox Provider 🏰

A Mailbox Provider who wants to collect user actions that indicate the message was not wanted, and to send a Feedback Message to the Message Originator, MAY query the CFBL-Address header field and forward the report to the provided CFBL address 🦋.

The Mailbox Provider MUST validate the DKIM requirements of the received message described in Section 3.1, and MUST take action to address the requirements described in Section 3.5 when sending Feedback Messages 🫶.

5. Header Field Syntax 📜

5.1. CFBL-Address 🎀

The following ABNF imports the rules for fields, CFWS, CRLF, and addr-spec from [RFC5322]. Implementations of the CFBL-Address header field MUST comply with [RFC6532] 💖.

fields =/ cfbl-address

cfbl-address = "CFBL-Address:" CFWS addr-spec
               [";" CFWS report-format] CRLF

report-format = %s"report=" (%s"arf" / %s"xarf")

5.2. CFBL-Feedback-ID 🌷

The following ABNF imports the rules for fields, WSP, CRLF, and atext from [RFC5322] 🧩.

fields =/ cfbl-feedback-id

cfbl-feedback-id = "CFBL-Feedback-ID:" CFWS fid CRLF

fid = 1*(atext / ":" / CFWS)

Empty space is ignored in the fid value and MUST be ignored when reassembling the original feedback-id. In particular, the Message Originator can safely insert CFWS in the fid value in arbitrary places to conform to line length limits when adding the header field 🙌.

6. Security Considerations 🚨

This section discusses possible security issues of a CFBL-Address header field and their solutions. Put on your serious hat, bestie, this part matters 👑.

6.1. Attacks on the Feedback Loop Address 📭

Like any other email address, a CFBL address can be an attack vector for malicious messages. For example, CFBL addresses can be flooded with spam 😩. This is an existing problem with any existing email address and is not created by this document.

6.2. Automatic Suspension of an Account 🙅‍♀️

Receiving a Feedback Message regarding a Message Author can cause the Message Author to be unreachable if an automatic account suspension occurs too quickly. For example, someone sends an invitation to their friends, and someone else marks this message as spam for some reason 😭.

If automatic account suspension is too fast, the Message Author's account will be blocked, and the Message Author will not be able to access their emails or send further messages, depending on the account suspension the Message Originator has chosen. Yikes 💀.

Message Originators must take appropriate measures to prevent account suspensions that happen too fast. Therefore, Message Originators have -- mostly proprietary -- ways to assess the trustworthiness of an account. For example, Message Originators may take into account the age of the account and/or any previous account suspension before suspending an account 🕵️‍♀️.

6.3. Enumeration Attacks / Provoking Unsubscription 🕷️

A malicious person may send a series of spoofed Abuse Reporting Format (ARF) messages to known CFBL addresses and attempt to guess a Message-ID / CFBL-Feedback-ID or any other identifiers. The malicious person may attempt to mass unsubscribe/suspend if such an automated system is in place. This is also an existing problem with the current feedback loop implementation and/or One-Click Unsubscription [RFC8058] 😤.

The Message Originator must take appropriate measures. For example, the CFBL-Feedback-ID header field (if used) can use a hard-to-forge component, such as an [HMAC] with a secret key, instead of a plaintext string, to make an enumeration attack impossible 🔒.

6.4. Data Privacy 🫧

The provision of such a header field itself does not pose a data privacy issue. The resulting ARF/XARF report sent by the Mailbox Provider to the Message Originator may violate a data privacy law because it may contain personal data 🥺.

This document already addresses some parts of this problem and describes a way to send a Feedback Message that keeps data privacy safe. As described in Section 3.5, the Mailbox Provider can omit the entire body and/or header field and send only the required fields. As recommended in [RFC6590], the Mailbox Provider can also redact the data in question. Nevertheless, each Mailbox Provider must consider for itself whether this implementation is acceptable and complies with existing data privacy laws in their country 🌍.

As described in Sections 3.5 and 3.3, it is also strongly RECOMMENDED that the Message-ID and CFBL-Feedback-ID (if used) contain a component that is difficult to forge, such as an [HMAC] that uses a secret key, rather than a plaintext string. See Section 8.3 for an example 🔐💜.

6.5. Abusing for Validity and Existence Queries 💀

Okay so this one is giving data privacy drama 😭. This mechanism could be abused to figure out whether an email address is real and existing, which is another data privacy issue 🙈. If the Mailbox Provider has an automatic process that generates a Feedback Message for a received message, it may not be doing the mailbox owner any favors 🫠. When the Mailbox Provider sends that automatic Feedback Message, the Message Originator gets proof that the mailbox exists for sure, because the report is based on a manual action taken by the mailbox owner 👀.

The receiving Mailbox Provider must take appropriate measures 🛡️. One possible countermeasure is pre-existing reputation data (usually proprietary data), for example. With this data, the Mailbox Provider can assess how trustworthy a Message Originator is and decide whether to send a Feedback Message based on that information 🧠✨.

7. IANA Considerations 📋

7.1. CFBL-Address 💌

IANA has registered a new header field, per [RFC3864], in the "Provisional Message Header Field Names" registry:

Header Field Name:  CFBL-Address

Protocol:  mail

Status:

Author/Change controller:  Jan-Philipp Benecke <jpb@cleverreach.com>

Reference:  RFC 9477

7.2. CFBL-Feedback-ID 🆔

IANA has registered a new header field, per [RFC3864], in the "Provisional Message Header Field Names" registry:

Header Field Name:  CFBL-Feedback-ID

Protocol:  mail

Status:

Author/Change controller:  Jan-Philipp Benecke <jpb@cleverreach.com>

Reference:  RFC 9477

8. Examples 🎀

To keep things simple, the DKIM header field has been shortened, and some tags have been left out 🍓.

8.1. Simple 🌸

Email about the report will be generated:

Return-Path: <sender@mailer.example.com>
From: Awesome Newsletter <newsletter@example.com>
To: me@example.net
Subject: Super awesome deals for you
CFBL-Address: fbl@example.com; report=arf
CFBL-Feedback-ID: 111:222:333:4444
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
       h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;

This is a super awesome newsletter.

Resulting ARF report:

------=_Part_240060962_1083385345.1592993161900
Content-Type: message/feedback-report
Content-Transfer-Encoding: 7bit

Feedback-Type: abuse
User-Agent: FBL/0.1
Version: 0.1
Original-Mail-From: sender@mailer.example.com
Arrival-Date: Tue, 23 Jun 2020 06:31:38 GMT
Reported-Domain: example.com
Source-IP: 192.0.2.1

------=_Part_240060962_1083385345.1592993161900
Content-Type: text/rfc822; charset=UTF-8
Content-Transfer-Encoding: 7bit

Return-Path: <sender@mailer.example.com>
From: Awesome Newsletter <newsletter@example.com>
To: me@example.net
Subject: Super awesome deals for you
CFBL-Address: fbl@example.com; report=arf
CFBL-Feedback-ID: 111:222:333:4444
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
       h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;

This is a super awesome newsletter.
------=_Part_240060962_1083385345.1592993161900--

8.2. Data Privacy Safe Report 🔒

Email about the report will be generated:

Return-Path: <sender@mailer.example.com>
From: Awesome Newsletter <newsletter@example.com>
To: me@example.net
Subject: Super awesome deals for you
CFBL-Address: fbl@example.com; report=arf
CFBL-Feedback-ID: 111:222:333:4444
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
       h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;

This is a super awesome newsletter.

Resulting ARF report that only contains the CFBL-Feedback-ID:

------=_Part_240060962_1083385345.1592993161900
Content-Type: message/feedback-report
Content-Transfer-Encoding: 7bit

Feedback-Type: abuse
User-Agent: FBL/0.1
Version: 0.1
Original-Mail-From: sender@mailer.example.com
Arrival-Date: Tue, 23 Jun 2020 06:31:38 GMT
Reported-Domain: example.com
Source-IP: 2001:DB8::25

------=_Part_240060962_1083385345.1592993161900
Content-Type: text/rfc822-headers; charset=UTF-8
Content-Transfer-Encoding: 7bit

CFBL-Feedback-ID: 111:222:333:4444
------=_Part_240060962_1083385345.1592993161900--

8.3. Data Privacy Safe Report with HMAC 🔐

Email about the report will be generated:

Return-Path: <sender@mailer.example.com>
From: Awesome Newsletter <newsletter@example.com>
To: me@example.net
Subject: Super awesome deals for you
CFBL-Address: fbl@example.com; report=arf
CFBL-Feedback-ID: 3789e1ae1938aa2f0dfdfa48b20d8f8bc6c21ac34fc5023d
       63f9e64a43dfedc0
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
       h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;

This is a super awesome newsletter.

Resulting ARF report that only contains the CFBL-Feedback-ID:

------=_Part_240060962_1083385345.1592993161900
Content-Type: message/feedback-report
Content-Transfer-Encoding: 7bit

Feedback-Type: abuse
User-Agent: FBL/0.1
Version: 0.1
Original-Mail-From: sender@mailer.example.com
Arrival-Date: Tue, 23 Jun 2020 06:31:38 GMT
Reported-Domain: example.com
Source-IP: 2001:DB8::25

------=_Part_240060962_1083385345.1592993161900
Content-Type: text/rfc822-headers; charset=UTF-8
Content-Transfer-Encoding: 7bit

CFBL-Feedback-ID: 3789e1ae1938aa2f0dfdfa48b20d8f8bc6c21ac34fc5023d
       63f9e64a43dfedc0
------=_Part_240060962_1083385345.1592993161900--

9. References 📚

9.1. Normative References

9.2. Informative References

Acknowledgments 🫶

Technical and editorial reviews were provided by the colleagues at CleverReach, the colleagues at Certified Senders Alliance and eco.de; Arne Allisat, Tobias Herkula and Levent Ulucan (1&1 Mail & Media); and Sven Krohlas (BFK Edv-consulting). Huge thanks to all of them, they really did the work 👑✨.

Author's Address 💌

Jan-Philipp Benecke
CleverReach GmbH & Co. KG
Schafjueckenweg 2
26180 Rastede
Germany
Phone: +49 4402 97390-16
Email: jpb@cleverreach.com
📦 where this page comes from