rfc9477.original   rfc9477.txt 
Network Working Group J. Benecke Independent Submission J. Benecke
Internet-Draft CleverReach GmbH & Co. KG Request for Comments: 9477 CleverReach GmbH & Co. KG
Intended status: Experimental 7 May 2023 Category: Experimental September 2023
Expires: 8 November 2023 ISSN: 2070-1721
Complaint Feedback Loop Address Header Complaint Feedback Loop Address Header
draft-benecke-cfbl-address-header-13
Abstract Abstract
This document describes a method that allows a Message Originator to This document describes a method that allows a Message Originator to
specify a complaint feedback loop (FBL) address as a message header specify a Complaint Feedback Loop (CFBL) address as a message header
field. Also, it defines the rules for processing and forwarding such field. It also defines the rules for processing and forwarding such
a complaint. The motivation for this arises out of the absence of a a complaint. The motivation for this arises out of the absence of a
standardized and automated way to provide Mailbox Providers with an standardized and automated way to provide Mailbox Providers with an
address for a complaint feedback loop. Currently, providing and address for a CFBL. Currently, providing and maintaining such an
maintaining such an address is a manual and time-consuming process address is a manual and time-consuming process for Message
for Message Originators and Mailbox Providers. Originators and Mailbox Providers.
The mechanism specified in this document is being published as an The mechanism specified in this document is being published as an
experiment, to gauge interest of, and gather feedback from experiment to gather feedback and gauge the interest of implementers
implementers and deployers. This document is produced through the and deployers. This document is produced through the Independent RFC
Independent RFC stream and was not subject to the IETF's approval Stream and was not subject to the IETF's approval process.
process.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for examination, experimental implementation, and
evaluation.
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 This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This is a contribution to the RFC Series, independently
time. It is inappropriate to use Internet-Drafts as reference of any other RFC stream. The RFC Editor has chosen to publish this
material or to cite them other than as "work in progress." document at its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not candidates for any level of Internet Standard;
see Section 2 of RFC 7841.
This Internet-Draft will expire on 8 November 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9477.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents Table of Contents
1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 1. Introduction and Motivation
1.1. Scope of this Experiment . . . . . . . . . . . . . . . . 4 1.1. Scope of this Experiment
1.2. How CFBL differs from One-Click-Unsubscribe . . . . . . . 5 1.2. How CFBL Differs from One-Click-Unsubscribe
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions Used in This Document
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements
3.1. Received Message . . . . . . . . . . . . . . . . . . . . 5 3.1. Received Message
3.1.1. Strict . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Strict
3.1.2. Relaxed . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.2. Relaxed
3.1.3. Third Party Address . . . . . . . . . . . . . . . . . 7 3.1.3. Third Party Address
3.1.4. DKIM Signature . . . . . . . . . . . . . . . . . . . 8 3.1.4. DKIM Signature
3.2. Multiple CFBL-Address Header Fields . . . . . . . . . . . 8 3.2. Multiple CFBL-Address Header Fields
3.3. CFBL-Feedback-ID Header Field . . . . . . . . . . . . . . 8 3.3. CFBL-Feedback-ID Header Field
3.4. Receiving Report Address . . . . . . . . . . . . . . . . 8 3.4. Receiving Report Address
3.5. Feedback Message . . . . . . . . . . . . . . . . . . . . 9 3.5. Feedback Message
3.5.1. XARF Report . . . . . . . . . . . . . . . . . . . . . 9 3.5.1. XARF Report
4. Implementation . . . . . . . . . . . . . . . . . . . . . . . 9 4. Implementation
4.1. Message Originator . . . . . . . . . . . . . . . . . . . 9 4.1. Message Originator
4.2. Mailbox Provider . . . . . . . . . . . . . . . . . . . . 10 4.2. Mailbox Provider
5. Header Field Syntax . . . . . . . . . . . . . . . . . . . . . 10 5. Header Field Syntax
5.1. CFBL-Address . . . . . . . . . . . . . . . . . . . . . . 10 5.1. CFBL-Address
5.2. CFBL-Feedback-ID . . . . . . . . . . . . . . . . . . . . 10 5.2. CFBL-Feedback-ID
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations
6.1. Attacks on the Feedback Loop Address . . . . . . . . . . 11 6.1. Attacks on the Feedback Loop Address
6.2. Automatic Suspension of an Account . . . . . . . . . . . 11 6.2. Automatic Suspension of an Account
6.3. Enumeration Attacks / Provoking Unsubscription . . . . . 11 6.3. Enumeration Attacks / Provoking Unsubscription
6.4. Data Privacy . . . . . . . . . . . . . . . . . . . . . . 12 6.4. Data Privacy
6.5. Abusing for Validity and Existence Queries . . . . . . . 12 6.5. Abusing for Validity and Existence Queries
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations
7.1. CFBL-Address . . . . . . . . . . . . . . . . . . . . . . 13 7.1. CFBL-Address
7.2. CFBL-Feedback-ID . . . . . . . . . . . . . . . . . . . . 13 7.2. CFBL-Feedback-ID
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Examples
8.1. Simple . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Simple
8.2. Data Privacy Safe Report . . . . . . . . . . . . . . . . 15 8.2. Data Privacy Safe Report
8.3. Data Privacy Safe Report with HMAC . . . . . . . . . . . 15 8.3. Data Privacy Safe Report with HMAC
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 9. References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References
10.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.2. Informative References
10.2. Informative References . . . . . . . . . . . . . . . . . 17 Acknowledgments
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address
1. Introduction and Motivation 1. Introduction and Motivation
This memo extends the complaint feedback loop recommendations This memo extends the CFBL recommendations described in [RFC6449]
described in {!RFC6449}} with an automated way to provide the with an automated way to provide the necessary information by the
necessary information by the Message Originator to Mailbox Providers. Message Originator to Mailbox Providers. The reader should be
The reader should be familiar with the terminology and concepts in familiar with the terminology and concepts in that document. Terms
that document; terms beginning with capital letters used in this memo beginning with capital letters used in this memo are described in
are described in that document. that document.
As described in [RFC6449], the registration for such a complaint As described in [RFC6449], the registration for such a CFBL needs to
feedback loop needs to be done manually by a human at any Mailbox be done manually by a human at any Mailbox Provider that provides a
Provider who provides a complaint feedback loop. The key CFBL. The key underpinning of [RFC6449] is that access to the CFBL
underpinning of [RFC6449] is that access to the complaint feedback is a privilege and Mailbox Providers are not prepared to send
loop is a privilege, and that Mailbox Providers are not prepared to feedback to anyone they cannot reasonably believe are legitimate.
send feedback to anyone they cannot reasonably believe are However, manual registration and management can be quite time-
legitimate. However, manual registration and management can be quite consuming if there are new feedback loops rising up or if the Message
time-consuming if there are new feedback loops rising up, or if the Originator wants to add new IP addresses, DomainKeys Identified Mail
Message Originator wants to add new IP addresses, DKIM domains or (DKIM) domains, or change their complaint address. In addition, a
change their complaint address. In addition, a manual process is not manual process is not well suited or feasible for smaller Mailbox
well suited and/or feasible for smaller Mailbox Providers. Providers.
Here we propose that Message Originators add a header field without Here, we propose that Message Originators add a header field without
the need to manually register with each Feedback Provider, and that the need to manually register with each Feedback Provider and willing
willing Mailbox Providers can use it to send the Feedback Messages to Mailbox Providers can use it to send the Feedback Messages to the
the specified complaint address. This simplification or extension of specified complaint address. This simplification or extension of a
a manual registration and verification process would be another manual registration and verification process would be another
advantage for the Mailbox Providers. advantage for the Mailbox Providers.
A new message header field, rather than a new DNS record, was chosen A new message header field, rather than a new DNS record, was chosen
to easily distinguish between multiple Message Originators without to easily distinguish between multiple Message Originators without
requiring user or administrator intervention. For example, if a requiring user or administrator intervention. For example, if a
company uses multiple systems, each system can set this header field company uses multiple systems, each system can set this header field
on its own without requiring users or administrators to make any on its own without requiring users or administrators to make any
changes to their DNS. No additional DNS lookup is required of the changes to their DNS. No additional DNS lookup is required of the
Mailbox Provider side to obtain the complaint address. Mailbox Provider side to obtain the complaint address.
The proposed mechanism is capable of being operated in compliance The proposed mechanism is capable of being operated in compliance
with the data privacy laws e.g. GDPR or CCPA. As described in with data privacy laws, e.g., the EU's General Data Protection
Section 6.4, a Feedback Message may contain personal data, this Regulation (GDPR) or the California Consumer Privacy Act (CCPA). As
document describes a way to omit this personal data when sending the described in Section 6.4, a Feedback Message may contain personal
Feedback Message and only send back a header field. 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 Nevertheless, the described mechanism below potentially permits a
kind of man-in-the-middle attack between the domain owner and the kind of person-in-the-middle attack between the domain owner and the
recipient. A bad actor can generate forged reports to be "from" a 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 domain name the bad actor is attacking and send these reports to the
complaint feedback loop address. These fake messages can result in a CFBL address. These fake messages can result in a number of actions,
number of actions, such as blocking of accounts or deactivating such as blocking accounts or deactivating recipient addresses. This
recipient addresses. This potential harm and others are described potential harm and others are described with potential
with potential countermeasures in Section 6. countermeasures in Section 6.
In summary, this document has the following objectives: In summary, this document has the following objectives:
* Allow Message Originators to signal that a complaint address * Allow Message Originators to signal that a complaint address
exists without requiring manual registration with all providers. exists without requiring manual registration with all providers.
* Allow Mailbox Providers to obtain a complaint address without * Allow Mailbox Providers to obtain a complaint address without
developing their own manual registration process. developing their own manual registration process.
* Be able to provide a complaint address to smaller Mailbox * Have the ability to provide a complaint address to smaller Mailbox
Providers who do not have a feedback loop in place Providers who do not have a feedback loop in place
* Provide a data privacy safe option for a complaint feedback loop. * Provide a data privacy safe option for a CFBL.
1.1. Scope of this Experiment 1.1. Scope of this Experiment
The CFBL-Address header field and the CFBL-Feedback-ID header field The CFBL-Address header field and the CFBL-Feedback-ID header field
comprise an experiment. Participation in this experiment consists of comprise an experiment. Participation in this experiment consists of
adding the CFBL-Address header field on Message Originators side or adding the CFBL-Address header field on the Message Originator side
by using the CFBL-Address header field to send Feedback Messages to or by using the CFBL-Address header field to send Feedback Messages
the provided address on Mailbox Provider side. Feedback on the to the provided address on the Mailbox Provider side. Feedback on
results of this experiment can be emailed to the author, raised as an the results of this experiment can be emailed to the author, raised
issue at https://github.com/jpbede/rfc-cfbl-address-header/ or can be as an issue at <https://github.com/jpbede/rfc-cfbl-address-header/>,
emailed to the IETF cfbl mailing list (cfbl@ietf.org). or can be emailed to the IETF cfbl mailing list (cfbl@ietf.org).
The goal of this experiment is to answer the following questions The goal of this experiment is to answer the following questions
based on real-world deployments: based on real-world deployments:
* Is there interest among Message Originator and Mailbox Providers? * Is there interest among Message Originators and Mailbox Providers?
* If the Mailbox Provider adds this capability, will it be used by * If the Mailbox Provider adds this capability, will it be used by
the Message Originators? the Message Originators?
* If the Message Originator adds this capability, will it be used by * If the Message Originator adds this capability, will it be used by
the Mailbox Providers? the Mailbox Providers?
* Does the presence of the CFBL-Address and CFBL-Feedback-ID header * Does the presence of the CFBL-Address and CFBL-Feedback-ID header
field introduce additional security issues? fields introduce additional security issues?
* What additional security measures/checks need to be performed at * What additional security measures/checks need to be performed at
the Mailbox Provider before a Feedback Message is sent? the Mailbox Provider before a Feedback Message is sent?
* What additional security measures/checks need to be performed at * What additional security measures/checks need to be performed at
the Message Originator after a Feedback Message is received? the Message Originator after a Feedback Message is received?
This experiment will be considered successful if the CFBL-Address This experiment will be considered successful if the CFBL-Address
header field is used by a leading Mailbox Provider and by at least header field is used by a leading Mailbox Provider and by at least
two Message Originators within the next two years and these parties two Message Originators within the next two years. It will also be
successfully use the address specified in the header field to considered a success if these parties successfully use the address
exchange Feedback Messages. specified in the header field to exchange Feedback Messages.
If this experiment is successful and these header fields prove to be 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 valuable and popular, the header fields may be taken to the IETF for
further discussion and revision. further discussion and revision.
1.2. How CFBL differs from One-Click-Unsubscribe 1.2. How CFBL Differs from One-Click-Unsubscribe
For good reasons, the One-Click-Unsubscribe [RFC8058] signaling For good reasons, the One-Click-Unsubscribe [RFC8058] signaling
already exists, which may have several interests in common with this already exists and may have several interests in common with this
document. However, this header field requires the List-Unsubscribe document. However, this header field requires the List-Unsubscribe
header field, whose purpose is to provide the link to unsubscribe header field. The purpose of this header field is to provide the
from a list. For this reason, this header field is only used by link to unsubscribe from a list. For this reason, this header field
operators of broadcast marketing lists or mailing lists, not in is only used by operators of broadcast marketing lists or mailing
normal email traffic. lists and not in normal email traffic.
2. Definitions 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The key word "CFBL" in this document is the abbreviation for In this document, "CFBL" is the abbreviation for "Complaint Feedback
"complaint feedback loop" and will hereafter be used. Loop" and will hereafter be used.
Syntax descriptions use ABNF [RFC5234] [RFC7405]. Syntax descriptions use ABNF [RFC5234] [RFC7405].
3. Requirements 3. Requirements
3.1. Received Message 3.1. Received Message
This section describes the requirements that a received message, the This section describes the requirements that must be met for the
message that is sent from the Message Originator to the Mailbox following: a received message, the message that is sent from the
Provider and about which a report is to be sent later, must meet. Message Originator to the Mailbox Provider, and a report that is to
be sent later.
3.1.1. Strict 3.1.1. Strict
If the domain in the [RFC5322].From and the domain in the CFBL- If the domain in the RFC5322.From and the domain in the CFBL-Address
Address header field are identical, this domain MUST be matched by a header fields are identical, this domain MUST be matched by a valid
valid [DKIM] signature. In this case, the DKIM "d=" parameter and [DKIM] signature. In this case, the DKIM "d=" parameter and the
the [RFC5322].From field have identical domains. This signature MUST RFC5322.From field have identical domains. This signature MUST meet
meet the requirements described in Section 3.1.4. the requirements described in Section 3.1.4.
The following example meets this case: The following example meets this case:
Return-Path: <sender@mailer.example.com> Return-Path: <sender@mailer.example.com>
From: Awesome Newsletter <newsletter@example.com> From: Awesome Newsletter <newsletter@example.com>
To: receiver@example.org To: receiver@example.org
Subject: Super awesome deals for you Subject: Super awesome deals for you
CFBL-Address: fbl@example.com; report=arf CFBL-Address: fbl@example.com; report=arf
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com> Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
Content-Type: text/plain; charset=utf-8 Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news; DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address; h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
This is a super awesome newsletter. This is a super awesome newsletter.
3.1.2. Relaxed 3.1.2. Relaxed
If the domain in CFBL-Address header field is a child domain of the If the domain in CFBL-Address header field is a child domain of
[RFC5322].From, the [RFC5322].From domain MUST be matched by a valid RFC5322.From, the RFC5322.From domain MUST be matched by a valid
[DKIM] signature. In this case, the DKIM "d=" parameter and the [DKIM] signature. In this case, the DKIM "d=" parameter and the
[RFC5322].From domain have a identical (Example 1) or parent (Example RFC5322.From domain have an identical (Example 1) or parent (Example
2) domain. This signature MUST meet the requirements described in 2) domain. This signature MUST meet the requirements described in
Section 3.1.4. Section 3.1.4.
Example 1: Example 1:
Return-Path: <sender@mailer.example.com> Return-Path: <sender@mailer.example.com>
From: Awesome Newsletter <newsletter@mailer.example.com> From: Awesome Newsletter <newsletter@mailer.example.com>
To: receiver@example.org To: receiver@example.org
Subject: Super awesome deals for you Subject: Super awesome deals for you
CFBL-Address: fbl@mailer.example.com; report=arf CFBL-Address: fbl@mailer.example.com; report=arf
skipping to change at page 7, line 20 skipping to change at line 298
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com> Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
Content-Type: text/plain; charset=utf-8 Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; DKIM-Signature: v=1; a=rsa-sha256; d=example.com;
h=Content-Type:Subject:From:To:Message-ID: h=Content-Type:Subject:From:To:Message-ID:
CFBL-Feedback-ID:CFBL-Address; CFBL-Feedback-ID:CFBL-Address;
This is a super awesome newsletter. This is a super awesome newsletter.
3.1.3. Third Party Address 3.1.3. Third Party Address
If the domain in [RFC5322].From differs from the domain in the CFBL- If the domain in RFC5322.From differs from the domain in the CFBL-
Address header field, an additional valid [DKIM] signature MUST be Address header field, an additional valid [DKIM] signature MUST be
added that matches the domain in the CFBL-Address header field. The added that matches the domain in the CFBL-Address header field. The
other existing valid [DKIM] signature MUST match the domain in the other existing valid [DKIM] signature MUST match the domain in the
[RFC5322].From header field. This double DKIM signature ensures that RFC5322.From header field. This double DKIM signature ensures that
both, the domain owner of the [RFC5322].From domain and the domain both the domain owner of the RFC5322.From domain and the domain owner
owner of the CFBL-Address domain, agree who should receive the of the CFBL-Address domain agree on who should receive the Feedback
Feedback Messages. Both signature MUST meet the requirements Messages. Both signatures MUST meet the requirements described in
described in Section 3.1.4. Section 3.1.4.
The following example meets this case: The following example meets this case:
Return-Path: <sender@saas-mailer.example> Return-Path: <sender@saas-mailer.example>
From: Awesome Newsletter <newsletter@example.com> From: Awesome Newsletter <newsletter@example.com>
To: receiver@example.org To: receiver@example.org
Subject: Super awesome deals for you Subject: Super awesome deals for you
CFBL-Address: fbl@saas-mailer.example; report=arf CFBL-Address: fbl@saas-mailer.example; report=arf
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@example.com> Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@example.com>
Content-Type: text/plain; charset=utf-8 Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=saas-mailer.example; s=system; DKIM-Signature: v=1; a=rsa-sha256; d=saas-mailer.example; s=system;
h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address; h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news; DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address; h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
This is a super awesome newsletter. This is a super awesome newsletter.
An Email Service Provider may accept pre-signed messages from its An Email Service Provider may accept pre-signed messages from its
Message Authors, making it impossible for it to apply the double Message Authors, making it impossible for it to apply the double
signature described above, in which case the double signature MUST BE signature described above; in this case, the double signature MUST be
omitted and the Email Service Provider MUST sign with its domain. omitted and the Email Service Provider MUST sign with its domain.
Therefore, the pre-signed message MUST NOT include "CFBL-Address" and Therefore, the pre-signed message MUST NOT include "CFBL-Address" and
"CFBL-Feedback-ID" in its h= tag. "CFBL-Feedback-ID" in its "h=" tag.
This way the Email Service Provider has the possibility to accept the This way, the Email Service Provider has the possibility to accept
pre-signed messages and can inject their own CFBL-Address. the pre-signed messages and can inject their own CFBL-Address.
The following example meets this case: The following example meets this case:
Return-Path: <newsletter@example.com> Return-Path: <newsletter@example.com>
From: Awesome Newsletter <newsletter@example.com> From: Awesome Newsletter <newsletter@example.com>
To: receiver@example.org To: receiver@example.org
Subject: Super awesome deals for you Subject: Super awesome deals for you
CFBL-Address: fbl@saas-mailer.example; report=arf CFBL-Address: fbl@saas-mailer.example; report=arf
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@example.com> Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@example.com>
Content-Type: text/plain; charset=utf-8 Content-Type: text/plain; charset=utf-8
skipping to change at page 8, line 29 skipping to change at line 355
DKIM-Signature: v=1; a=rsa-sha256; d=saas-mailer.example; s=system; DKIM-Signature: v=1; a=rsa-sha256; d=saas-mailer.example; s=system;
h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address; h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
This is a super awesome newsletter. This is a super awesome newsletter.
3.1.4. DKIM Signature 3.1.4. DKIM Signature
When present, CFBL-Address and CFBL-Feedback-ID header fields MUST be When present, CFBL-Address and CFBL-Feedback-ID header fields MUST be
included in the "h=" tag of the aforementioned valid DKIM signature. included in the "h=" tag of the aforementioned valid DKIM signature.
If the domain is neither matched by a valid DKIM signature nor the If the domain is not matched by a valid DKIM signature or the header
header field is covered by the "h=" tag, the Mailbox Provider SHALL field is not covered by the "h=" tag, the Mailbox Provider SHALL NOT
NOT send a report message. send a report message.
3.2. Multiple CFBL-Address Header Fields 3.2. Multiple CFBL-Address Header Fields
A Message can contain multiple CFBL-Address header fields. These A Message can contain multiple CFBL-Address header fields. These
multiple header fields MUST be treated as a list of receive report multiple header fields MUST be treated as a list of addresses, each
addresses so that each address can receive a report. of which should receive a report.
3.3. CFBL-Feedback-ID Header Field 3.3. CFBL-Feedback-ID Header Field
The Message Originator MAY include a CFBL-Feedback-ID header field in The Message Originator MAY include a CFBL-Feedback-ID header field in
its messages out of various reasons, e.g. their feedback loop its messages for various reasons, e.g., their feedback loop
processing system can't do anything with the Message-ID header field. processing system can't do anything with the Message-ID header field.
It is RECOMMENDED that the header field include a hard to forge It is RECOMMENDED that the header field include a hard-to-forge
protection component such as an [HMAC] using a secret key, instead of protection component, such as an [HMAC] using a secret key, instead
a plain-text string. of a plaintext string.
3.4. Receiving Report Address 3.4. Receiving Report Address
The receiving report address provided in the CFBL-Address header The receiving report address provided in the CFBL-Address header
field MUST accept [ARF] reports. field MUST accept [ARF] reports.
The Message Originator can OPTIONALLY request a [XARF] report, as It is OPTIONAL for the Message Originator to request a [XARF] report,
described in Section 3.5.1. as described in Section 3.5.1.
3.5. Feedback Message 3.5. Feedback Message
The Feedback Message (sent by Mailbox Provider to the address The Feedback Message (sent by Mailbox Provider to the address
provided in the CFBL-Address header field) MUST have a valid [DKIM] provided in the CFBL-Address header field) MUST have a valid [DKIM]
signature. This signature MUST match the [RFC5322].From domain of signature. This signature MUST match the RFC5322.From domain of the
the Feedback Message. Feedback Message.
If the message does not have the required valid [DKIM] signature, the If the message does not have the required valid [DKIM] signature, the
Message Originator SHALL NOT process this Feedback Message. Message Originator SHALL NOT process this Feedback Message.
The Feedback Message MUST be a [ARF] or [XARF] report. If the The Feedback Message MUST be an [ARF] or [XARF] report. If the
Message Originator requests it (described in Section 3.5.1), and it Message Originator requests it (described in Section 3.5.1) and it is
is technically possible for the Mailbox Provider to do so, the technically possible for the Mailbox Provider to do so, the Feedback
Feedback Message MUST be a [XARF] report, otherwise the Feedback Message MUST be a [XARF] report. Otherwise, the Feedback Message
Message MUST be a [ARF] report. MUST be an [ARF] report.
The third MIME part of the [ARF] or the "Samples" section of the The third MIME part of the [ARF] or the "Samples" section of the
[XARF] report MUST contain the Message-ID [MAIL] of the received [XARF] report MUST contain the Message-ID [RFC5322] of the received
message. If present, the header field "CFBL-Feedback-ID" of the message. If present, the CFBL-Feedback-ID header field of the
received message MUST be added additionally to the third MIME part of received message MUST be added to the third MIME part of the [ARF] or
the [ARF] or to "Samples" section of the [XARF] report. to the "Samples" section of the [XARF] report.
The Mailbox Provider MAY omit or redact, as described in [RFC6590], The Mailbox Provider MAY omit or redact all further header fields
all further header fields and/or body to comply with any data- and/or body to comply with any data regulation laws as described in
regulation laws. [RFC6590].
3.5.1. XARF Report 3.5.1. XARF Report
A Message Originator wishing to receive a [XARF] report MUST append A Message Originator wishing to receive a [XARF] report MUST append
"report=xarf" to the CFBL-Address header field (Section 5.1). The "report=xarf" to the CFBL-Address header field (Section 5.1). The
report parameter is separated from the report address by a ";". report parameter is separated from the report address by a ";".
The resulting header field would look like the following: The resulting header field would appear as shown below.
CFBL-Address: fbl@example.com; report=xarf CFBL-Address: fbl@example.com; report=xarf
4. Implementation 4. Implementation
4.1. Message Originator 4.1. Message Originator
A Message Originator who wishes to use this new mechanism to receive A Message Originator who wishes to use this new mechanism to receive
Feedback Messages MUST include a CFBL-Address header field in their Feedback Messages MUST include a CFBL-Address header field in their
messages. messages.
skipping to change at page 10, line 15 skipping to change at line 437
It is RECOMMENDED that these Feedback Messages be processed It is RECOMMENDED that these Feedback Messages be processed
automatically. Each Message Originator must decide for themselves automatically. Each Message Originator must decide for themselves
what action to take after receiving a Feedback Message. what action to take after receiving a Feedback Message.
The Message Originator MUST take action to address the described The Message Originator MUST take action to address the described
requirements in Section 3. requirements in Section 3.
4.2. Mailbox Provider 4.2. Mailbox Provider
A Mailbox Provider who wants to collect user actions that indicate A Mailbox Provider who wants to collect user actions that indicate
the message was not wanted and send a Feedback Message to the Message the message was not wanted and to send a Feedback Message to the
Originator, they MAY query the CFBL-Address header field and forward Message Originator MAY query the CFBL-Address header field and
the report to the provided complaint feedback loop address. forward the report to the provided CFBL address.
The Mailbox Provider MUST validate the DKIM requirements of the The Mailbox Provider MUST validate the DKIM requirements of the
received Message described in Section 3.1 and MUST take action to received message described in Section 3.1 and MUST take action to
address the requirements described in Section 3.5 when sending address the requirements described in Section 3.5 when sending
Feedback Messages. Feedback Messages.
5. Header Field Syntax 5. Header Field Syntax
5.1. CFBL-Address 5.1. CFBL-Address
The following ABNF imports fields, CFWS, CRLF and addr-spec from The following ABNF imports the rules for fields, CFWS, CRLF, and
[MAIL]. Implementations of the CFBL-Address header field MUST comply addr-spec from [RFC5322]. Implementations of the CFBL-Address header
with [RFC6532]. field MUST comply with [RFC6532].
fields =/ cfbl-address fields =/ cfbl-address
cfbl-address = "CFBL-Address:" CFWS addr-spec cfbl-address = "CFBL-Address:" CFWS addr-spec
[";" CFWS report-format] CRLF [";" CFWS report-format] CRLF
report-format = %s"report=" (%s"arf" / %s"xarf") report-format = %s"report=" (%s"arf" / %s"xarf")
5.2. CFBL-Feedback-ID 5.2. CFBL-Feedback-ID
The following ABNF imports fields, WSP, CRLF and atext from [MAIL]. The following ABNF imports the rules for fields, WSP, CRLF, and atext
from [RFC5322].
fields =/ cfbl-feedback-id fields =/ cfbl-feedback-id
cfbl-feedback-id = "CFBL-Feedback-ID:" CFWS fid CRLF cfbl-feedback-id = "CFBL-Feedback-ID:" CFWS fid CRLF
fid = 1*(atext / ":" / CFWS) fid = 1*(atext / ":" / CFWS)
Whitespace is ignored in the fid value and MUST be ignored when
reassembling the original feedback id. Empty space is ignored in the fid value and MUST be ignored when
In particular, when adding the header field the Message Originator reassembling the original feedback-id.
can safely insert CFWS in the fid value in arbitrary places to In particular, the Message Originator can safely insert CFWS in the
conform to line-length limits. fid value in arbitrary places to conform to line length limits when
adding the header field.
6. Security Considerations 6. Security Considerations
This section discusses possible security issues, and their possible This section discusses possible security issues of a CFBL-Address
solutions, of a complaint feedback loop address header field. header field and their solutions.
6.1. Attacks on the Feedback Loop Address 6.1. Attacks on the Feedback Loop Address
Like any other email address, a complaint feedback loop address can Like any other email address, a CFBL address can be an attack vector
be an attack vector for malicious messages. For example, complaint for malicious messages. For example, CFBL addresses can be flooded
feedback loop addresses can be flooded with spam. This is an with spam. This is an existing problem with any existing email
existing problem with any existing email address and is not created address and is not created by this document.
by this document.
6.2. Automatic Suspension of an Account 6.2. Automatic Suspension of an Account
Receiving a Feedback Message regarding a Message Author can cause the Receiving a Feedback Message regarding a Message Author can cause the
Message Author to be unreachable if an automatic account suspension Message Author to be unreachable if an automatic account suspension
occurs too quickly. An example: someone sends an invitation to their occurs too quickly. For example, someone sends an invitation to
friends. For some reason, someone marks this message as spam. their friends, and someone else marks this message as spam for some
reason.
Now, if there is too fast automatic account suspension, the Message If automatic account suspension is too fast, the Message Author's
Author's account will be blocked and the Message Author will not be account will be blocked and the Message Author will not be able to
able to access their emails or is able to send further messages, access their emails or send further messages, depending on the
depending on the account suspension the Message Originator has account suspension the Message Originator has chosen.
chosen.
Message Originators must take appropriate measures to prevent too Message Originators must take appropriate measures to prevent account
fast account suspensions. Message Originators therefore have - suspensions that happen too fast. Therefore, Message Originators
mostly proprietary - ways to assess the trustworthiness of an have -- mostly proprietary -- ways to assess the trustworthiness of
account. For example, Message Originators may take into account the an account. For example, Message Originators may take into account
age of the account and/or any previous account suspension before the age of the account and/or any previous account suspension before
suspending an account. suspending an account.
6.3. Enumeration Attacks / Provoking Unsubscription 6.3. Enumeration Attacks / Provoking Unsubscription
A malicious person may send a series of spoofed ARF messages to known A malicious person may send a series of spoofed Abuse Reporting
complaint feedback loop addresses and attempt to guess a Message-ID/ Format (ARF) messages to known CFBL addresses and attempt to guess a
CFBL-Feedback-ID or any other identifiers. The malicious person may Message-ID / CFBL-Feedback-ID or any other identifiers. The
attempt to mass unsubscribe/suspend if such an automated system is in malicious person may attempt to mass unsubscribe/suspend if such an
place. This is also an existing problem with the current feedback automated system is in place. This is also an existing problem with
loop implementation and/or One-Click Unsubscription [RFC8058]. the current feedback loop implementation and/or One-Click
Unsubscription [RFC8058].
The Message Originator must take appropriate measures, a The Message Originator must take appropriate measures. For example,
countermeasure would be, that the CFBL-Feedback-ID header field, if the CFBL-Feedback-ID header field (if used) can use a hard-to-forge
used, use a hard-to-forge component such as a [HMAC] with a secret component, such as an [HMAC] with a secret key, instead of a
key instead of a plaintext string to make an enumeration attack plaintext string, to make an enumeration attack impossible.
impossible.
6.4. Data Privacy 6.4. Data Privacy
The provision of such a header field itself does not pose a data The provision of such a header field itself does not pose a data
privacy issue. The resulting ARF/XARF report sent by the Mailbox privacy issue. The resulting ARF/XARF report sent by the Mailbox
Provider to the Message Originator may violate a data privacy law Provider to the Message Originator may violate a data privacy law
because it may contain personal data. because it may contain personal data.
This document already addresses some parts of this problem and This document already addresses some parts of this problem and
describes a data privacy safe way to send a Feedback Message. As describes a way to send a Feedback Message that keeps data privacy
described in Section 3.5, the Mailbox Provider can omit the entire safe. As described in Section 3.5, the Mailbox Provider can omit the
body and/or header field and send only the required fields. As entire body and/or header field and send only the required fields.
recommended in [RFC6590], the Mailbox Provider can also redact the As recommended in [RFC6590], the Mailbox Provider can also redact the
data in question. Nevertheless, each Mailbox Provider must consider data in question. Nevertheless, each Mailbox Provider must consider
for itself whether this implementation is acceptable and complies for itself whether this implementation is acceptable and complies
with existing data privacy laws in their country. with existing data privacy laws in their country.
As described in Section 3.5 and in Section 3.3, it is also strongly As described in Sections 3.5 and 3.3, it is also strongly RECOMMENDED
RECOMMENDED that the Message-ID and, if used, the CFBL-Feedback-ID. that the Message-ID and CFBL-Feedback-ID (if used) contain a
contain a component that is difficult to forge, such as a [HMAC] that component that is difficult to forge, such as an [HMAC] that uses a
uses a secret key, rather than a plaintext string. See Section 8.3 secret key, rather than a plaintext string. See Section 8.3 for an
for an example. example.
6.5. Abusing for Validity and Existence Queries 6.5. Abusing for Validity and Existence Queries
This mechanism could be abused to determine the validity and This mechanism could be abused to determine the validity and
existence of an email address, which exhibits another potential data existence of an email address, exhibiting another potential data
privacy issue. Now, if the Mailbox Provider has an automatic process privacy issue. If the Mailbox Provider has an automatic process to
to generate a Feedback Message for a received message, it may not be generate a Feedback Message for a received message, it may not be
doing the mailbox owner any favors. As the Mailbox Provider now doing the mailbox owner any favors. As the Mailbox Provider
generates an automatic Feedback Message for the received message, the generates an automatic Feedback Message for the received message, the
Mailbox Provider now proves to the Message Originator that this Mailbox Provider proves to the Message Originator that this mailbox
mailbox exists for sure, because it is based on a manual action of exists for sure because it is based on a manual action of the mailbox
the mailbox owner. owner.
The receiving Mailbox Provider must take appropriate measures. One The receiving Mailbox Provider must take appropriate measures. One
possible countermeasure could be, for example, pre-existing possible countermeasure could be pre-existing reputation data
reputation data, usually proprietary data. Using this data, the (usually proprietary data), for example. Using this data, the
Mailbox Provider can assess the trustworthiness of a Message Mailbox Provider can assess the trustworthiness of a Message
Originator and decide whether to send a Feedback Message based on Originator and decide whether to send a Feedback Message based on
this information. this information.
7. IANA Considerations 7. IANA Considerations
7.1. CFBL-Address 7.1. CFBL-Address
The IANA is requested to register a new header field, per [RFC3864], IANA has registered a new header field, per [RFC3864], in the
into the "Provisional Message Header Field Names" registry: "Provisional Message Header Field Names" registry:
Header field name: CFBL-Address Header Field Name: CFBL-Address
Applicable protocol: mail Protocol: mail
Status: provisional Status:
Author/Change controller: Jan-Philipp Benecke <jpb@cleverreach.com> Author/Change controller: Jan-Philipp Benecke <jpb@cleverreach.com>
Specification document: this document Reference: RFC 9477
7.2. CFBL-Feedback-ID 7.2. CFBL-Feedback-ID
The IANA is requested to register a new header field, per [RFC3864], IANA has registered a new header field, per [RFC3864], in the
into the "Provisional Message Header Field Names" registry: "Provisional Message Header Field Names" registry:
Header field name: CFBL-Feedback-ID Header Field Name: CFBL-Feedback-ID
Applicable protocol: mail Protocol: mail
Status: provisional Status:
Author/Change controller: Jan-Philipp Benecke <jpb@cleverreach.com> Author/Change controller: Jan-Philipp Benecke <jpb@cleverreach.com>
Specification document: this document Reference: RFC 9477
8. Examples 8. Examples
For simplicity the DKIM header field has been shortened, and some For simplicity, the DKIM header field has been shortened, and some
tags have been omitted. tags have been omitted.
8.1. Simple 8.1. Simple
Email about the report will be generated: Email about the report will be generated:
Return-Path: <sender@mailer.example.com> Return-Path: <sender@mailer.example.com>
From: Awesome Newsletter <newsletter@example.com> From: Awesome Newsletter <newsletter@example.com>
To: me@example.net To: me@example.net
Subject: Super awesome deals for you Subject: Super awesome deals for you
skipping to change at page 15, line 22 skipping to change at line 669
Subject: Super awesome deals for you Subject: Super awesome deals for you
CFBL-Address: fbl@example.com; report=arf CFBL-Address: fbl@example.com; report=arf
CFBL-Feedback-ID: 111:222:333:4444 CFBL-Feedback-ID: 111:222:333:4444
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com> Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
Content-Type: text/plain; charset=utf-8 Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news; DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address; h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
This is a super awesome newsletter. This is a super awesome newsletter.
Resulting ARF report contains only the CFBL-Feedback-ID: Resulting ARF report that only contains the CFBL-Feedback-ID:
------=_Part_240060962_1083385345.1592993161900 ------=_Part_240060962_1083385345.1592993161900
Content-Type: message/feedback-report Content-Type: message/feedback-report
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
Feedback-Type: abuse Feedback-Type: abuse
User-Agent: FBL/0.1 User-Agent: FBL/0.1
Version: 0.1 Version: 0.1
Original-Mail-From: sender@mailer.example.com Original-Mail-From: sender@mailer.example.com
Arrival-Date: Tue, 23 Jun 2020 06:31:38 GMT Arrival-Date: Tue, 23 Jun 2020 06:31:38 GMT
skipping to change at page 16, line 19 skipping to change at line 708
CFBL-Address: fbl@example.com; report=arf CFBL-Address: fbl@example.com; report=arf
CFBL-Feedback-ID: 3789e1ae1938aa2f0dfdfa48b20d8f8bc6c21ac34fc5023d CFBL-Feedback-ID: 3789e1ae1938aa2f0dfdfa48b20d8f8bc6c21ac34fc5023d
63f9e64a43dfedc0 63f9e64a43dfedc0
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com> Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
Content-Type: text/plain; charset=utf-8 Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news; DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address; h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
This is a super awesome newsletter. This is a super awesome newsletter.
Resulting ARF report contains only the CFBL-Feedback-ID: Resulting ARF report that only contains the CFBL-Feedback-ID:
------=_Part_240060962_1083385345.1592993161900 ------=_Part_240060962_1083385345.1592993161900
Content-Type: message/feedback-report Content-Type: message/feedback-report
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
Feedback-Type: abuse Feedback-Type: abuse
User-Agent: FBL/0.1 User-Agent: FBL/0.1
Version: 0.1 Version: 0.1
Original-Mail-From: sender@mailer.example.com Original-Mail-From: sender@mailer.example.com
Arrival-Date: Tue, 23 Jun 2020 06:31:38 GMT Arrival-Date: Tue, 23 Jun 2020 06:31:38 GMT
skipping to change at page 16, line 41 skipping to change at line 730
Source-IP: 2001:DB8::25 Source-IP: 2001:DB8::25
------=_Part_240060962_1083385345.1592993161900 ------=_Part_240060962_1083385345.1592993161900
Content-Type: text/rfc822-headers; charset=UTF-8 Content-Type: text/rfc822-headers; charset=UTF-8
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
CFBL-Feedback-ID: 3789e1ae1938aa2f0dfdfa48b20d8f8bc6c21ac34fc5023d CFBL-Feedback-ID: 3789e1ae1938aa2f0dfdfa48b20d8f8bc6c21ac34fc5023d
63f9e64a43dfedc0 63f9e64a43dfedc0
------=_Part_240060962_1083385345.1592993161900-- ------=_Part_240060962_1083385345.1592993161900--
9. Acknowledgments 9. References
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. Normative References 9.1. Normative References
[ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An [ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An
Extensible Format for Email Feedback Reports", RFC 5965, Extensible Format for Email Feedback Reports", RFC 5965,
DOI 10.17487/RFC5965, August 2010, 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., [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76, "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011, RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/rfc/rfc6376>. <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/rfc/rfc5322>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, 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 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, 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, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008, 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 [RFC6449] Falk, J., Ed., "Complaint Feedback Loop Operational
Recommendations", RFC 6449, DOI 10.17487/RFC6449, November Recommendations", RFC 6449, DOI 10.17487/RFC6449, November
2011, <https://www.rfc-editor.org/rfc/rfc6449>. 2011, <https://www.rfc-editor.org/info/rfc6449>.
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
Email Headers", RFC 6532, DOI 10.17487/RFC6532, February Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
2012, <https://www.rfc-editor.org/rfc/rfc6532>. 2012, <https://www.rfc-editor.org/info/rfc6532>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014, 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 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[XARF] Abusix, "eXtended Abuse Reporting Format", [XARF] "XARF - eXtended Abuse Reporting Format", commit cc1a6e6,
Web https://github.com/abusix/xarf. March 2023, <https://github.com/abusix/xarf>.
10.2. Informative References 9.2. Informative References
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, 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 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
DOI 10.17487/RFC3864, September 2004, 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 [RFC6590] Falk, J., Ed. and M. Kucherawy, Ed., "Redaction of
Potentially Sensitive Data from Mail Abuse Reports", Potentially Sensitive Data from Mail Abuse Reports",
RFC 6590, DOI 10.17487/RFC6590, April 2012, 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 [RFC8058] Levine, J. and T. Herkula, "Signaling One-Click
Functionality for List Email Headers", RFC 8058, Functionality for List Email Headers", RFC 8058,
DOI 10.17487/RFC8058, January 2017, 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 Author's Address
Jan-Philipp Benecke Jan-Philipp Benecke
CleverReach GmbH & Co. KG CleverReach GmbH & Co. KG
Schafjueckenweg 2 Schafjueckenweg 2
26180 Rastede 26180 Rastede
Germany Germany
Phone: +49 4402 97390-16 Phone: +49 4402 97390-16
Email: jpb@cleverreach.com Email: jpb@cleverreach.com
 End of changes. 96 change blocks. 
279 lines changed or deleted 278 lines changed or added

This html diff was produced by rfcdiff 1.48.