Network Working Group J. Benecke Internet-Draft CleverReach GmbH & Co. KG Intended status: Experimental June 29, 2021 Expires: December 31, 2021 Complaint Feedback Loop Address Header draft-benecke-cfbl-address-header-00 Abstract This document describes a method to allow a mail sender to specify a complaint feedback loop address as an email header and how a mail receiver can use it. This document 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 a complaint feedback loop address to mailbox providers. Currently, providing and maintaining such an address to a mailbox provider is a manual and time-consuming 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 December 31, 2021. Copyright Notice Copyright (c) 2021 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. Code Components extracted from this document must Benecke Expires December 31, 2021 [Page 1] Internet-Draft CFBL Address Header June 2021 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Complaining about an email . . . . . . . . . . . . . . . 4 3.2. Report email . . . . . . . . . . . . . . . . . . . . . . 4 4. Implementation . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Mail senders . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Mailbox provider . . . . . . . . . . . . . . . . . . . . 5 5. Complaint report . . . . . . . . . . . . . . . . . . . . . . 5 6. Header Syntax . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Complaint-FBL-Address . . . . . . . . . . . . . . . . . . 6 6.2. Feedback-ID . . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7.1. Attacks on the FBL address . . . . . . . . . . . . . . . 6 7.2. Enumeration attacks / provoking unsubscription . . . . . 6 7.3. GDPR and other data-regulation laws . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8.1. Complaint-FBL-Address . . . . . . . . . . . . . . . . . . 7 8.2. Feedback-ID . . . . . . . . . . . . . . . . . . . . . . . 8 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Simple . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.2. GDPR safe report . . . . . . . . . . . . . . . . . . . . 9 9.3. GDPR safe report with HMAC . . . . . . . . . . . . . . . 10 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction and Motivation Since a long time there is a way to forward manual complaints back to e.g. a broadcast marketing list operator. The mailbox provider provides a so-called feedback loop [RFC6449]. This feedback loop is being used to give e.g. operators of broadcast marketing lists feedback about resulting complaints from their marketing mailings. Those complaints are based on manual user interaction e.g. IMAP movement to "Junk". As described in [RFC6449] the registration for such a feedback loop needs to be done manually by a human at any FBL provider he wants to receive complaints from. Which can be quite time-consuming if there Benecke Expires December 31, 2021 [Page 2] Internet-Draft CFBL Address Header June 2021 are new feedback loops rising up, or the mail sender wants to add new ip addresses or DKIM domains. Besides, a manual process isn't well suitable and/or doable for smaller mailbox providers. The change of such a complaint address e.g. due to an infrastructure change is another problem. Due to this manual process the mail sender needs to go through all providers again and delete his existing subscriptions and re-signup with the new complaint address. This document addresses this problem with a new email header. It extends the described complaint feedback loop recommendations in [RFC6449] with an automated way to provide the complaint feedback loop address to mail receiver. Mail senders can add this header and willing mailbox provider can use this header to forward the generated report to the provided complaint address. The mail sender just needs to add a email header and isn't required to signup manually at every feedback loop provider. Another benefit would be the mailbox provider doesn't need to develop a manual registration process and verification process. A new email header has been chosen over a new DNS record in favour to be able to easily distinguish between multiple broadcast marketing list operators / mail senders, without the intervention of its users or administrators. For example, if a company uses multiple sending systems, each system can set this header on their own, without the need of a change that has to be done by its users or administrators. On the side of the mailbox provider, there is no need to do an additional DNS query to get the complaint address. This document has been created with GDPR and other data-regulation laws in mind and to address the resulting problems in providing an automated complaint feedback loop address, as the email may contain personal data. Summarised this document has following goals: o Allow mail senders to signal that there is a complaint address without a manual registration at all providers. o Have a way for mailbox provider to get a complaint address without developing an own manual registration process. o Be able to provide a complaint address to smaller mailbox providers who do not have a feedback loop registration process. o Provide a GDPR compliant way for a complaint feedback loop Benecke Expires December 31, 2021 [Page 3] Internet-Draft CFBL Address Header June 2021 2. Definitions The keywords "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 keyword "FBL" in this document is the abbreviation for "feedback loop" and will hereafter be used. The keyword "CFBL" in this document is the abbreviation for "complaint feedback loop" and will hereafter be used. The keyword "MBP" in this document is the abbreviation for "mailbox provider" and will hereafter be used. 3. Requirements 3.1. Complaining about an email The email (sent by mail sender/broadcast marketing list operator) about which a complaint should be sent MUST have at least one valid [DKIM] signature, which covers the From-Header [MAIL] domain. The email about which a complaint should be sent MUST be aligned as specified in [DMARC]. The Complaint-FBL-Address header MUST be covered by the signature, it MUST be included in the "h=" tag of the valid DKIM-Signature header field. If the message isn't properly aligned, nor it does have the required header coverage by [DKIM], the MBP SHOULD NOT send a report email. This ensures that only reports are sent to the complaint address that are based on an authenticated email. 3.2. Report email The report email (sent by MBP to mail sender) MUST have a valid [DKIM] signature and MUST cover the From-Header [MAIL] domain. If the message does not have the required valid [DKIM], the mail sender SHOULD NOT process this email. It is highly RECOMMENDED that the mail sender does further plausibility checks. Benecke Expires December 31, 2021 [Page 4] Internet-Draft CFBL Address Header June 2021 4. Implementation 4.1. Mail senders A mail sender that wishes to receive complaints about their mailings MUST place a Complaint-FBL-Address in the message. The mail sender MAY place a Feedback-ID header in the message out of various reasons. The receiving complaint FBL address, placed in the message, MUST accept [ARF] compatible reports. It is highly RECOMMENDED processing these ARF reports automatically and unsubscribe the complaining receivers. The mail sender MUST take action to address the described requirements in Section 3. 4.2. Mailbox provider An MBP MAY process the complaint and forward it to the complaint FBL address. If the MBP wants to process the complaints and forwards it, he MUST query the Complaint-FBL-Address header. An [ARF] compatible report MUST be sent when a manual action has been taken, e.g. when a receiver marks a mail as spam, by clicking the "This is spam"-button in any web portal or by moving a mail to junk folder, this includes also IMAP/POP3 movements. The MBP SHOULD NOT send any report when an automatic decisions has been made, e.g. spam filtering. The MBP MUST validate and take action to address the described requirements in Section 3. 5. Complaint report The complaint report (sent by MBP to mail sender) MUST be an [ARF] report. The report MUST contain at least the Message-ID [MAIL] or the header "Feedback-ID" of the complaining email. The MBP MAY omit all further headers and/or body to comply with any data-regulation laws. It is highly RECOMMENDED that, if used, the Feedback-ID includes a hard to forge component such as an [HMAC] using a secret key, instead of a plain-text string. Benecke Expires December 31, 2021 [Page 5] Internet-Draft CFBL Address Header June 2021 6. Header Syntax 6.1. Complaint-FBL-Address The following ABNF imports fields, WSP, CRLF and addr-spec from [MAIL]. fields /= cfbl-address cfbl-address = "Complaint-FBL-Address:" 0*1WSP "<" addr-spec ">" CRLF 6.2. Feedback-ID The following ABNF imports fields, WSP, CRLF and atext from [MAIL]. It imports ALPHA and DIGIT from [RFC5234]. fields /= feedback-id feedback-id = "Feedback-ID:" 0*1WSP fid CRLF fid = 1*(atext | ":") 7. Security Considerations This section discusses possible security issues, and their possible solutions, of a complaint FBL address header. 7.1. Attacks on the FBL address As any other email address, a complaint FBL addresses can be an attack vector for malicious emails. The complaint FBL addresses can be for example flooded with spam. This is an existing problem with any existing email address and isn't newly created by this document. The broadcast marketing lists operator/mail sender must take appropriated measures. One possible countermeasure would be a rate limit on the delivering IP. However, this should be done with caution, the normal FBL email traffic must not be impaired. 7.2. Enumeration attacks / provoking unsubscription A malicious person can send a bunch of forged ARF reports to a known complaint FBL addresses and try to guess a Message-ID/Feedback-ID. He might try to do a mass-unsubscription of a complete marketing list. This is also an already existing problem with the current FBL implementation. Benecke Expires December 31, 2021 [Page 6] Internet-Draft CFBL Address Header June 2021 The receiving broadcast marketing lists operator/mail sender must take appropriated measures. As a countermeasure it is recommended that the Message-ID and, if used, Feedback-ID uses a hard to forge component such as an [HMAC] using a secret key, instead of a plain-text string, to make an enumeration attack impossible. If it is impossible for the broadcast marketing lists operator/mail sender to use a hard to forge component, the broadcast marketing lists operator/mail sender should take measures to avoid enumeration attacks. 7.3. GDPR and other data-regulation laws Providing such a header itself doesn't produce a data-regulation law problem. The resulting ARF report, that is sent to the mail sender by the MBP, may conflict with a data-regulation law, as it may contain personal data. This document already addresses some parts of this problem and describes a data-regulation law safe way to send a FBL report. As described in Section 5, the MBP may omit the complete body and/or headers and just sends the required fields. Nevertheless, each MBP must consider on their own, if this implementation is acceptable and complies with the existing data-regulation laws. As described in Section 5, it is also highly RECOMMENDED that the Message-ID and, if used, the Feedback-ID includes a hard to forge component such as an [HMAC] using a secret key, instead of a plain- text string. See Section 9.3 for an example. Using HMAC, or any other hard to forge component, ensures that only the mail sender has knowledge about the data. 8. IANA Considerations 8.1. Complaint-FBL-Address The IANA is requested to register a new header field, per [RFC3864], into the "Permanent Message Header Field Names" registry: Benecke Expires December 31, 2021 [Page 7] Internet-Draft CFBL Address Header June 2021 Header field name: Complaint-FBL-Address Applicable protocol: mail Status: experimental Author/Change controller: Jan-Philipp Benecke Specification document: this document 8.2. Feedback-ID The IANA is requested to register a new header field, per [RFC3864], into the "Permanent Message Header Field Names" registry: Header field name: Feedback-ID Applicable protocol: mail Status: experimental Author/Change controller: Jan-Philipp Benecke Specification document: this document 9. Examples For simplicity the DKIM header has been shortened. 9.1. Simple Email about the report will be generated: Return-Path: From: Awesome Newsletter To: me@example.net Subject: Super awesome deals for you Complaint-FBL-Address: Message-ID: Content-Type: text/plain; charset=utf-8 This is a super awesome newsletter. Resulting ARF report: Benecke Expires December 31, 2021 [Page 8] Internet-Draft CFBL Address Header June 2021 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 Complaint-FBL-Address: Message-ID: Content-Type: text/plain; charset=utf-8 This is a super awesome newsletter. ------=_Part_240060962_1083385345.1592993161900-- 9.2. GDPR safe report Email about the report will be generated: Return-Path: From: Awesome Newsletter To: me@example.net Subject: Super awesome deals for you Complaint-FBL-Address: Message-ID: Feedback-ID: 111:222:333:4444 Content-Type: text/plain; charset=utf-8 This is a super awesome newsletter. Resulting ARF report contains only the Feedback-ID: Benecke Expires December 31, 2021 [Page 9] Internet-Draft CFBL Address Header June 2021 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-headers; charset=UTF-8 Content-Transfer-Encoding: 7bit Feedback-ID: 111:222:333:4444 ------=_Part_240060962_1083385345.1592993161900-- 9.3. GDPR 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 Complaint-FBL-Address: Message-ID: Feedback-ID: 3789e1ae1938aa2f0dfdfa48b20d8f8bc6c21ac34fc5023d63f9e64a 43dfedc0 Content-Type: text/plain; charset=utf-8 This is a super awesome newsletter. Resulting ARF report contains only the Feedback-ID: 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-headers; charset=UTF-8 Content-Transfer-Encoding: 7bit Feedback-ID: 3789e1ae1938aa2f0dfdfa48b20d8f8bc6c21ac34fc5023d63f9e64a 43dfedc0 ------=_Part_240060962_1083385345.1592993161900-- Benecke Expires December 31, 2021 [Page 10] Internet-Draft CFBL Address Header June 2021 10. Acknowledgments Technical and editorial reviews and comments were provided by colleagues at CleverReach, and the colleagues at Certified Senders Alliance. Legal reviews and comments were provided by the colleagues at the Certified Senders Alliance. 11. References 11.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, . [DMARC] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, . [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Benecke Expires December 31, 2021 [Page 11] Internet-Draft CFBL Address Header June 2021 11.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, . [RFC6449] Falk, J., Ed., "Complaint Feedback Loop Operational Recommendations", RFC 6449, DOI 10.17487/RFC6449, November 2011, . Author's Address Jan-Philipp Benecke CleverReach GmbH & Co. KG Schafjueckenweg 2 Rastede 26180 Germany Phone: +49 4402 97390-16 Email: jpb@cleverreach.com Benecke Expires December 31, 2021 [Page 12]