wdiff rfc9477.original rfc9477.txt

Network Working Group

Independent Submission J. Benecke
Internet-Draft
Request for Comments: 9477 CleverReach GmbH & Co. KG
Intended status:
Category: Experimental 7 May 2023
Expires: 8 November September 2023
ISSN: 2070-1721

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

Abstract

This document describes a method that allows a Message Originator to
specify a complaint feedback loop (FBL) Complaint Feedback Loop (CFBL) address as a message header
field. Also, it It 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 Mailbox Providers with an
address for a complaint feedback loop. CFBL. Currently, providing and maintaining such an
address is a manual and time-consuming process for Message
Originators and Mailbox Providers.

The mechanism specified in this document is being published as an
experiment,
experiment to gauge interest of, and gather feedback from and gauge the interest of implementers
and deployers. This document is produced through the Independent RFC stream
Stream and was not subject to the IETF's approval process.

Status of This Memo

This Internet-Draft document is submitted in full conformance with the
provisions of BCP 78 not an Internet Standards Track specification; it is
published for examination, experimental implementation, and BCP 79.

Internet-Drafts are working documents of
evaluation.

This document defines an Experimental Protocol for the Internet Engineering
Task Force (IETF). Note that
community. This is a contribution to the RFC Series, independently
of any other groups may also distribute
working documents as Internet-Drafts. RFC stream. The list of current Internet-
Drafts is RFC Editor has chosen to publish this
document at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are draft documents valid not candidates for a maximum any level of six months Internet Standard;
see Section 2 of RFC 7841.

Information about the current status of this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 8 November 2023.
https://www.rfc-editor.org/info/rfc9477.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info)
(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. How CFBL differs Differs from One-Click-Unsubscribe . . . . . . . 5
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 Conventions Used in This Document
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Received Message . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Strict . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. Relaxed . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.3. Third Party Address . . . . . . . . . . . . . . . . . 7
3.1.4. DKIM Signature . . . . . . . . . . . . . . . . . . . 8
3.2. Multiple CFBL-Address Header Fields . . . . . . . . . . . 8
3.3. CFBL-Feedback-ID Header Field . . . . . . . . . . . . . . 8
3.4. Receiving Report Address . . . . . . . . . . . . . . . . 8
3.5. Feedback Message . . . . . . . . . . . . . . . . . . . . 9
3.5.1. XARF Report . . . . . . . . . . . . . . . . . . . . . 9
4. Implementation . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Message Originator . . . . . . . . . . . . . . . . . . . 9
4.2. Mailbox Provider . . . . . . . . . . . . . . . . . . . . 10
5. Header Field Syntax . . . . . . . . . . . . . . . . . . . . . 10
5.1. CFBL-Address . . . . . . . . . . . . . . . . . . . . . . 10
5.2. CFBL-Feedback-ID . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6.1. Attacks on the Feedback Loop Address . . . . . . . . . . 11
6.2. Automatic Suspension of an Account . . . . . . . . . . . 11
6.3. Enumeration Attacks / Provoking Unsubscription . . . . . 11
6.4. Data Privacy . . . . . . . . . . . . . . . . . . . . . . 12
6.5. Abusing for Validity and Existence Queries . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7.1. CFBL-Address . . . . . . . . . . . . . . . . . . . . . . 13
7.2. CFBL-Feedback-ID . . . . . . . . . . . . . . . . . . . . 13
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Simple . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.2. Data Privacy Safe Report . . . . . . . . . . . . . . . . 15
8.3. Data Privacy Safe Report with HMAC . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1.
9.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2.
9.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgments
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18

1. Introduction and Motivation

This memo extends the complaint feedback loop CFBL recommendations described in {!RFC6449}} [RFC6449]
with an automated way to provide the necessary information by the
Message Originator to Mailbox Providers. The reader should be
familiar with the terminology and concepts in that document; terms document. Terms
beginning with capital letters used in this memo are described in
that document.

As described in [RFC6449], the registration for such a complaint
feedback loop CFBL needs to
be done manually by a human at any Mailbox Provider who that provides a complaint feedback loop.
CFBL. The key underpinning of [RFC6449] is that access to the complaint feedback
loop CFBL
is a privilege, privilege and that Mailbox Providers are not prepared to send
feedback to anyone they cannot reasonably believe are legitimate.
However, manual registration and management can be quite
time-consuming time-
consuming if there are new feedback loops rising up, up or if the Message
Originator wants to add new IP addresses, DKIM domains DomainKeys Identified Mail
(DKIM) domains, or change their complaint address. In addition, a
manual process is not well suited and/or or feasible for smaller Mailbox
Providers.

Here

Here, we propose that Message Originators add a header field without
the need to manually register with each Feedback Provider, Provider and that willing
Mailbox Providers can use it to send the Feedback Messages to the
specified complaint address. This simplification or extension of a
manual registration and verification process would be another
advantage for the Mailbox Providers.

A new message header field, rather than a new DNS record, was chosen
to easily distinguish between multiple Message Originators without
requiring user or administrator intervention. For example, if a
company uses multiple systems, each system can set this header field
on its own without requiring users or administrators to make any
changes to their DNS. No additional DNS lookup is required of the
Mailbox Provider side to obtain the complaint address.

The proposed mechanism is capable of being operated in compliance
with the data privacy laws e.g. GDPR laws, e.g., the EU's General Data Protection
Regulation (GDPR) or CCPA. the California Consumer Privacy Act (CCPA). As
described in Section 6.4, a Feedback Message may contain personal data, this
data. This document describes a way to omit this personal data when
sending the Feedback Message and only send back a header field.

Nevertheless, the described mechanism below potentially permits a
kind of man-in-the-middle person-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 these reports to the
complaint feedback loop
CFBL 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 6.

In summary, this document has the following objectives:

* Allow Message Originators 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 Have the ability to provide a complaint address to smaller Mailbox
Providers who do not have a feedback loop in place

* Provide a data privacy safe option for a complaint feedback loop. CFBL.

1.1. Scope of this Experiment

The CFBL-Address header field and the CFBL-Feedback-ID header field
comprise an experiment. Participation in this experiment consists of
adding the CFBL-Address header field on the Message Originators Originator side
or by using the CFBL-Address header field to send Feedback Messages
to the provided address on the 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/ <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 Message Originator Originators and Mailbox Providers?

* If the Mailbox Provider adds this capability, will it be used by
the Message Originators?

* If the Message Originator adds this capability, will it be used by
the Mailbox Providers?

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

* What additional security measures/checks need to be performed at
the Mailbox Provider before a Feedback Message is sent?

* What additional security measures/checks need to be performed at
the Message Originator after a Feedback Message is received?

This experiment will be considered successful if the CFBL-Address
header field is used by a leading Mailbox Provider and by at least
two Message Originators within the next two years and years. It will also be
considered a success if these parties successfully use the address
specified in the header field to exchange Feedback Messages.

If this experiment is successful and these header fields prove to be
valuable and popular, the header fields may be taken to the IETF for
further discussion and revision.

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

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

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

The key word "CFBL" in

In this document document, "CFBL" is the abbreviation for
"complaint feedback loop" "Complaint Feedback
Loop" and will hereafter be used.

Syntax descriptions use ABNF [RFC5234] [RFC7405].

3. Requirements

3.1. Received Message

This section describes the requirements that must be met for the
following: a received message, the message that is sent from the
Message Originator to the Mailbox
Provider Provider, and about which a report that is to
be sent later, must meet. later.

3.1.1. Strict

If the domain in the [RFC5322].From RFC5322.From and the domain in the CFBL-
Address CFBL-Address
header field fields are identical, this domain MUST be matched by a valid
[DKIM] signature. In this case, the DKIM "d=" parameter and the [RFC5322].From
RFC5322.From field have identical 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.

3.1.2. Relaxed

If the domain in CFBL-Address header field is a child domain of
RFC5322.From, the
[RFC5322].From, the [RFC5322].From RFC5322.From domain MUST be matched by a valid
[DKIM] signature. In this case, the DKIM "d=" parameter and the
[RFC5322].From
RFC5322.From domain have a an identical (Example 1) or parent (Example
2) domain. 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

If the domain in [RFC5322].From RFC5322.From differs from the domain in the CFBL-
Address header field, an additional 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
RFC5322.From header field. This double DKIM signature ensures that
both,
both the domain owner of the [RFC5322].From RFC5322.From domain and the domain owner
of the CFBL-Address domain, domain agree on who should receive the Feedback
Messages. Both signature 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, making it impossible for it to apply the double
signature described above, above; in which case this case, the double signature MUST BE 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= "h=" tag.

This way 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 neither not matched by a valid DKIM signature nor 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 receive report
addresses so that addresses, each address can
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 out of for various reasons, e.g. 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 hard-to-forge
protection component component, such as an [HMAC] using a secret key, instead
of a plain-text plaintext string.

3.4. Receiving Report Address

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

The

It is OPTIONAL for the Message Originator can OPTIONALLY 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 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 a an [ARF] or [XARF] report. If the
Message Originator requests it (described in Section 3.5.1), 3.5.1) and it is
technically possible for the Mailbox Provider to do so, the Feedback
Message MUST be a [XARF] report, otherwise report. Otherwise, the Feedback Message
MUST be a an [ARF] report.

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

The Mailbox Provider MAY omit or redact, as described in [RFC6590], redact all further header fields
and/or body to comply with any data- data regulation laws. 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 look like the following: 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, they Originator MAY query the CFBL-Address header field and
forward the report to the provided complaint feedback loop CFBL address.

The Mailbox Provider MUST validate the DKIM requirements of the
received Message 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 CRLF, and
addr-spec from
[MAIL]. [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 CRLF, and atext
from [MAIL]. [RFC5322].

fields =/ cfbl-feedback-id

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

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

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

6. Security Considerations

This section discusses possible security issues, and their possible
solutions, issues of a complaint feedback loop address CFBL-Address
header field. field and their solutions.

6.1. Attacks on the Feedback Loop Address

Like any other email address, a complaint feedback loop CFBL address can be an attack vector
for malicious messages. For example, complaint
feedback loop 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. An example: For example, someone sends an invitation to
their
friends. For some reason, friends, and someone else marks this message as spam.

Now, if there is too fast spam for some
reason.

If automatic account suspension, 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 is able to send further messages, depending on the
account suspension the Message Originator has chosen.

Message Originators must take appropriate measures to prevent too
fast account suspensions.
suspensions that happen too fast. Therefore, Message Originators therefore
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 ARF Abuse Reporting
Format (ARF) messages to known
complaint feedback loop CFBL addresses and attempt to guess a Message-ID/
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, a
countermeasure would be, that measures. For example,
the CFBL-Feedback-ID header field, if
used, field (if used) can use a hard-to-forge component
component, such as a an [HMAC] with a secret
key key, instead of a
plaintext string 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 data privacy safe way to send a Feedback Message. 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 Section Sections 3.5 and in Section 3.3, it is also strongly RECOMMENDED
that the Message-ID and, if used, the CFBL-Feedback-ID. and CFBL-Feedback-ID (if used) contain a
component that is difficult to forge, such as a 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

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

The receiving Mailbox Provider must take appropriate measures. One
possible countermeasure could be, for example, be pre-existing reputation data, usually data
(usually proprietary data. data), for example. Using this data, the
Mailbox Provider can assess the trustworthiness of a Message
Originator and decide whether to send a Feedback Message based on
this information.

7. IANA Considerations

7.1. CFBL-Address

The

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

Header field name: Field Name: CFBL-Address

Applicable protocol:

Protocol: mail

Status: provisional

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

Specification document: this document

Reference: RFC 9477

7.2. CFBL-Feedback-ID

The

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

Header field name: Field Name: CFBL-Feedback-ID

Applicable protocol:

Protocol: mail

Status: provisional

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

Specification document: this document

Reference: RFC 9477

8. Examples

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

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

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

8.2. Data Privacy Safe Report

Email about the report will be generated:

This is a super awesome newsletter.

Resulting ARF report contains 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 contains 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. 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).

10. References

10.1.

9.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/rfc/rfc5965>.
<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/rfc/rfc6376>.

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

[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/rfc/rfc2119>.
<https://www.rfc-editor.org/info/rfc2119>.

[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/rfc/rfc5234>.
<https://www.rfc-editor.org/info/rfc5234>.

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

[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
2012, <https://www.rfc-editor.org/rfc/rfc6532>. <https://www.rfc-editor.org/info/rfc6532>.

[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/rfc/rfc7405>.
<https://www.rfc-editor.org/info/rfc7405>.

[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/rfc/rfc8174>. <https://www.rfc-editor.org/info/rfc8174>.

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

10.2. commit cc1a6e6,
March 2023, <https://github.com/abusix/xarf>.

9.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/rfc/rfc2104>.
<https://www.rfc-editor.org/info/rfc2104>.

[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/rfc/rfc3864>.
<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/rfc/rfc6590>.
<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/rfc/rfc8058>.
<https://www.rfc-editor.org/info/rfc8058>.

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

Author's Address

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