Network Working Group J. Benecke Internet-Draft CleverReach GmbH & Co. KG Intended status: Experimental 20 February 2023 Expires: 24 August 2023 Complaint Feedback Loop Address Header draft-benecke-cfbl-address-header-09 Abstract This document describes a method that allows a Message Originator to specify a complaint feedback loop (FBL) address as a message header field. Also, it defines the rules for processing and forwarding such a complaint. The motivation for this arises out of the absence of a standardized and automated way to provide Mailbox Providers with an address for a complaint feedback loop. Currently, providing and maintaining such an address is a manual and time-consuming process for Message Originators and Mailbox Providers. It is unclear, at the time of publication, whether the function provided by this document has widespread demand, and whether the mechanism offered will be adopted and found to be useful. Therefore, this is being published as an Experiment, looking for a constituency of implementers and deployers, and for feedback on the operational utility. The document is produced through the Independent RFC stream and was not subject to the IETF's approval process. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 24 August 2023. Benecke Expires 24 August 2023 [Page 1] Internet-Draft CFBL Address Header February 2023 Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 1.1. Scope of this Experiment . . . . . . . . . . . . . . . . 4 1.2. Difference to One-Click-Unsubscribe . . . . . . . . . . . 5 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Received Message . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Strict . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.2. Relaxed . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.3. Third Party Address . . . . . . . . . . . . . . . . . 7 3.1.4. DKIM Signature . . . . . . . . . . . . . . . . . . . 9 3.2. CFBL-Feedback-ID Header Field . . . . . . . . . . . . . . 9 3.3. Receiving Report Address . . . . . . . . . . . . . . . . 9 3.4. Feedback Message . . . . . . . . . . . . . . . . . . . . 9 3.4.1. XARF Report . . . . . . . . . . . . . . . . . . . . . 10 4. Implementation . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Message Originator . . . . . . . . . . . . . . . . . . . 10 4.2. Mailbox Provider . . . . . . . . . . . . . . . . . . . . 10 5. Header Field Syntax . . . . . . . . . . . . . . . . . . . . . 10 5.1. CFBL-Address . . . . . . . . . . . . . . . . . . . . . . 10 5.2. CFBL-Feedback-ID . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . 12 6.4. Data Privacy . . . . . . . . . . . . . . . . . . . . . . 12 6.5. Abusing for Validity and Existence Queries . . . . . . . 12 6.6. Over-Signing when Accepting Pre-Signed Emails . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7.1. CFBL-Address . . . . . . . . . . . . . . . . . . . . . . 13 7.2. CFBL-Feedback-ID . . . . . . . . . . . . . . . . . . . . 13 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Simple . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.2. Data Privacy Safe Report . . . . . . . . . . . . . . . . 15 8.3. Data Privacy Safe Report with HMAC . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 Benecke Expires 24 August 2023 [Page 2] Internet-Draft CFBL Address Header February 2023 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction and Motivation The topic and goal of this document is to extend the complaint feedback loop recommendations described in [RFC6449] with an automated way to provide the necessary information to Mailbox Providers, to report message handling actions taken by message recipients, such as "mark as spam", back to the Message Originator. As described in [RFC6449] the registration for such a complaint feedback loop needs to be done manually by a human at any Mailbox Provider who provides a complaint feedback loop. The key underpinning of [RFC6449] is that access to the complaint feedback loop is a privilege, and the Mailbox Providers are not prepared to send feedback to anyone it cannot reasonably believe are legitimate. However, a manual registration and management can be quite time- consuming if there are new feedback loops rising up, or the Message Originator wants to add new IP addresses or DKIM domains. In addition, a manual process is not well suited and/or feasible for smaller Mailbox Providers. Because of the manual process involved, the Message Originator has to go through all providers again, delete his existing subscriptions and register with their new complaint address. Message Originators can add a header field, willing Mailbox Providers can use it to send the Feedback Messages to the specified complaint address. The Message Originator only needs to add a message header field and does not need to manually register with each Feedback Provider. The 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 on the Mailbox Provider side to obtain the complaint address. The proposed mechanism is capable of being operated in compliance with the data privacy laws. Benecke Expires 24 August 2023 [Page 3] Internet-Draft CFBL Address Header February 2023 Nevertheless, the described mechanism below potentially permits a kind of man-in-the-middle attack between the domain owner and the recipient. A bad actor can generate forged reports to be "from" a domain name the bad actor is attacking and send this reports to the complaint feedback loop 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 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. 1.1. Scope of this Experiment The CFBL-Address header field and the CFBL-Feedback-ID header field are an experiment. Participation in this experiment consists of adding the CFBL-Address header field on Message Originators side or by using the CFBL-Address header field to send Feedback Messages to the provided address on Mailbox Provider side. Feedback on the results of this experiment can be emailed to the author, raised as an issue at https://github.com/jpbede/rfc-cfbl-address-header/ or can be emailed to the IETF cfbl mailing list (cfbl@ietf.org). The goal of this experiment is to answer the following questions based on real-world deployments: * Is there interest among Message Originator 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 introduce additional security issues? Benecke Expires 24 August 2023 [Page 4] Internet-Draft CFBL Address Header February 2023 * 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 in a country and by at least two Message Originators within the next two years and 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, it may be taken to the IETF for further discussion and revision. One possible outcome could be that a working group creates a specification for the standards track. 1.2. Difference to One-Click-Unsubscribe For good reasons, the One-Click-Unsubscribe [RFC8058] signaling already exists, which may have several interests in common with this document. However, this header field requires the List-Unsubscribe header field, whose purpose 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, not in normal email traffic. The main interest of this document now is to provide an automated way to signal Mailbox Providers an address for a complaint feedback loop. It is the obligation of the Message Originator to decide for themselves what action to take after receiving a notification; this is not the subject of this document. Nevertheless, there is discussion about possible actions and their possible harm in Section 6. 2. Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The key word "CFBL" in this document is the abbreviation for "complaint feedback loop" and will hereafter be used. Unless otherwise noted, the terminology used in this document is taken from [RFC6449]. Benecke Expires 24 August 2023 [Page 5] Internet-Draft CFBL Address Header February 2023 3. Requirements 3.1. Received Message This section describes the requirements that a received message, the message that is sent from the Message Originator to the Mailbox Provider and about which a report is to be sent later, must meet. 3.1.1. Strict If the domain in the [RFC5322].From and the domain in the CFBL- Address header field are identical, this domain MUST be covered by a valid [DKIM] signature. In this case, the DKIM "d=" parameter and the [RFC5322].From field have identical DNS domains. This signature MUST meet the requirements described in Section 3.1.4. The following example meets this case: Return-Path: From: Awesome Newsletter To: receiver@example.org Subject: Super awesome deals for you CFBL-Address: fbl@example.com; report=arf Message-ID: 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 is a child domain of the [RFC5322].From, the [RFC5322].From domain MUST be covered by a valid [DKIM] signature. In this case, the DKIM "d=" parameter and the [RFC5322].From domain have a identical (Example 1) or parent (Example 2) DNS domains. This signature MUST meet the requirements described in Section 3.1.4. Example 1: Benecke Expires 24 August 2023 [Page 6] Internet-Draft CFBL Address Header February 2023 Return-Path: From: Awesome Newsletter To: receiver@example.org Subject: Super awesome deals for you CFBL-Address: fbl@mailer.example.com; report=arf Message-ID: 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: From: Awesome Newsletter To: receiver@example.org Subject: Super awesome deals for you CFBL-Address: fbl@mailer.example.com; report=arf Message-ID: Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; d=example.com; h=Content-Type:Subject:From:To:Message-ID: CFBL-Feedback-ID:CFBL-Address; This is a super awesome newsletter. 3.1.3. Third Party Address If the domain in [RFC5322].From differs from the domain in the CFBL- Address header field, the domain of the CFBL-Address header field MUST be covered by an additional valid [DKIM] signature. Both signatures MUST meet the requirements described in Section 3.1.4. This double DKIM signature ensures that both, the domain owner of the [RFC5322].From domain and the domain owner of the CFBL-Address domain, agree who should receive the Feedback Messages. The following example meets this case: Benecke Expires 24 August 2023 [Page 7] Internet-Draft CFBL Address Header February 2023 Return-Path: From: Awesome Newsletter To: receiver@example.org Subject: Super awesome deals for you CFBL-Address: fbl@super-saas-mailer.com; report=arf Message-ID: Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; d=super-saas-mailer.com; s=system; h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address; DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news; h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address; This is a super awesome newsletter. 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, in which case the double signature MUST BE omitted and the Email Service Provider MUST sign with its domain. Therefore, the pre-signed message MUST NOT include "CFBL-Address" and "CFBL-Feedback-ID" in its h= tag. This way the Email Service Provider has the possibility to accept the pre-signed messages and can inject their own CFBL-Address. Due to this granted exception a malicious actor can destroy this possibility with over-signing. This potential harm is described in Section 6. The following example meets this case: Return-Path: From: Awesome Newsletter To: receiver@example.org Subject: Super awesome deals for you CFBL-Address: fbl@super-saas-mailer.com; report=arf Message-ID: Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news; h=Subject:From:To:Message-ID; DKIM-Signature: v=1; a=rsa-sha256; d=super-saas-mailer.com; s=system; h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address; This is a super awesome newsletter. Benecke Expires 24 August 2023 [Page 8] Internet-Draft CFBL Address Header February 2023 3.1.4. DKIM Signature The CFBL-Address header field MUST be included in the "h=" tag of the aforementioned valid DKIM-Signature. When the CFBL-Feedback-ID header field is present, it MUST also be included in the "h=" tag of the aforementioned valid DKIM signature. If the domain has neither the required coverage by a valid DKIM signature nor the required header field coverage by the "h=" tag, the Mailbox Provider SHALL NOT send a report message. 3.2. CFBL-Feedback-ID Header Field The Message Originator MAY include a CFBL-Feedback-ID header field in its messages out of various reasons, e.g. their feedback loop processing system can't do anything with the Message-ID header field. It is highly RECOMMENDED that the header field includes a hard to forge component such as an [HMAC] using a secret key, instead of a plain-text string. 3.3. Receiving Report Address The receiving report address provided in the CFBL-Address header field MUST accept [ARF] reports. The Message Originator can OPTIONALLY request a [XARF] report, as described in Section 3.4.1. 3.4. 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. 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 [ARF] or [XARF] report. If the Message Originator requests it (described in Section 3.4.1), and it is technically possible for the Mailbox Provider to do so, the Feedback Message MUST be a [XARF] report, otherwise the Feedback Message MUST be a [ARF] report. The [ARF] or [XARF] report MUST contain the Message-ID [MAIL]. If present, the header field "CFBL-Feedback-ID" of the received message MUST be added additionally to the [ARF] or [XARF] report. Benecke Expires 24 August 2023 [Page 9] Internet-Draft CFBL Address Header February 2023 The Mailbox Provider MAY omit or redact, as described in [RFC6590], all further header fields and/or body to comply with any data- regulation laws. 3.4.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: 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 strongly 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 send a Feedback Message to the Message Originator, they MAY query the CFBL-Address header field and forward the report to the provided complaint feedback loop address. The Mailbox Provider MUST validate and take action to address the described requirements in Section 3. 5. Header Field Syntax 5.1. CFBL-Address The following ABNF imports fields, WSP, CRLF and addr-spec from [MAIL]. Benecke Expires 24 August 2023 [Page 10] Internet-Draft CFBL Address Header February 2023 fields =/ cfbl-address cfbl-address = "CFBL-Address:" 0*1WSP addr-spec [";" 0*1WSP report-format] CRLF report-format = "report=" ("arf" / "xarf") 5.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 / ":") 6. Security Considerations This section discusses possible security issues, and their possible solutions, of a complaint feedback loop address header field. 6.1. Attacks on the Feedback Loop Address Like any other email address, a complaint feedback loop address can be an attack vector for malicious messages. For example, complaint feedback loop 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: someone sends an invitation to their friends. For some reason, someone marks this message as spam. Now, if there is too fast automatic account suspension, 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. 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. Benecke Expires 24 August 2023 [Page 11] Internet-Draft CFBL Address Header February 2023 6.3. Enumeration Attacks / Provoking Unsubscription A malicious person may send a series of spoofed ARF messages to known complaint feedback loop addresses and attempt to guess a Message-ID/ CFBL-Feedback-ID or any other identifiers. The malicious person may attempt to mass unsubscribe/suspend if such an automated system is in place. This is also an existing problem with the current feedback loop implementation and/or One-Click Unsubscription [RFC8058]. The Message Originator must take appropriate measures, a countermeasure would be, that the CFBL-Feedback-ID header field, if used, use a hard-to-forge component such as a [HMAC] with a secret key instead of a plaintext string to make an enumeration attack impossible. 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. As described in Section 3.4, 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 3.4 and in Section 3.2, it is also strongly RECOMMENDED that the Message-ID and, if used, the CFBL-Feedback-ID. contain a component that is difficult to forge, such as a [HMAC] that uses a secret key, rather than a plaintext string. See Section 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 another potential data privacy issue. Now, 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, because it is based on a manual action of the mailbox owner. Benecke Expires 24 August 2023 [Page 12] Internet-Draft CFBL Address Header February 2023 The receiving Mailbox Provider must take appropriate measures. One possible countermeasure could be, for example, pre-existing reputation data, usually proprietary data. 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. 6.6. Over-Signing when Accepting Pre-Signed Emails When accepting pre-signed mails, a malicious actor can destroy the possibility of adding the CFBL-Address header field by the Email Service Provider, with "over-signing". The methode "over-signing" is described in Section 5.4 of [DKIM]. The Email Service Provider must take appropriate measures. Email Service Providers therefore have - mostly proprietary - methods for assessing the trustworthiness of an account and decide on this basis whether to accept pre-signed messages. 7. IANA Considerations 7.1. CFBL-Address The IANA is requested to register a new header field, per [RFC3864], into the "Provisional Message Header Field Names" registry: Header field name: CFBL-Address Applicable protocol: mail Status: provisional Author/Change controller: Jan-Philipp Benecke Specification document: this document 7.2. CFBL-Feedback-ID The IANA is requested to register a new header field, per [RFC3864], into the "Provisional Message Header Field Names" registry: Benecke Expires 24 August 2023 [Page 13] Internet-Draft CFBL Address Header February 2023 Header field name: CFBL-Feedback-ID Applicable protocol: mail Status: provisional Author/Change controller: Jan-Philipp Benecke Specification document: this document 8. Examples For 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: From: Awesome Newsletter 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: 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: Benecke Expires 24 August 2023 [Page 14] Internet-Draft CFBL Address Header February 2023 ------=_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: From: Awesome Newsletter 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: Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news; h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address; This is a super awesome newsletter. ------=_Part_240060962_1083385345.1592993161900-- 8.2. Data Privacy Safe Report Email about the report will be generated: Return-Path: From: Awesome Newsletter 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: Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news; h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address; This is a super awesome newsletter. Resulting ARF report contains only the CFBL-Feedback-ID: Benecke Expires 24 August 2023 [Page 15] Internet-Draft CFBL Address Header February 2023 ------=_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: From: Awesome Newsletter To: me@example.net Subject: Super awesome deals for you CFBL-Address: fbl@example.com; report=arf CFBL-Feedback-ID: 3789e1ae1938aa2f0dfdfa48b20d8f8bc6c21ac34fc5023d 63f9e64a43dfedc0 Message-ID: Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news; h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address; This is a super awesome newsletter. Resulting ARF report contains only the CFBL-Feedback-ID: Benecke Expires 24 August 2023 [Page 16] Internet-Draft CFBL Address Header February 2023 ------=_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, Levent Ulucan (Inxmail), Arne Allisat and Tobias Herkula (1&1 Mail & Media) and Sven Krohlas (BFK Edv-consulting). 10. References 10.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, . [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, . [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . Benecke Expires 24 August 2023 [Page 17] Internet-Draft CFBL Address Header February 2023 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [RFC6449] Falk, J., Ed., "Complaint Feedback Loop Operational Recommendations", RFC 6449, DOI 10.17487/RFC6449, November 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [XARF] Abusix, "eXtended Abuse Reporting Format", Web https://github.com/abusix/xarf. 10.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, . [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, . [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, . [RFC8058] Levine, J. and T. Herkula, "Signaling One-Click Functionality for List Email Headers", RFC 8058, DOI 10.17487/RFC8058, January 2017, . Author's Address Benecke Expires 24 August 2023 [Page 18] Internet-Draft CFBL Address Header February 2023 Jan-Philipp Benecke CleverReach GmbH & Co. KG Schafjueckenweg 2 26180 Rastede Germany Phone: +49 4402 97390-16 Email: jpb@cleverreach.com Benecke Expires 24 August 2023 [Page 19]