diff options
Diffstat (limited to 'doc/rfc/rfc9477.txt')
| -rw-r--r-- | doc/rfc/rfc9477.txt | 818 |
1 files changed, 818 insertions, 0 deletions
diff --git a/doc/rfc/rfc9477.txt b/doc/rfc/rfc9477.txt new file mode 100644 index 0000000..e950255 --- /dev/null +++ b/doc/rfc/rfc9477.txt @@ -0,0 +1,818 @@ + + + + +Independent Submission J. Benecke +Request for Comments: 9477 CleverReach GmbH & Co. KG +Category: Experimental September 2023 +ISSN: 2070-1721 + + + Complaint Feedback Loop Address Header + +Abstract + + This document describes a method that allows a Message Originator to + specify a Complaint Feedback Loop (CFBL) address as a message header + field. 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 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 to gather feedback and gauge the interest of implementers + and deployers. This document is produced through the Independent RFC + Stream and was not subject to the IETF's approval process. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This is a contribution to the RFC Series, independently + of any other RFC stream. The RFC Editor has chosen to publish this + 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. + + 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 (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 + 1.1. Scope of this Experiment + 1.2. How CFBL Differs from One-Click-Unsubscribe + 2. Conventions Used in This Document + 3. Requirements + 3.1. Received Message + 3.1.1. Strict + 3.1.2. Relaxed + 3.1.3. Third Party Address + 3.1.4. DKIM Signature + 3.2. Multiple CFBL-Address Header Fields + 3.3. CFBL-Feedback-ID Header Field + 3.4. Receiving Report Address + 3.5. Feedback Message + 3.5.1. XARF Report + 4. Implementation + 4.1. Message Originator + 4.2. Mailbox Provider + 5. Header Field Syntax + 5.1. CFBL-Address + 5.2. CFBL-Feedback-ID + 6. Security Considerations + 6.1. Attacks on the Feedback Loop Address + 6.2. Automatic Suspension of an Account + 6.3. Enumeration Attacks / Provoking Unsubscription + 6.4. Data Privacy + 6.5. Abusing for Validity and Existence Queries + 7. IANA Considerations + 7.1. CFBL-Address + 7.2. CFBL-Feedback-ID + 8. Examples + 8.1. Simple + 8.2. Data Privacy Safe Report + 8.3. Data Privacy Safe Report with HMAC + 9. References + 9.1. Normative References + 9.2. Informative References + Acknowledgments + Author's Address + +1. Introduction and Motivation + + This memo extends the CFBL recommendations described in [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 + beginning with capital letters used in this memo are described in + that document. + + As described in [RFC6449], the registration for such a CFBL needs to + be done manually by a human at any Mailbox Provider that provides a + CFBL. The key underpinning of [RFC6449] is that access to the CFBL + is a privilege and 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 if there are new feedback loops rising up or if the Message + Originator wants to add new IP addresses, DomainKeys Identified Mail + (DKIM) domains, or change their complaint address. In addition, a + manual process is not well suited or feasible for smaller Mailbox + Providers. + + Here, we propose that Message Originators add a header field without + the need to manually register with each Feedback Provider and 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 data privacy laws, e.g., the EU's General Data Protection + Regulation (GDPR) or the California Consumer Privacy Act (CCPA). As + described in Section 6.4, a Feedback Message may contain personal + 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 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 these reports to the + CFBL address. These fake messages can result in a number of actions, + such as blocking 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. + + * 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 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 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/>, + 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 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 + 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. 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 from One-Click-Unsubscribe + + For good reasons, the One-Click-Unsubscribe [RFC8058] signaling + already exists and may have several interests in common with this + document. However, this header field requires the List-Unsubscribe + header 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 and not in normal email traffic. + +2. 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. + + In this document, "CFBL" is the abbreviation for "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, and a report that is to + be sent later. + +3.1.1. Strict + + If the domain in the RFC5322.From and the domain in the CFBL-Address + header fields are identical, this domain MUST be matched by a valid + [DKIM] signature. In this case, the DKIM "d=" parameter and the + 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 domain MUST be matched by a valid + [DKIM] signature. In this case, the DKIM "d=" parameter and the + RFC5322.From domain have 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 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 header field. 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 on who should receive the Feedback + Messages. Both 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; in this 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. + + 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 not matched by a valid DKIM signature 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 addresses, each + 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 for various reasons, 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 + protection component, such as an [HMAC] using a secret key, instead + of a plaintext string. + +3.4. Receiving Report Address + + The receiving report address provided in the CFBL-Address header + field MUST accept [ARF] reports. + + It is OPTIONAL for the Message Originator 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 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 an [ARF] or [XARF] report. If the + Message Originator requests it (described in Section 3.5.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 an [ARF] report. + + The third MIME part of the [ARF] or the "Samples" section of the + [XARF] report MUST contain the Message-ID [RFC5322] of the received + message. If present, the CFBL-Feedback-ID header field of the + received message MUST be added to the third MIME part of the [ARF] or + to the "Samples" section of the [XARF] report. + + The Mailbox Provider MAY omit or redact all further header fields + and/or body to comply with any data regulation 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 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 MAY query the CFBL-Address header field and + forward the report to the provided CFBL address. + + The Mailbox Provider MUST validate the DKIM requirements of the + received 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, and + addr-spec from [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, and atext + from [RFC5322]. + + fields =/ cfbl-feedback-id + + cfbl-feedback-id = "CFBL-Feedback-ID:" CFWS fid CRLF + + fid = 1*(atext / ":" / CFWS) + + Empty space is ignored in the fid value and MUST be ignored when + reassembling the original feedback-id. + In particular, the Message Originator can safely insert CFWS in the + fid value in arbitrary places to conform to line length limits when + adding the header field. + +6. Security Considerations + + This section discusses possible security issues of a CFBL-Address + header field and their solutions. + +6.1. Attacks on the Feedback Loop Address + + Like any other email address, a CFBL address can be an attack vector + for malicious messages. For example, 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. For example, someone sends an invitation to + their friends, and someone else marks this message as spam for some + reason. + + If automatic account 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 send further messages, depending on the + account suspension the Message Originator has chosen. + + Message Originators must take appropriate measures to prevent account + suspensions that happen too fast. Therefore, Message Originators + 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 Abuse Reporting + Format (ARF) messages to known CFBL 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. For example, + the CFBL-Feedback-ID header field (if used) can use a hard-to-forge + component, such as an [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 way to send a Feedback 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 Sections 3.5 and 3.3, it is also strongly RECOMMENDED + that the Message-ID and CFBL-Feedback-ID (if used) contain a + component that is difficult to forge, such as 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, exhibiting another potential data + privacy issue. 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 + generates an automatic Feedback Message for the received message, the + Mailbox Provider proves to the Message Originator that this mailbox + exists for 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 pre-existing reputation data + (usually proprietary 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 + + IANA has registered a new header field, per [RFC3864], in the + "Provisional Message Header Field Names" registry: + + Header Field Name: CFBL-Address + + Protocol: mail + + Status: + + Author/Change controller: Jan-Philipp Benecke <jpb@cleverreach.com> + + Reference: RFC 9477 + +7.2. CFBL-Feedback-ID + + IANA has registered a new header field, per [RFC3864], in the + "Provisional Message Header Field Names" registry: + + Header Field Name: CFBL-Feedback-ID + + Protocol: mail + + Status: + + Author/Change controller: Jan-Philipp Benecke <jpb@cleverreach.com> + + Reference: RFC 9477 + +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: <sender@mailer.example.com> + From: Awesome Newsletter <newsletter@example.com> + To: me@example.net + Subject: Super awesome deals for you + CFBL-Address: fbl@example.com; report=arf + CFBL-Feedback-ID: 111:222:333:4444 + Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com> + Content-Type: text/plain; charset=utf-8 + DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news; + h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address; + + This is a super awesome newsletter. + + Resulting ARF report: + + ------=_Part_240060962_1083385345.1592993161900 + Content-Type: message/feedback-report + Content-Transfer-Encoding: 7bit + + Feedback-Type: abuse + User-Agent: FBL/0.1 + Version: 0.1 + Original-Mail-From: sender@mailer.example.com + Arrival-Date: Tue, 23 Jun 2020 06:31:38 GMT + Reported-Domain: example.com + Source-IP: 192.0.2.1 + + ------=_Part_240060962_1083385345.1592993161900 + Content-Type: text/rfc822; charset=UTF-8 + Content-Transfer-Encoding: 7bit + + Return-Path: <sender@mailer.example.com> + From: Awesome Newsletter <newsletter@example.com> + To: me@example.net + Subject: Super awesome deals for you + CFBL-Address: fbl@example.com; report=arf + CFBL-Feedback-ID: 111:222:333:4444 + Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com> + Content-Type: text/plain; charset=utf-8 + DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news; + h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address; + + This is a super awesome newsletter. + ------=_Part_240060962_1083385345.1592993161900-- + +8.2. Data Privacy Safe Report + + Email about the report will be generated: + + Return-Path: <sender@mailer.example.com> + From: Awesome Newsletter <newsletter@example.com> + To: me@example.net + Subject: Super awesome deals for you + CFBL-Address: fbl@example.com; report=arf + CFBL-Feedback-ID: 111:222:333:4444 + Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com> + Content-Type: text/plain; charset=utf-8 + DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news; + h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address; + + This is a super awesome newsletter. + + Resulting ARF report 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 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. References + +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/info/rfc5965>. + + [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., + "DomainKeys Identified Mail (DKIM) Signatures", STD 76, + RFC 6376, DOI 10.17487/RFC6376, September 2011, + <https://www.rfc-editor.org/info/rfc6376>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [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/info/rfc5234>. + + [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, + DOI 10.17487/RFC5322, October 2008, + <https://www.rfc-editor.org/info/rfc5322>. + + [RFC6449] Falk, J., Ed., "Complaint Feedback Loop Operational + Recommendations", RFC 6449, DOI 10.17487/RFC6449, November + 2011, <https://www.rfc-editor.org/info/rfc6449>. + + [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized + Email Headers", RFC 6532, DOI 10.17487/RFC6532, February + 2012, <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/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/info/rfc8174>. + + [XARF] "XARF - eXtended Abuse Reporting Format", 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/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/info/rfc3864>. + + [RFC6590] Falk, J., Ed. and M. Kucherawy, Ed., "Redaction of + Potentially Sensitive Data from Mail Abuse Reports", + RFC 6590, DOI 10.17487/RFC6590, April 2012, + <https://www.rfc-editor.org/info/rfc6590>. + + [RFC8058] Levine, J. and T. Herkula, "Signaling One-Click + Functionality for List Email Headers", RFC 8058, + DOI 10.17487/RFC8058, January 2017, + <https://www.rfc-editor.org/info/rfc8058>. + +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 |