5Independent Submission J. Benecke
6Request for Comments: 9477 CleverReach GmbH & Co. KG
7Category: Experimental September 2023
11 Complaint Feedback Loop Address Header
15 This document describes a method that allows a Message Originator to
16 specify a Complaint Feedback Loop (CFBL) address as a message header
17 field. It also defines the rules for processing and forwarding such
18 a complaint. The motivation for this arises out of the absence of a
19 standardized and automated way to provide Mailbox Providers with an
20 address for a CFBL. Currently, providing and maintaining such an
21 address is a manual and time-consuming process for Message
22 Originators and Mailbox Providers.
24 The mechanism specified in this document is being published as an
25 experiment to gather feedback and gauge the interest of implementers
26 and deployers. This document is produced through the Independent RFC
27 Stream and was not subject to the IETF's approval process.
31 This document is not an Internet Standards Track specification; it is
32 published for examination, experimental implementation, and
35 This document defines an Experimental Protocol for the Internet
36 community. This is a contribution to the RFC Series, independently
37 of any other RFC stream. The RFC Editor has chosen to publish this
38 document at its discretion and makes no statement about its value for
39 implementation or deployment. Documents approved for publication by
40 the RFC Editor are not candidates for any level of Internet Standard;
41 see Section 2 of RFC 7841.
43 Information about the current status of this document, any errata,
44 and how to provide feedback on it may be obtained at
45 https://www.rfc-editor.org/info/rfc9477.
49 Copyright (c) 2023 IETF Trust and the persons identified as the
50 document authors. All rights reserved.
52 This document is subject to BCP 78 and the IETF Trust's Legal
53 Provisions Relating to IETF Documents
54 (https://trustee.ietf.org/license-info) in effect on the date of
55 publication of this document. Please review these documents
56 carefully, as they describe your rights and restrictions with respect
61 1. Introduction and Motivation
62 1.1. Scope of this Experiment
63 1.2. How CFBL Differs from One-Click-Unsubscribe
64 2. Conventions Used in This Document
69 3.1.3. Third Party Address
71 3.2. Multiple CFBL-Address Header Fields
72 3.3. CFBL-Feedback-ID Header Field
73 3.4. Receiving Report Address
77 4.1. Message Originator
79 5. Header Field Syntax
82 6. Security Considerations
83 6.1. Attacks on the Feedback Loop Address
84 6.2. Automatic Suspension of an Account
85 6.3. Enumeration Attacks / Provoking Unsubscription
87 6.5. Abusing for Validity and Existence Queries
88 7. IANA Considerations
93 8.2. Data Privacy Safe Report
94 8.3. Data Privacy Safe Report with HMAC
96 9.1. Normative References
97 9.2. Informative References
1011. Introduction and Motivation
103 This memo extends the CFBL recommendations described in [RFC6449]
104 with an automated way to provide the necessary information by the
105 Message Originator to Mailbox Providers. The reader should be
106 familiar with the terminology and concepts in that document. Terms
107 beginning with capital letters used in this memo are described in
110 As described in [RFC6449], the registration for such a CFBL needs to
111 be done manually by a human at any Mailbox Provider that provides a
112 CFBL. The key underpinning of [RFC6449] is that access to the CFBL
113 is a privilege and Mailbox Providers are not prepared to send
114 feedback to anyone they cannot reasonably believe are legitimate.
115 However, manual registration and management can be quite time-
116 consuming if there are new feedback loops rising up or if the Message
117 Originator wants to add new IP addresses, DomainKeys Identified Mail
118 (DKIM) domains, or change their complaint address. In addition, a
119 manual process is not well suited or feasible for smaller Mailbox
122 Here, we propose that Message Originators add a header field without
123 the need to manually register with each Feedback Provider and willing
124 Mailbox Providers can use it to send the Feedback Messages to the
125 specified complaint address. This simplification or extension of a
126 manual registration and verification process would be another
127 advantage for the Mailbox Providers.
129 A new message header field, rather than a new DNS record, was chosen
130 to easily distinguish between multiple Message Originators without
131 requiring user or administrator intervention. For example, if a
132 company uses multiple systems, each system can set this header field
133 on its own without requiring users or administrators to make any
134 changes to their DNS. No additional DNS lookup is required of the
135 Mailbox Provider side to obtain the complaint address.
137 The proposed mechanism is capable of being operated in compliance
138 with data privacy laws, e.g., the EU's General Data Protection
139 Regulation (GDPR) or the California Consumer Privacy Act (CCPA). As
140 described in Section 6.4, a Feedback Message may contain personal
141 data. This document describes a way to omit this personal data when
142 sending the Feedback Message and only send back a header field.
144 Nevertheless, the described mechanism below potentially permits a
145 kind of person-in-the-middle attack between the domain owner and the
146 recipient. A bad actor can generate forged reports to be "from" a
147 domain name the bad actor is attacking and send these reports to the
148 CFBL address. These fake messages can result in a number of actions,
149 such as blocking accounts or deactivating recipient addresses. This
150 potential harm and others are described with potential
151 countermeasures in Section 6.
153 In summary, this document has the following objectives:
155 * Allow Message Originators to signal that a complaint address
156 exists without requiring manual registration with all providers.
158 * Allow Mailbox Providers to obtain a complaint address without
159 developing their own manual registration process.
161 * Have the ability to provide a complaint address to smaller Mailbox
162 Providers who do not have a feedback loop in place
164 * Provide a data privacy safe option for a CFBL.
1661.1. Scope of this Experiment
168 The CFBL-Address header field and the CFBL-Feedback-ID header field
169 comprise an experiment. Participation in this experiment consists of
170 adding the CFBL-Address header field on the Message Originator side
171 or by using the CFBL-Address header field to send Feedback Messages
172 to the provided address on the Mailbox Provider side. Feedback on
173 the results of this experiment can be emailed to the author, raised
174 as an issue at <https://github.com/jpbede/rfc-cfbl-address-header/>,
175 or can be emailed to the IETF cfbl mailing list (cfbl@ietf.org).
177 The goal of this experiment is to answer the following questions
178 based on real-world deployments:
180 * Is there interest among Message Originators and Mailbox Providers?
182 * If the Mailbox Provider adds this capability, will it be used by
183 the Message Originators?
185 * If the Message Originator adds this capability, will it be used by
186 the Mailbox Providers?
188 * Does the presence of the CFBL-Address and CFBL-Feedback-ID header
189 fields introduce additional security issues?
191 * What additional security measures/checks need to be performed at
192 the Mailbox Provider before a Feedback Message is sent?
194 * What additional security measures/checks need to be performed at
195 the Message Originator after a Feedback Message is received?
197 This experiment will be considered successful if the CFBL-Address
198 header field is used by a leading Mailbox Provider and by at least
199 two Message Originators within the next two years. It will also be
200 considered a success if these parties successfully use the address
201 specified in the header field to exchange Feedback Messages.
203 If this experiment is successful and these header fields prove to be
204 valuable and popular, the header fields may be taken to the IETF for
205 further discussion and revision.
2071.2. How CFBL Differs from One-Click-Unsubscribe
209 For good reasons, the One-Click-Unsubscribe [RFC8058] signaling
210 already exists and may have several interests in common with this
211 document. However, this header field requires the List-Unsubscribe
212 header field. The purpose of this header field is to provide the
213 link to unsubscribe from a list. For this reason, this header field
214 is only used by operators of broadcast marketing lists or mailing
215 lists and not in normal email traffic.
2172. Conventions Used in This Document
219 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
220 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
221 "OPTIONAL" in this document are to be interpreted as described in
222 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
223 capitals, as shown here.
225 In this document, "CFBL" is the abbreviation for "Complaint Feedback
226 Loop" and will hereafter be used.
228 Syntax descriptions use ABNF [RFC5234] [RFC7405].
234 This section describes the requirements that must be met for the
235 following: a received message, the message that is sent from the
236 Message Originator to the Mailbox Provider, and a report that is to
241 If the domain in the RFC5322.From and the domain in the CFBL-Address
242 header fields are identical, this domain MUST be matched by a valid
243 [DKIM] signature. In this case, the DKIM "d=" parameter and the
244 RFC5322.From field have identical domains. This signature MUST meet
245 the requirements described in Section 3.1.4.
247 The following example meets this case:
249 Return-Path: <sender@mailer.example.com>
250 From: Awesome Newsletter <newsletter@example.com>
251 To: receiver@example.org
252 Subject: Super awesome deals for you
253 CFBL-Address: fbl@example.com; report=arf
254 Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
255 Content-Type: text/plain; charset=utf-8
256 DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
257 h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
259 This is a super awesome newsletter.
263 If the domain in CFBL-Address header field is a child domain of
264 RFC5322.From, the RFC5322.From domain MUST be matched by a valid
265 [DKIM] signature. In this case, the DKIM "d=" parameter and the
266 RFC5322.From domain have an identical (Example 1) or parent (Example
267 2) domain. This signature MUST meet the requirements described in
272 Return-Path: <sender@mailer.example.com>
273 From: Awesome Newsletter <newsletter@mailer.example.com>
274 To: receiver@example.org
275 Subject: Super awesome deals for you
276 CFBL-Address: fbl@mailer.example.com; report=arf
277 Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
278 Content-Type: text/plain; charset=utf-8
279 DKIM-Signature: v=1; a=rsa-sha256; d=example.com;
280 h=Content-Type:Subject:From:To:Message-ID:
281 CFBL-Feedback-ID:CFBL-Address;
283 This is a super awesome newsletter.
287 Return-Path: <sender@mailer.example.com>
288 From: Awesome Newsletter <newsletter@example.com>
289 To: receiver@example.org
290 Subject: Super awesome deals for you
291 CFBL-Address: fbl@mailer.example.com; report=arf
292 Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
293 Content-Type: text/plain; charset=utf-8
294 DKIM-Signature: v=1; a=rsa-sha256; d=example.com;
295 h=Content-Type:Subject:From:To:Message-ID:
296 CFBL-Feedback-ID:CFBL-Address;
298 This is a super awesome newsletter.
3003.1.3. Third Party Address
302 If the domain in RFC5322.From differs from the domain in the CFBL-
303 Address header field, an additional valid [DKIM] signature MUST be
304 added that matches the domain in the CFBL-Address header field. The
305 other existing valid [DKIM] signature MUST match the domain in the
306 RFC5322.From header field. This double DKIM signature ensures that
307 both the domain owner of the RFC5322.From domain and the domain owner
308 of the CFBL-Address domain agree on who should receive the Feedback
309 Messages. Both signatures MUST meet the requirements described in
312 The following example meets this case:
314 Return-Path: <sender@saas-mailer.example>
315 From: Awesome Newsletter <newsletter@example.com>
316 To: receiver@example.org
317 Subject: Super awesome deals for you
318 CFBL-Address: fbl@saas-mailer.example; report=arf
319 Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@example.com>
320 Content-Type: text/plain; charset=utf-8
321 DKIM-Signature: v=1; a=rsa-sha256; d=saas-mailer.example; s=system;
322 h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
323 DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
324 h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
326 This is a super awesome newsletter.
328 An Email Service Provider may accept pre-signed messages from its
329 Message Authors, making it impossible for it to apply the double
330 signature described above; in this case, the double signature MUST be
331 omitted and the Email Service Provider MUST sign with its domain.
332 Therefore, the pre-signed message MUST NOT include "CFBL-Address" and
333 "CFBL-Feedback-ID" in its "h=" tag.
335 This way, the Email Service Provider has the possibility to accept
336 the pre-signed messages and can inject their own CFBL-Address.
338 The following example meets this case:
340 Return-Path: <newsletter@example.com>
341 From: Awesome Newsletter <newsletter@example.com>
342 To: receiver@example.org
343 Subject: Super awesome deals for you
344 CFBL-Address: fbl@saas-mailer.example; report=arf
345 Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@example.com>
346 Content-Type: text/plain; charset=utf-8
347 DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
348 h=Subject:From:To:Message-ID;
349 DKIM-Signature: v=1; a=rsa-sha256; d=saas-mailer.example; s=system;
350 h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
352 This is a super awesome newsletter.
356 When present, CFBL-Address and CFBL-Feedback-ID header fields MUST be
357 included in the "h=" tag of the aforementioned valid DKIM signature.
359 If the domain is not matched by a valid DKIM signature or the header
360 field is not covered by the "h=" tag, the Mailbox Provider SHALL NOT
361 send a report message.
3633.2. Multiple CFBL-Address Header Fields
365 A Message can contain multiple CFBL-Address header fields. These
366 multiple header fields MUST be treated as a list of addresses, each
367 of which should receive a report.
3693.3. CFBL-Feedback-ID Header Field
371 The Message Originator MAY include a CFBL-Feedback-ID header field in
372 its messages for various reasons, e.g., their feedback loop
373 processing system can't do anything with the Message-ID header field.
375 It is RECOMMENDED that the header field include a hard-to-forge
376 protection component, such as an [HMAC] using a secret key, instead
377 of a plaintext string.
3793.4. Receiving Report Address
381 The receiving report address provided in the CFBL-Address header
382 field MUST accept [ARF] reports.
384 It is OPTIONAL for the Message Originator to request a [XARF] report,
385 as described in Section 3.5.1.
389 The Feedback Message (sent by Mailbox Provider to the address
390 provided in the CFBL-Address header field) MUST have a valid [DKIM]
391 signature. This signature MUST match the RFC5322.From domain of the
394 If the message does not have the required valid [DKIM] signature, the
395 Message Originator SHALL NOT process this Feedback Message.
397 The Feedback Message MUST be an [ARF] or [XARF] report. If the
398 Message Originator requests it (described in Section 3.5.1) and it is
399 technically possible for the Mailbox Provider to do so, the Feedback
400 Message MUST be a [XARF] report. Otherwise, the Feedback Message
401 MUST be an [ARF] report.
403 The third MIME part of the [ARF] or the "Samples" section of the
404 [XARF] report MUST contain the Message-ID [RFC5322] of the received
405 message. If present, the CFBL-Feedback-ID header field of the
406 received message MUST be added to the third MIME part of the [ARF] or
407 to the "Samples" section of the [XARF] report.
409 The Mailbox Provider MAY omit or redact all further header fields
410 and/or body to comply with any data regulation laws as described in
415 A Message Originator wishing to receive a [XARF] report MUST append
416 "report=xarf" to the CFBL-Address header field (Section 5.1). The
417 report parameter is separated from the report address by a ";".
419 The resulting header field would appear as shown below.
421 CFBL-Address: fbl@example.com; report=xarf
4254.1. Message Originator
427 A Message Originator who wishes to use this new mechanism to receive
428 Feedback Messages MUST include a CFBL-Address header field in their
431 It is RECOMMENDED that these Feedback Messages be processed
432 automatically. Each Message Originator must decide for themselves
433 what action to take after receiving a Feedback Message.
435 The Message Originator MUST take action to address the described
436 requirements in Section 3.
440 A Mailbox Provider who wants to collect user actions that indicate
441 the message was not wanted and to send a Feedback Message to the
442 Message Originator MAY query the CFBL-Address header field and
443 forward the report to the provided CFBL address.
445 The Mailbox Provider MUST validate the DKIM requirements of the
446 received message described in Section 3.1 and MUST take action to
447 address the requirements described in Section 3.5 when sending
4505. Header Field Syntax
454 The following ABNF imports the rules for fields, CFWS, CRLF, and
455 addr-spec from [RFC5322]. Implementations of the CFBL-Address header
456 field MUST comply with [RFC6532].
458 fields =/ cfbl-address
460 cfbl-address = "CFBL-Address:" CFWS addr-spec
461 [";" CFWS report-format] CRLF
463 report-format = %s"report=" (%s"arf" / %s"xarf")
467 The following ABNF imports the rules for fields, WSP, CRLF, and atext
470 fields =/ cfbl-feedback-id
472 cfbl-feedback-id = "CFBL-Feedback-ID:" CFWS fid CRLF
474 fid = 1*(atext / ":" / CFWS)
476 Empty space is ignored in the fid value and MUST be ignored when
477 reassembling the original feedback-id.
478 In particular, the Message Originator can safely insert CFWS in the
479 fid value in arbitrary places to conform to line length limits when
480 adding the header field.
4826. Security Considerations
484 This section discusses possible security issues of a CFBL-Address
485 header field and their solutions.
4876.1. Attacks on the Feedback Loop Address
489 Like any other email address, a CFBL address can be an attack vector
490 for malicious messages. For example, CFBL addresses can be flooded
491 with spam. This is an existing problem with any existing email
492 address and is not created by this document.
4946.2. Automatic Suspension of an Account
496 Receiving a Feedback Message regarding a Message Author can cause the
497 Message Author to be unreachable if an automatic account suspension
498 occurs too quickly. For example, someone sends an invitation to
499 their friends, and someone else marks this message as spam for some
502 If automatic account suspension is too fast, the Message Author's
503 account will be blocked and the Message Author will not be able to
504 access their emails or send further messages, depending on the
505 account suspension the Message Originator has chosen.
507 Message Originators must take appropriate measures to prevent account
508 suspensions that happen too fast. Therefore, Message Originators
509 have -- mostly proprietary -- ways to assess the trustworthiness of
510 an account. For example, Message Originators may take into account
511 the age of the account and/or any previous account suspension before
512 suspending an account.
5146.3. Enumeration Attacks / Provoking Unsubscription
516 A malicious person may send a series of spoofed Abuse Reporting
517 Format (ARF) messages to known CFBL addresses and attempt to guess a
518 Message-ID / CFBL-Feedback-ID or any other identifiers. The
519 malicious person may attempt to mass unsubscribe/suspend if such an
520 automated system is in place. This is also an existing problem with
521 the current feedback loop implementation and/or One-Click
522 Unsubscription [RFC8058].
524 The Message Originator must take appropriate measures. For example,
525 the CFBL-Feedback-ID header field (if used) can use a hard-to-forge
526 component, such as an [HMAC] with a secret key, instead of a
527 plaintext string, to make an enumeration attack impossible.
531 The provision of such a header field itself does not pose a data
532 privacy issue. The resulting ARF/XARF report sent by the Mailbox
533 Provider to the Message Originator may violate a data privacy law
534 because it may contain personal data.
536 This document already addresses some parts of this problem and
537 describes a way to send a Feedback Message that keeps data privacy
538 safe. As described in Section 3.5, the Mailbox Provider can omit the
539 entire body and/or header field and send only the required fields.
540 As recommended in [RFC6590], the Mailbox Provider can also redact the
541 data in question. Nevertheless, each Mailbox Provider must consider
542 for itself whether this implementation is acceptable and complies
543 with existing data privacy laws in their country.
545 As described in Sections 3.5 and 3.3, it is also strongly RECOMMENDED
546 that the Message-ID and CFBL-Feedback-ID (if used) contain a
547 component that is difficult to forge, such as an [HMAC] that uses a
548 secret key, rather than a plaintext string. See Section 8.3 for an
5516.5. Abusing for Validity and Existence Queries
553 This mechanism could be abused to determine the validity and
554 existence of an email address, exhibiting another potential data
555 privacy issue. If the Mailbox Provider has an automatic process to
556 generate a Feedback Message for a received message, it may not be
557 doing the mailbox owner any favors. As the Mailbox Provider
558 generates an automatic Feedback Message for the received message, the
559 Mailbox Provider proves to the Message Originator that this mailbox
560 exists for sure because it is based on a manual action of the mailbox
563 The receiving Mailbox Provider must take appropriate measures. One
564 possible countermeasure could be pre-existing reputation data
565 (usually proprietary data), for example. Using this data, the
566 Mailbox Provider can assess the trustworthiness of a Message
567 Originator and decide whether to send a Feedback Message based on
5707. IANA Considerations
574 IANA has registered a new header field, per [RFC3864], in the
575 "Provisional Message Header Field Names" registry:
577 Header Field Name: CFBL-Address
583 Author/Change controller: Jan-Philipp Benecke <jpb@cleverreach.com>
589 IANA has registered a new header field, per [RFC3864], in the
590 "Provisional Message Header Field Names" registry:
592 Header Field Name: CFBL-Feedback-ID
598 Author/Change controller: Jan-Philipp Benecke <jpb@cleverreach.com>
604 For simplicity, the DKIM header field has been shortened, and some
605 tags have been omitted.
609 Email about the report will be generated:
611 Return-Path: <sender@mailer.example.com>
612 From: Awesome Newsletter <newsletter@example.com>
614 Subject: Super awesome deals for you
615 CFBL-Address: fbl@example.com; report=arf
616 CFBL-Feedback-ID: 111:222:333:4444
617 Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
618 Content-Type: text/plain; charset=utf-8
619 DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
620 h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
622 This is a super awesome newsletter.
624 Resulting ARF report:
626 ------=_Part_240060962_1083385345.1592993161900
627 Content-Type: message/feedback-report
628 Content-Transfer-Encoding: 7bit
633 Original-Mail-From: sender@mailer.example.com
634 Arrival-Date: Tue, 23 Jun 2020 06:31:38 GMT
635 Reported-Domain: example.com
638 ------=_Part_240060962_1083385345.1592993161900
639 Content-Type: text/rfc822; charset=UTF-8
640 Content-Transfer-Encoding: 7bit
642 Return-Path: <sender@mailer.example.com>
643 From: Awesome Newsletter <newsletter@example.com>
645 Subject: Super awesome deals for you
646 CFBL-Address: fbl@example.com; report=arf
647 CFBL-Feedback-ID: 111:222:333:4444
648 Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
649 Content-Type: text/plain; charset=utf-8
650 DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
651 h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
653 This is a super awesome newsletter.
654 ------=_Part_240060962_1083385345.1592993161900--
6568.2. Data Privacy Safe Report
658 Email about the report will be generated:
660 Return-Path: <sender@mailer.example.com>
661 From: Awesome Newsletter <newsletter@example.com>
663 Subject: Super awesome deals for you
664 CFBL-Address: fbl@example.com; report=arf
665 CFBL-Feedback-ID: 111:222:333:4444
666 Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
667 Content-Type: text/plain; charset=utf-8
668 DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
669 h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
671 This is a super awesome newsletter.
673 Resulting ARF report that only contains the CFBL-Feedback-ID:
675 ------=_Part_240060962_1083385345.1592993161900
676 Content-Type: message/feedback-report
677 Content-Transfer-Encoding: 7bit
682 Original-Mail-From: sender@mailer.example.com
683 Arrival-Date: Tue, 23 Jun 2020 06:31:38 GMT
684 Reported-Domain: example.com
685 Source-IP: 2001:DB8::25
687 ------=_Part_240060962_1083385345.1592993161900
688 Content-Type: text/rfc822-headers; charset=UTF-8
689 Content-Transfer-Encoding: 7bit
691 CFBL-Feedback-ID: 111:222:333:4444
692 ------=_Part_240060962_1083385345.1592993161900--
6948.3. Data Privacy Safe Report with HMAC
696 Email about the report will be generated:
698 Return-Path: <sender@mailer.example.com>
699 From: Awesome Newsletter <newsletter@example.com>
701 Subject: Super awesome deals for you
702 CFBL-Address: fbl@example.com; report=arf
703 CFBL-Feedback-ID: 3789e1ae1938aa2f0dfdfa48b20d8f8bc6c21ac34fc5023d
705 Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
706 Content-Type: text/plain; charset=utf-8
707 DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
708 h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
710 This is a super awesome newsletter.
712 Resulting ARF report that only contains the CFBL-Feedback-ID:
714 ------=_Part_240060962_1083385345.1592993161900
715 Content-Type: message/feedback-report
716 Content-Transfer-Encoding: 7bit
721 Original-Mail-From: sender@mailer.example.com
722 Arrival-Date: Tue, 23 Jun 2020 06:31:38 GMT
723 Reported-Domain: example.com
724 Source-IP: 2001:DB8::25
726 ------=_Part_240060962_1083385345.1592993161900
727 Content-Type: text/rfc822-headers; charset=UTF-8
728 Content-Transfer-Encoding: 7bit
730 CFBL-Feedback-ID: 3789e1ae1938aa2f0dfdfa48b20d8f8bc6c21ac34fc5023d
732 ------=_Part_240060962_1083385345.1592993161900--
7369.1. Normative References
738 [ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An
739 Extensible Format for Email Feedback Reports", RFC 5965,
740 DOI 10.17487/RFC5965, August 2010,
741 <https://www.rfc-editor.org/info/rfc5965>.
743 [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
744 "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
745 RFC 6376, DOI 10.17487/RFC6376, September 2011,
746 <https://www.rfc-editor.org/info/rfc6376>.
748 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
749 Requirement Levels", BCP 14, RFC 2119,
750 DOI 10.17487/RFC2119, March 1997,
751 <https://www.rfc-editor.org/info/rfc2119>.
753 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
754 Specifications: ABNF", STD 68, RFC 5234,
755 DOI 10.17487/RFC5234, January 2008,
756 <https://www.rfc-editor.org/info/rfc5234>.
758 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
759 DOI 10.17487/RFC5322, October 2008,
760 <https://www.rfc-editor.org/info/rfc5322>.
762 [RFC6449] Falk, J., Ed., "Complaint Feedback Loop Operational
763 Recommendations", RFC 6449, DOI 10.17487/RFC6449, November
764 2011, <https://www.rfc-editor.org/info/rfc6449>.
766 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
767 Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
768 2012, <https://www.rfc-editor.org/info/rfc6532>.
770 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
771 RFC 7405, DOI 10.17487/RFC7405, December 2014,
772 <https://www.rfc-editor.org/info/rfc7405>.
774 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
775 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
776 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
778 [XARF] "XARF - eXtended Abuse Reporting Format", commit cc1a6e6,
779 March 2023, <https://github.com/abusix/xarf>.
7819.2. Informative References
783 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
784 Hashing for Message Authentication", RFC 2104,
785 DOI 10.17487/RFC2104, February 1997,
786 <https://www.rfc-editor.org/info/rfc2104>.
788 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
789 Procedures for Message Header Fields", BCP 90, RFC 3864,
790 DOI 10.17487/RFC3864, September 2004,
791 <https://www.rfc-editor.org/info/rfc3864>.
793 [RFC6590] Falk, J., Ed. and M. Kucherawy, Ed., "Redaction of
794 Potentially Sensitive Data from Mail Abuse Reports",
795 RFC 6590, DOI 10.17487/RFC6590, April 2012,
796 <https://www.rfc-editor.org/info/rfc6590>.
798 [RFC8058] Levine, J. and T. Herkula, "Signaling One-Click
799 Functionality for List Email Headers", RFC 8058,
800 DOI 10.17487/RFC8058, January 2017,
801 <https://www.rfc-editor.org/info/rfc8058>.
805 Technical and editorial reviews were provided by the colleagues at
806 CleverReach, the colleagues at Certified Senders Alliance and eco.de;
807 Arne Allisat, Tobias Herkula and Levent Ulucan (1&1 Mail & Media);
808 and Sven Krohlas (BFK Edv-consulting).
813 CleverReach GmbH & Co. KG
817 Phone: +49 4402 97390-16
818 Email: jpb@cleverreach.com