Complaint Feedback Loop Address Header
draft-benecke-cfbl-address-header-08

Network Working Group                                         J. Benecke
Internet-Draft                                 CleverReach GmbH & Co. KG
Intended status: Experimental                           14 November 2022
Expires: 18 May 2023

                 Complaint Feedback Loop Address Header
                  draft-benecke-cfbl-address-header-08

Abstract

   This document describes a method that allows an email sender to
   specify a complaint feedback loop (FBL) address as an email header.
   Also, it defines the rules for processing and forwarding such a
   complaint.  The motivation for this arises out of the absence of a
   standardized and automated way to provide mailbox providers with an
   address for a complaint feedback loop.  Currently, providing and
   maintaining such an address is a manual and time-consuming process
   for email senders and providers.

   It is unclear, at the time of publication, whether the function
   provided by this document has widespread demand, and whether the
   mechanism offered will be adopted and found to be useful.  Therefore,
   this is being published as an Experiment, looking for a constituency
   of implementers and deployers, and for feedback on the operational
   utility.  The document is produced through the Independent RFC stream
   and was not subject to the IETF's approval process.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 18 May 2023.

Benecke                    Expires 18 May 2023                  [Page 1]
Internet-Draft             CFBL Address Header             November 2022

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Table of Contents

   1.  Introduction and Motivation . . . . . . . . . . . . . . . . .   3
     1.1.  Scope of this Experiment  . . . . . . . . . . . . . . . .   4
     1.2.  Difference to One-Click-Unsubscribe . . . . . . . . . . .   5
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Received email  . . . . . . . . . . . . . . . . . . . . .   6
       3.1.1.  Strict  . . . . . . . . . . . . . . . . . . . . . . .   6
       3.1.2.  Relaxed . . . . . . . . . . . . . . . . . . . . . . .   7
       3.1.3.  Third Party Address . . . . . . . . . . . . . . . . .   7
       3.1.4.  DKIM signature  . . . . . . . . . . . . . . . . . . .   9
     3.2.  Report email  . . . . . . . . . . . . . . . . . . . . . .   9
   4.  Implementation  . . . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  Email senders . . . . . . . . . . . . . . . . . . . . . .   9
     4.2.  Mailbox provider  . . . . . . . . . . . . . . . . . . . .  10
   5.  Complaint report  . . . . . . . . . . . . . . . . . . . . . .  10
     5.1.  XARF compatible report  . . . . . . . . . . . . . . . . .  11
   6.  Header Syntax . . . . . . . . . . . . . . . . . . . . . . . .  11
     6.1.  CFBL-Address  . . . . . . . . . . . . . . . . . . . . . .  11
     6.2.  CFBL-Feedback-ID  . . . . . . . . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
     7.1.  Attacks on the FBL address  . . . . . . . . . . . . . . .  11
     7.2.  Automatic suspension of an account  . . . . . . . . . . .  12
     7.3.  Enumeration attacks / provoking unsubscription  . . . . .  12
     7.4.  GDPR and other data-regulation laws . . . . . . . . . . .  12
     7.5.  Abusing for Validity and Existence Queries  . . . . . . .  13
     7.6.  Over-Signing when accepting pre-signed emails . . . . . .  13
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     8.1.  CFBL-Address  . . . . . . . . . . . . . . . . . . . . . .  14
     8.2.  CFBL-Feedback-ID  . . . . . . . . . . . . . . . . . . . .  14
   9.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
     9.1.  Simple  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     9.2.  GDPR safe report  . . . . . . . . . . . . . . . . . . . .  16
     9.3.  GDPR safe report with HMAC  . . . . . . . . . . . . . . .  16
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  17
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17

Benecke                    Expires 18 May 2023                  [Page 2]
Internet-Draft             CFBL Address Header             November 2022

     11.1.  Normative References . . . . . . . . . . . . . . . . . .  17
     11.2.  Informative References . . . . . . . . . . . . . . . . .  18
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction and Motivation

   For a long time there has been a way for a mailbox provider to
   forward manual complaints back to the email sender.  The mailbox
   provider provides what is called a feedback loop [RFC6449].  This
   feedback loop is used to give operators of, e.g. broadcast marketing
   lists, feedback on resulting complaints from their marketing
   mailings.  These complaints are based on manual user interaction,
   e.g.  IMAP movement to "junk" or by clicking on a "This is spam"
   button.

   As described in [RFC6449] the registration for such a feedback loop
   needs to be done manually by a human at any mailbox provider who
   provides a FBL.  This can be quite time-consuming if there are new
   feedback loops rising up, or the email sender wants to add new IP
   addresses or DKIM domains.  In addition, a manual process is not well
   suited and/or feasible for smaller mailbox providers.

   Because of the manual process involved, the email sender has to go
   through all providers again, delete his existing subscriptions and
   register with their new complaint address.

   This document addresses this issue with a new email header.  It
   extends the recommendations for the complaint feedback loop described
   in [RFC6449] with an automated way to submit the necessary
   information to mailbox providers.

   Mail senders can add this header, willing mailbox providers can use
   it to forward the generated report to the specified complaint
   address.  The email sender only needs to add an email header and does
   not need to manually register with each feedback loop provider.  The
   elimination of a manual registration and verification process would
   be another advantage for the mailbox providers.

   A new email header has been chosen in favour of a new DNS record to
   easily distinguish between multiple broadcast marketing list
   operators / email senders without requiring user or administrator
   intervention.  For example, if a company uses multiple mailing
   systems, each system can set this header itself without requiring any
   change by the users or administrators within their DNS.  No
   additional DNS query is required on the mailbox provider side to
   obtain the complaint address.

Benecke                    Expires 18 May 2023                  [Page 3]
Internet-Draft             CFBL Address Header             November 2022

   This document has been prepared in compliance with the GDPR and other
   data protection laws to address the resulting issues when providing
   an automated address for a complaint feedback loop, as the email may
   contain personal data.

   Nevertheless, the described mechanism bellow potentially permits a
   kind of man-in-the-middle attack between the domain owner and the
   recipient.  A bad actor can generate forged reports to be "from" a
   domain name the bad actor is attacking and send this reports to the
   complaint FBL address.  These fake messages can result in a number of
   actions, such as blocking of accounts or deactivating recipient
   addresses.  This potential harm and others are described with
   potential countermeasures in Section 7.

   In summary, this document has the following objectives:

   *  Allow email senders to signal that a complaint address exists
      without requiring manual registration with all providers.

   *  Allow mailbox providers to obtain a complaint address without
      developing their own manual registration process.

   *  Be able to provide a complaint address to smaller mailbox
      providers who do not have a feedback loop in place

   *  Provide a GDPR-compliant option for a complaint feedback loop.

1.1.  Scope of this Experiment

   The CFBL-Address header and the CFBL-Feedback-ID header are an
   experiment.  Participation in this experiment consists of adding the
   CFBL-Address-Header on email sender side or by using the CFBl-
   Address-Header to send FBL reports to the provided address on mailbox
   provider side.  Feedback on the results of this experiment can be
   emailed to the author, raised as an issue at
   https://github.com/jpbede/rfc-cfbl-address-header/ or can be emailed
   to the IETF cfbl mailing list (cfbl@ietf.org).

   The goal of this experiment is to answer the following questions
   based on real-world deployments:

   *  Is there interest among email sender and mailbox providers?

   *  If the mailbox provider adds this capability, will it be used by
      the senders?

   *  If the email sender adds this capability, will it be used by the
      mailbox provider?

Benecke                    Expires 18 May 2023                  [Page 4]
Internet-Draft             CFBL Address Header             November 2022

   *  Does the presence of the CFBL-Address/CFBL-Feedback-ID field
      introduce additional security issues?

   *  What additional security measures/checks need to be performed at
      the mailbox provider before a complaint report is sent?

   *  What additional security measures/checks need to be performed at
      the email sender after a complaint report is received?

   This experiment is considered successful if the CFBL-Address header
   has been implemented by multiple independent parties (email sender
   and mailbox provider) and these parties successfully use the address
   specified in the header to exchange feedback loop reports.

   If this experiment is successful and these headers prove to be
   valuable and popular, it may be taken to the IETF for further
   discussion and revision.  One possible outcome could be that a
   working group creates a specification for the standard track.

1.2.  Difference to One-Click-Unsubscribe

   For good reasons, the One-Click-Unsubscribe [RFC8058] signaling
   already exists, which may have several interests in common with this
   document.  However, this header requires the List-Unsubscribe header,
   whose purpose is to provide the link to unsubscribe from a list.  For
   this reason, this header is only used by operators of broadcast
   marketing lists or mailing lists, not in normal email traffic.

   The main interest of this document now is to provide an automated way
   to signal mailbox providers an address for a complaint feedback loop.
   It is the obligation of the email sender to decide for themselves
   what action to take after receiving a notification; this is not the
   subject of this document.

2.  Definitions

   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.

   The keyword "CFBL" in this document is the abbreviation for
   "complaint feedback loop" and will hereafter be used.

   The keyword "MBP" in this document is the abbreviation for "mailbox
   provider", it is the party who receives an email and provides an
   email mailbox to end users.  It will be used hereafter.

Benecke                    Expires 18 May 2023                  [Page 5]
Internet-Draft             CFBL Address Header             November 2022

   The keyword "ESP" in this document is the abbreviation for "email
   service provider", it is used to describe a party who provides email
   services to a third party e.g. broadcast marketing list operator, in
   most cases an ESP does not provide mailbox services.  It will be used
   hereafter.

   The keyword "email sender" in this document is used to describe the
   party who sends an email.  This can be an MBP, a broadcast marketing
   list operator or any other email sending party.  It will be used
   hereafter.

3.  Requirements

3.1.  Received email

   This section describes the requirements that a received email, i.e.
   the email that is sent from the email sender to the MBP and about
   which a report is to be sent later, must meet.

3.1.1.  Strict

   If the domain in the [RFC5322].From and the domain in the CFBL-
   Address header are identical, this domain MUST be covered by a valid
   [DKIM] signature.  In this case, the DKIM "d=" parameter and the
   [RFC5322].From field have identical DNS domains.  This signature MUST
   meet the requirements described in Section 3.1.4.

   The following example 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.

Benecke                    Expires 18 May 2023                  [Page 6]
Internet-Draft             CFBL Address Header             November 2022

3.1.2.  Relaxed

   If the domain in CFBL-Address is a child domain of the
   [RFC5322].From, the [RFC5322].From domain MUST be covered by a valid
   [DKIM] signature.  In this case, the DKIM "d=" parameter and the
   [RFC5322].From domain have a identical (Example 1) or parent (Example
   2) DNS domains.  This signature MUST meet the requirements described
   in Section 3.1.4.

   Example 1:

   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.

   Example 2:

   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.

3.1.3.  Third Party Address

   If the domain in [RFC5322].From differs from the domain in the CFBL-
   Address header, the domain of the CFBL-Address header MUST be covered
   by an additional valid [DKIM] signature.  Both signatures MUST meet
   the requirements described in Section 3.1.4.

Benecke                    Expires 18 May 2023                  [Page 7]
Internet-Draft             CFBL Address Header             November 2022

   This double DKIM signature ensures that both, the domain owner of the
   [RFC5322].From domain and the domain owner of the CFBL-Address
   domain, agree to receive the complaint reports on the address from
   the CFBL-Address header.

   The following example meets this case:

   Return-Path: <sender@super-saas-mailer.com>
   From: Awesome Newsletter <newsletter@example.com>
   To: receiver@example.org
   Subject: Super awesome deals for you
   CFBL-Address: fbl@super-saas-mailer.com; 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=super-saas-mailer.com; 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.

   If an ESP does not have full control over the signing process and
   wants to accept pre-signed mails from its email senders, the double
   signature described above can be omitted and the ESP can sign with
   its domain.  Therefor the pre-signed email MUST NOT include "CFBL-
   Address" and "CFBL-Feedback-ID" in its h= tag.

   This way the ESP has the possibility to accept the emails and can
   inject their own CFBL-Address.

   Due to this granted exception a malicious actor can destroy this
   possibility with over-signing.  This potential harm is described in
   Section 7.

   The following example meets this case:

Benecke                    Expires 18 May 2023                  [Page 8]
Internet-Draft             CFBL Address Header             November 2022

   Return-Path: <newsletter@example.com>
   From: Awesome Newsletter <newsletter@example.com>
   To: receiver@example.org
   Subject: Super awesome deals for you
   CFBL-Address: fbl@super-saas-mailer.com; 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=super-saas-mailer.com; s=system;
          h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;

   This is a super awesome newsletter.

3.1.4.  DKIM signature

   The CFBL-Address header MUST be included in the "h=" tag of the
   aforementioned valid DKIM-Signature.  When the CFBL-Feedback-ID
   header is used, it MUST also be included in the "h=" tag of the
   aforementioned valid DKIM signature.

   If the domain has neither the required coverage by a valid DKIM
   signature nor the required header coverage by the "h=" tag, the MBP
   SHALL NOT send a report email.

3.2.  Report email

   The report email (sent by MBP to email sender) MUST have a valid
   [DKIM] signature.  The aforementioned valid DKIM signature MUST cover
   the From: header [MAIL] domain, from which the report is sent to the
   email sender.

   If the message does not have the required valid [DKIM] signature, the
   email sender SHALL NOT process this complaint report.

   As part of this experiment, it is recommended to determine what
   plausibility and security checks are useful and achievable.

4.  Implementation

4.1.  Email senders

   An email sender who wishes to receive complaints about their emails
   MUST include a CFBL-Address header in their messages.

   The receiving complaint FBL address specified in the messages MUST
   accept [ARF] compatible reports by default.  The email sender can
   OPTIONALLY request a [XARF] compatible report if they want one, as

Benecke                    Expires 18 May 2023                  [Page 9]
Internet-Draft             CFBL Address Header             November 2022

   described in Section 5.1.  The MBP MAY send a [XARF] compatible
   report if it is technically possible for them to do so, otherwise a
   [ARF] compatible report will be sent.

   It is strongly RECOMMENDED that these reports be processed
   automatically.  Each sender must decide for themselves what action to
   take after receiving a report.

   The email sender MUST take action to address the described
   requirements in Section 3.

4.2.  Mailbox provider

   If the MBP wants to process the complaints and forward it, they MUST
   query the CFBL-Address header and forward the report to the complaint
   FBL address.

   By default, an [ARF] compatible report MUST be sent.  Per [RFC6449]
   Section 3.2, a complaint report MUST be sent when a manual action has
   been taken e.g., when a receiver marks a mail as spam, by clicking
   the "This is spam"-button in any web portal or by moving a mail to
   junk folder, this also includes [IMAP] and [POP3] movements.  The MBP
   SHALL NOT send any report when an automatic decisions has been made
   e.g., spam filtering.

   The MBP MUST send a [XARF] compatible report when the email sender
   requests it as described in Section 5.1.  If it is not possible for
   the MBP to send a [XARF] compatible report as requested, a [ARF]
   compatible report MUST be sent.

   The MBP MUST validate and take action to address the described
   requirements in Section 3.

5.  Complaint report

   The complaint report MAY be a [XARF] report if the email sender
   requests it, and it is technically possible for the MBP to do so,
   otherwise the complaint report MUST be a [ARF] report.

   The report MUST contain at least the Message-ID [MAIL].  If present,
   the header "CFBL-Feedback-ID" of the complaining email MUST be added
   additionally.

   The MBP MAY omit or redact, as described in [RFC6590], all further
   headers and/or body to comply with any data-regulation laws.

Benecke                    Expires 18 May 2023                 [Page 10]
Internet-Draft             CFBL Address Header             November 2022

   It is highly RECOMMENDED that, if used, the CFBL-Feedback-ID includes
   a hard to forge component such as an [HMAC] using a secret key,
   instead of a plain-text string.

5.1.  XARF compatible report

   A email sender wishing to receive a [XARF] compliant report MUST
   append "report=xarf" to the Section 6.1.  The resulting header would
   look like the following:

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

6.  Header Syntax

6.1.  CFBL-Address

   The following ABNF imports fields, WSP, CRLF and addr-spec from
   [MAIL].

   fields /= cfbl-address

   cfbl-address = "CFBL-Address:" 0*1WSP addr-spec
                  [";" 0*1WSP report-format] CRLF

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

6.2.  CFBL-Feedback-ID

   The following ABNF imports fields, WSP, CRLF and atext from [MAIL].

   fields /= cfbl-feedback-id

   cfbl-feedback-id = "CFBL-Feedback-ID:" 0*1WSP fid CRLF

   fid = 1*(atext / ":")

7.  Security Considerations

   This section discusses possible security issues, and their possible
   solutions, of a complaint FBL address header.

7.1.  Attacks on the FBL address

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

Benecke                    Expires 18 May 2023                 [Page 11]
Internet-Draft             CFBL Address Header             November 2022

   The email sender must take appropriate measures.  One possible
   countermeasure would be a rate limit for the delivering IP.  However,
   this should be done with caution; normal FBL email traffic must not
   be affected.

7.2.  Automatic suspension of an account

   Sending an FBL report against a mailbox can cause the account holder
   to be unreachable if an automatic account suspension occurs too
   quickly.  An example: someone sends an invitation to his friends.
   For some reason, someone marks this mail as spam.  Now, if there is
   too fast automatic account suspension, the sender's account will be
   blocked and the sender will not be able to access his mails.

   MBPs and email senders must take appropriate measures to prevent
   this.  MBPs and email senders therefore have - mostly proprietary -
   ways to assess the trustworthiness of an account.  For example, MBPs
   and email senders may take into account the age of the account and/or
   any previous account suspension before suspending an account.

7.3.  Enumeration attacks / provoking unsubscription

   A malicious person may send a series of spoofed ARF messages to known
   complaint FBL 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 FBL
   implementation and/or One-Click Unsubscription [RFC8058].

   The sender of the received email must take appropriate measures.  As
   a countermeasure, it is recommended that the CFBL-Feedback-ID, if
   used, use a hard-to-forge component such as a [HMAC] with a secret
   key instead of a plaintext string to make an enumeration attack
   impossible.

   If it is impossible for the email sender to use a component that is
   difficult to fake, they should take steps to avoid enumeration
   attacks.

7.4.  GDPR and other data-regulation laws

   The provision of such a header itself does not pose a data protection
   issue.  The resulting ARF report sent by the MBP to the email sender
   may violate a data protection law because it may contain personal
   data.

Benecke                    Expires 18 May 2023                 [Page 12]
Internet-Draft             CFBL Address Header             November 2022

   This document already addresses some parts of this problem and
   describes a privacy-safe way to send a FBL report.  As described in
   Section 5, the MBP can omit the entire body and/or header and send
   only the required fields.  As described in [RFC6590], the MBP can
   also redact the data in question.  Nevertheless, each MBP must
   consider for itself whether this implementation is acceptable and
   complies with existing privacy laws.

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

   Using HMAC, or any other hard to forge component, ensures that only
   the email sender has knowledge about the data.

7.5.  Abusing for Validity and Existence Queries

   This mechanism could be abused to determine the validity and
   existence of an email address, which exhibits another potential
   privacy issue.  Now, if the MBP has an automatic process to generate
   a complaint report for a received email, it may not be doing the
   mailbox owner any favors.  As the MBP now generates an automatic
   complaint report for the received email, the MBP now proves to the
   email sender that this mailbox exists for sure, because it is based
   on a manual action of the mailbox owner.

   The receiving MBP must take appropriate measures.  One possible
   countermeasure could be, for example, pre-existing reputation data,
   usually proprietary data.  Using this data, the MBP can assess the
   trustworthiness of an email sender and decide whether to send a
   complaint report based on this information.

7.6.  Over-Signing when accepting pre-signed emails

   When accepting pre-signed mails, a malicious actor can destroy the
   possibility of adding the CFBL-Address header by the ESP, with "over-
   signing".  This methode "over-signing" is described in [DKIM]
   Section 5.4.

   The ESP must take appropriate measures.  ESPs therefore have - mostly
   proprietary - methods for assessing the trustworthiness of an account
   and decide on this basis whether to accept pre-signed emails.

8.  IANA Considerations

Benecke                    Expires 18 May 2023                 [Page 13]
Internet-Draft             CFBL Address Header             November 2022

8.1.  CFBL-Address

   The IANA is requested to register a new header field, per [RFC3864],
   into the "Provisional Message Header Field Names" registry:

   Header field name: CFBL-Address

   Applicable protocol: mail

   Status: provisional

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

   Specification document: this document

8.2.  CFBL-Feedback-ID

   The IANA is requested to register a new header field, per [RFC3864],
   into the "Provisional Message Header Field Names" registry:

   Header field name: CFBL-Feedback-ID

   Applicable protocol: mail

   Status: provisional

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

   Specification document: this document

9.  Examples

   For simplicity the DKIM header has been shortened, and some tags have
   been omitted.

9.1.  Simple

   Email about the report will be generated:

Benecke                    Expires 18 May 2023                 [Page 14]
Internet-Draft             CFBL Address Header             November 2022

   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--

Benecke                    Expires 18 May 2023                 [Page 15]
Internet-Draft             CFBL Address Header             November 2022

9.2.  GDPR 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 contains only 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--

9.3.  GDPR safe report with HMAC

   Email about the report will be generated:

Benecke                    Expires 18 May 2023                 [Page 16]
Internet-Draft             CFBL Address Header             November 2022

   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 contains only 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--

10.  Acknowledgments

   Technical and editorial reviews were provided by the colleagues at
   CleverReach, the colleagues at Certified Senders Alliance and eco.de,
   Levent Ulucan (Inxmail), Arne Allisat and Tobias Herkula (1&1 Mail &
   Media) and Sven Krohlas (BFK Edv-consulting).

11.  References

11.1.  Normative References

Benecke                    Expires 18 May 2023                 [Page 17]
Internet-Draft             CFBL Address Header             November 2022

   [ARF]      Shafranovich, Y., Levine, J., and M. Kucherawy, "An
              Extensible Format for Email Feedback Reports", RFC 5965,
              DOI 10.17487/RFC5965, August 2010,
              <https://www.rfc-editor.org/info/rfc5965>.

   [DKIM]     Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
              "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
              RFC 6376, DOI 10.17487/RFC6376, September 2011,
              <https://www.rfc-editor.org/info/rfc6376>.

   [MAIL]     Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/info/rfc5322>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/info/rfc5322>.

   [RFC6449]  Falk, J., Ed., "Complaint Feedback Loop Operational
              Recommendations", RFC 6449, DOI 10.17487/RFC6449, November
              2011, <https://www.rfc-editor.org/info/rfc6449>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [XARF]     Abusix, "eXtended Abuse Reporting Format",
              Web https://github.com/abusix/xarf.

11.2.  Informative References

   [HMAC]     Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997,
              <https://www.rfc-editor.org/info/rfc2104>.

   [IMAP]     Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
              Access Protocol (IMAP) - Version 4rev2", RFC 9051,
              DOI 10.17487/RFC9051, August 2021,
              <https://www.rfc-editor.org/info/rfc9051>.

Benecke                    Expires 18 May 2023                 [Page 18]
Internet-Draft             CFBL Address Header             November 2022

   [POP3]     Myers, J. and M. Rose, "Post Office Protocol - Version 3",
              STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996,
              <https://www.rfc-editor.org/info/rfc1939>.

   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
              Procedures for Message Header Fields", BCP 90, RFC 3864,
              DOI 10.17487/RFC3864, September 2004,
              <https://www.rfc-editor.org/info/rfc3864>.

   [RFC6590]  Falk, J., Ed. and M. Kucherawy, Ed., "Redaction of
              Potentially Sensitive Data from Mail Abuse Reports",
              RFC 6590, DOI 10.17487/RFC6590, April 2012,
              <https://www.rfc-editor.org/info/rfc6590>.

   [RFC8058]  Levine, J. and T. Herkula, "Signaling One-Click
              Functionality for List Email Headers", RFC 8058,
              DOI 10.17487/RFC8058, January 2017,
              <https://www.rfc-editor.org/info/rfc8058>.

Author's Address

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

Benecke                    Expires 18 May 2023                 [Page 19]