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

Network Working Group                                         J. Benecke
Internet-Draft                                 CleverReach GmbH & Co. KG
Intended status: Experimental                              July 08, 2021
Expires: January 9, 2022

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

Abstract

   This document describes a method to allow a mail sender to specify a
   complaint feedback loop address as an email header and how a mail
   receiver can use it.  This document also 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 a complaint feedback loop address to mailbox providers.
   Currently, providing and maintaining such an address is a manual to a
   time-consuming process for mail senders and mailbox providers.

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 January 9, 2022.

Copyright Notice

   Copyright (c) 2021 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.  Code Components extracted from this document must

Benecke                  Expires January 9, 2022                [Page 1]
Internet-Draft             CFBL Address Header                 July 2021

   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction and Motivation . . . . . . . . . . . . . . . . .   2
     1.1.  Difference to One-Click-Unsubscribe . . . . . . . . . . .   4
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Complaining about an email  . . . . . . . . . . . . . . .   5
     3.2.  Report email  . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Implementation  . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Mail senders  . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Mailbox provider  . . . . . . . . . . . . . . . . . . . .   6
   5.  Complaint report  . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  XARF compatible report  . . . . . . . . . . . . . . . . .   6
   6.  Header Syntax . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  CFBL-Address  . . . . . . . . . . . . . . . . . . . . . .   7
     6.2.  CFBL-Feedback-ID  . . . . . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     7.1.  Attacks on the FBL address  . . . . . . . . . . . . . . .   7
     7.2.  Automatic suspension of an account  . . . . . . . . . . .   7
     7.3.  Enumeration attacks / provoking unsubscription  . . . . .   8
     7.4.  GDPR and other data-regulation laws . . . . . . . . . . .   8
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  CFBL-Address  . . . . . . . . . . . . . . . . . . . . . .   9
     8.2.  CFBL-Feedback-ID  . . . . . . . . . . . . . . . . . . . .   9
   9.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Simple  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.2.  GDPR safe report  . . . . . . . . . . . . . . . . . . . .  11
     9.3.  GDPR safe report with HMAC  . . . . . . . . . . . . . . .  11
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     11.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction and Motivation

   For a long time there is a way for a mailbox provider to forward
   manual complaints back to the mail sender, which can be a mailbox
   provider, or an operator of a broadcast marketing list.  The mailbox
   provider provides a so-called feedback loop [RFC6449].  This feedback
   loop is being used to give e.g., operators of broadcast marketing
   lists feedback about resulting complaints from their marketing
   mailings.  Those complaints are based on manual user interaction
   e.g., IMAP movement to "Junk".

Benecke                  Expires January 9, 2022                [Page 2]
Internet-Draft             CFBL Address Header                 July 2021

   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 an FBL, and he wants to receive complaints from.  This can
   be quite time-consuming if there are new feedback loops rising up, or
   the mail sender wants to add new ip addresses or DKIM domains.
   Besides, a manual process isn't well suitable and/or doable for
   smaller mailbox providers.

   The change of such a complaint address e.g., due to an infrastructure
   change is another problem.  Due to this manual process the mail
   sender needs to go through all providers again and delete his
   existing subscriptions and re-signup with the new complaint address.

   This document addresses this problem with a new email header.  It
   extends the described complaint feedback loop recommendations in
   [RFC6449] with an automated way to provide the complaint feedback
   loop address to mailbox providers.

   Mail senders can add this header and willing mailbox provider can use
   this header to forward the generated report to the provided complaint
   address.  The mail sender just needs to add an email header and isn't
   required to signup manually at every feedback loop provider.  Another
   benefit would be the mailbox provider doesn't need to develop a
   manual registration process and verification process.

   A new email header has been chosen over a new DNS record in favour to
   be able to easily distinguish between multiple broadcast marketing
   list operators / mail senders, without the intervention of its users
   or administrators.  For example, if a company uses multiple sending
   systems, each system can set this header on their own, without the
   need of a change that has to be done by its users or administrators.
   On the side of the mailbox provider, there is no need to do an
   additional DNS query to get the complaint address.

   This document has been created with GDPR and other data-regulation
   laws in mind and to address the resulting problems in providing an
   automated complaint feedback loop address, as the email may contain
   personal data.

   Summarised this document has following goals:

   o  Allow mail senders to signal that there is a complaint address
      without a manual registration at all providers

   o  Have a way for mailbox provider to get a complaint address without
      developing an own manual registration process

Benecke                  Expires January 9, 2022                [Page 3]
Internet-Draft             CFBL Address Header                 July 2021

   o  Be able to provide a complaint address to smaller mailbox
      providers who do not have a feedback loop registration process

   o  Provide a GDPR compliant way for a complaint feedback loop

1.1.  Difference to One-Click-Unsubscribe

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

   The main interest of this document is now to provide an automated way
   to signal a complaint feedback loop address to mailbox providers.  It
   is the mail sender's obligation to consider on their own which
   measure they want to take after receiving a report, this is out of
   scope of this document.

2.  Definitions

   The keywords "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 "FBL" in this document is the abbreviation for "feedback
   loop" and will hereafter be used.

   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 will be used
   hereafter.

   The keyword "mail 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

Benecke                  Expires January 9, 2022                [Page 4]
Internet-Draft             CFBL Address Header                 July 2021

3.1.  Complaining about an email

   The email (sent by mail sender to MBP) about which a complaint should
   be sent MUST have at least a valid [DKIM] signature.  The
   aforementioned valid DKIM signature MUST cover at least the CFBL-
   Address header domain.  It is RECOMMENDED that the DKIM signature
   aligns with the CFBL-Address header domain and the From header [MAIL]
   domain where possible.  The CFBL-Address header MUST be included in
   the "h=" tag of the aforementioned valid DKIM-Signature.

   If the message isn't properly aligned, nor it does have the required
   header coverage by the "h=" tag of a valid DKIM-Signature, the MBP
   SHALL NOT send a report email.

   This ensures that only reports are sent to the complaint address that
   are based on an authenticated email.

3.2.  Report email

   The report email (sent by MBP to mail sender) MUST have a valid
   [DKIM] signature and MUST cover the From header [MAIL] domain.

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

   It is highly RECOMMENDED that the mail sender does further
   plausibility checks.

4.  Implementation

4.1.  Mail senders

   A mail sender that wishes to receive complaints about their emails
   MUST place a CFBL-Address header in the message.  The mail sender MAY
   place a CFBL-Feedback-ID header in the message out of various
   reasons.

   The receiving complaint FBL address, placed in the message, MUST
   accept by default [ARF] compatible reports.

   The mail sender can OPTIONAL request, as described in Section 5.1, a
   [XARF] compatible report.  The MBP MAY send a [XARF] compatible
   report, if it is technical possible for him, otherwise a [ARF]
   compatible reports will be sent.

   It is highly RECOMMENDED processing these reports automatically.
   Each mail sender must consider on their own which measure they take
   after receiving a report.

Benecke                  Expires January 9, 2022                [Page 5]
Internet-Draft             CFBL Address Header                 July 2021

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

4.2.  Mailbox provider

   An MBP MAY process the complaint and forward it to the complaint FBL
   address.  If the MBP wants to process the complaints and forwards it,
   he MUST query the CFBL-Address header.

   By default, an [ARF] compatible 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 includes also [IMAP] and [POP3] movements.
   The MBP SHALL NOT send any report when an automatic decisions has
   been made e.g., spam filtering.

   The MBP SHOULD send a [XARF] compatible report, if the mail sender
   requests it as described in Section 5.1.  If this is not possible 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 (sent by MBP to mail sender) MUST be an [ARF]
   report by default.  The complaint report MAY be an [XARF] report, if
   the mail sender requests it, and the MBP can send it.

   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 all further headers and/or body to comply with any
   data-regulation laws.

   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 mail sender that wishes to receive a [XARF] compatible report, MUST
   append "report=xarf" to the CFBL-Address header (Section 6.1).  The
   resulting header would be the following:

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

Benecke                  Expires January 9, 2022                [Page 6]
Internet-Draft             CFBL Address Header                 July 2021

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

   As any other email address, a complaint FBL addresses can be an
   attack vector for malicious emails.  The complaint FBL addresses can
   be for example flooded with spam.  This is an existing problem with
   any existing email address and isn't newly created by this document.

   The mail sender must take appropriated measures.  One possible
   countermeasure would be a rate limit on the delivering IP.  However,
   this should be done with caution, the normal FBL email traffic must
   not be impaired.

7.2.  Automatic suspension of an account

   Sending a FBL report against a mailbox may lead into an
   inaccessibility for the account owner, if there is a too quick
   automatic account suspension.  For example, someone sends an
   invitation to his friends.  For somewhat reason someone marks this
   mail as spam.  Now, if there is a too quick automatic account

Benecke                  Expires January 9, 2022                [Page 7]
Internet-Draft             CFBL Address Header                 July 2021

   suspension in place, the senders account will be suspended, and the
   sender can't access his mails anymore.

   MBPs and mail senders MUST take appropriate measures to prevent this.
   MBPs and mail senders have therefore, mostly proprietary, ways to
   evaluate the trustworthiness of an account.  For example MBPs and
   mail senders can consider the account age and/or any other account
   suspension that happened beforehand, before an account gets
   suspended.

7.3.  Enumeration attacks / provoking unsubscription

   A malicious person can send a bunch of forged ARF reports to a known
   complaint FBL addresses and try to guess a Message-ID/CFBL-Feedback-
   ID.  He might try to do a mass-unsubscription/suspension, if there is
   such an automatic in place.  This is also an already existing problem
   with the current FBL implementation and/or the One-Click-
   Unsubscription [RFC8058].

   The receiving mail sender MUST take appropriated measures.

   As a countermeasure it is recommended that the Message-ID and, if
   used, CFBL-Feedback-ID uses a hard to forge component such as an
   [HMAC] using a secret key, instead of a plain-text string, to make an
   enumeration attack impossible.

   If it is impossible for the mail sender to use a hard to forge
   component, the mail sender should take measures to avoid enumeration
   attacks.

7.4.  GDPR and other data-regulation laws

   Providing such a header itself doesn't produce a data-regulation law
   problem.  The resulting ARF report, that is sent to the mail sender
   by the MBP, may conflict with a data-regulation law, as it may
   contain personal data.

   This document already addresses some parts of this problem and
   describes a data-regulation law safe way to send a FBL report.  As
   described in Section 5, the MBP may omit the complete body and/or
   headers and just sends the required fields.  Nevertheless, each MBP
   must consider on their own, if this implementation is acceptable and
   complies with the existing data-regulation laws.

   As described in Section 5, it is also highly RECOMMENDED that the
   Message-ID and, 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.  See Section 9.3 for an example.

Benecke                  Expires January 9, 2022                [Page 8]
Internet-Draft             CFBL Address Header                 July 2021

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

8.  IANA Considerations

8.1.  CFBL-Address

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

   Header field name: CFBL-Address

   Applicable protocol: mail

   Status: experimental

   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 "Permanent Message Header Field Names" registry:

   Header field name: CFBL-Feedback-ID

   Applicable protocol: mail

   Status: experimental

   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 has
   been omitted.

9.1.  Simple

   Email about the report will be generated:

Benecke                  Expires January 9, 2022                [Page 9]
Internet-Draft             CFBL Address Header                 July 2021

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

   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
   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.
   ------=_Part_240060962_1083385345.1592993161900--

Benecke                  Expires January 9, 2022               [Page 10]
Internet-Draft             CFBL Address Header                 July 2021

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
   Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
   CFBL-Feedback-ID: 111:222:333:4444
   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.

   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:deaf:beef::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 January 9, 2022               [Page 11]
Internet-Draft             CFBL Address Header                 July 2021

   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
   Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
   CFBL-Feedback-ID: 3789e1ae1938aa2f0dfdfa48b20d8f8bc6c21ac34fc5023d
          63f9e64a43dfedc0
   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.

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

   ------=_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 and comments were provided by the
   colleagues at CleverReach, the colleagues at Certified Senders
   Alliance and eco.de, Arne Allisat and Tobias Herkula (1&1 Mail &
   Media) and Sven Krohlas (BFK Edv-consulting).

Benecke                  Expires January 9, 2022               [Page 12]
Internet-Draft             CFBL Address Header                 July 2021

11.  References

11.1.  Normative References

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

   [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]     Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
              4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
              <https://www.rfc-editor.org/info/rfc3501>.

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

Benecke                  Expires January 9, 2022               [Page 13]
Internet-Draft             CFBL Address Header                 July 2021

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

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

   [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
   Rastede  26180
   Germany

   Phone: +49 4402 97390-16
   Email: jpb@cleverreach.com

Benecke                  Expires January 9, 2022               [Page 14]