CleverReach GmbH & Co. KG

Schafjueckenweg 2 Rastede 26180 Germany +49 4402 97390-16 jpb@cleverreach.com

art Network Working Group Internet-Draft 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 is a manual to a time-consuming process for mail senders and mailbox providers.

For a long time there is a way for a mailbox provider to forward manual complaints back to the mail sender, which can be a mailbox provider, or an operator of a broadcast marketing list. The mailbox provider provides a so-called feedback loop . 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 the registration for such a feedback loop needs to be done manually by a human at any mailbox provider who provides an FBL, and he wants to receive complaints from. This can be quite time-consuming if there 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 with an automated way to provide the complaint feedback loop address to mailbox providers. 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 an 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: Allow mail senders to signal that there is a complaint address without a manual registration at all providers Have a way for mailbox provider to get a complaint address without developing an own manual registration process Be able to provide a complaint address to smaller mailbox providers who do not have a feedback loop registration process Provide a GDPR compliant way for a complaint feedback loop

For good reasons there is already the One-Click-Unsubscribe signaling, which may have several interests in common with this document. However, this header requires the List-Unsubscribe header, which intention is to provide the unsubscription link of a list. For this reason, this header is only used by broadcast marketing list operator or mailing list operators, but not in normal email traffic. The main interest of this document is now to provide an automated way to signal a complaint feedback loop address to mailbox providers. It is the mail sender's obligation to consider on their own which measure they want to take after receiving a report, this is out of scope of this document.

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 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", it is the party who receives an email, and will be used hereafter. The keyword "mail sender" in this document is used to describe the party who sends an email, this can be an MBP, a broadcast marketing list operator or any other email sending party. It will be used hereafter.

The email (sent by mail sender to MBP) about which a complaint should be sent MUST have at least a valid signature. The aforementioned valid DKIM signature MUST cover at least the CFBL-Address header domain. It is RECOMMENDED that the DKIM signature aligns with the CFBL-Address header domain and the From header domain where possible. The CFBL-Address header MUST be included in the "h=" tag of the aforementioned valid DKIM-Signature. If the message isn't properly aligned, nor it does have the required header coverage by the "h=" tag of a valid DKIM-Signature, the MBP SHALL NOT send a report email. This ensures that only reports are sent to the complaint address that are based on an authenticated email.

The report email (sent by MBP to mail sender) MUST have a valid signature and MUST cover the From header domain. If the message does not have the required valid , the mail sender SHALL NOT process this email. It is highly RECOMMENDED that the mail sender does further plausibility checks.

A mail sender that wishes to receive complaints about their emails MUST place a CFBL-Address header in the message. The mail sender MAY place a CFBL-Feedback-ID header in the message out of various reasons. The receiving complaint FBL address, placed in the message, MUST accept by default compatible reports. The mail sender can OPTIONAL request, as described in , a compatible report. The MBP MAY send a compatible report, if it is technical possible for him, otherwise a compatible reports will be sent. It is highly RECOMMENDED processing these reports automatically. Each mail sender must consider on their own which measure they take after receiving a report. The mail sender MUST take action to address the described requirements in .

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 CFBL-Address header. By default, an 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 and movements. The MBP SHALL NOT send any report when an automatic decisions has been made e.g., spam filtering. The MBP SHOULD send a compatible report, if the mail sender requests it as described in . If this is not possible a compatible report MUST be sent. The MBP MUST validate and take action to address the described requirements in .

The complaint report (sent by MBP to mail sender) MUST be an report by default. The complaint report MAY be an report, if the mail sender requests it, and the MBP can send it. The report MUST contain at least the Message-ID . If present, the header "CFBL-Feedback-ID" of the complaining email MUST be added additionally. 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 CFBL-Feedback-ID includes a hard to forge component such as an using a secret key, instead of a plain-text string.

A mail sender that wishes to receive a compatible report, MUST append "report=xarf" to the CFBL-Address header. The resulting header would be the following:

The following ABNF imports fields, WSP, CRLF and addr-spec from .

The following ABNF imports fields, WSP, CRLF and atext from .

This section discusses possible security issues, and their possible solutions, of a complaint FBL address header.

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 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.

Sending a FBL report against a mailbox may lead into an inaccessibility for the account owner, if there is a too quick automatic account suspension. For example, someone sends an invitation to his friends. For somewhat reason someone marks this mail as spam. Now, if there is a too quick automatic account suspension in place, the senders account will be suspended, and the sender can't access his mails anymore. MBPs and mail senders MUST take appropriate measures to prevent this. MBPs and mail senders have therefore, mostly proprietary, ways to evaluate the trustworthiness of an account. For example MBPs and mail senders can consider the account age and/or any other account suspension that happened beforehand, before an account gets suspended.

A malicious person can send a bunch of forged ARF reports to a known complaint FBL addresses and try to guess a Message-ID/CFBL-Feedback-ID. He might try to do a mass-unsubscription/suspension, if there is such an automatic in place. This is also an already existing problem with the current FBL implementation and/or the One-Click-Unsubscription . The receiving mail sender MUST take appropriated measures. As a countermeasure it is recommended that the Message-ID and, if used, CFBL-Feedback-ID uses a hard to forge component such as an using a secret key, instead of a plain-text string, to make an enumeration attack impossible. If it is impossible for the mail sender to use a hard to forge component, the mail sender should take measures to avoid enumeration attacks.

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 , 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 , it is also highly RECOMMENDED that the Message-ID and, if used, the CFBL-Feedback-ID includes a hard to forge component such as an using a secret key, instead of a plain-text string. See for an example. Using HMAC, or any other hard to forge component, ensures that only the mail sender has knowledge about the data.

The IANA is requested to register a new header field, per , into the "Permanent Message Header Field Names" registry:

Specification document: this document ]]>

The IANA is requested to register a new header field, per , into the "Permanent Message Header Field Names" registry:

Specification document: this document ]]>

For simplicity the DKIM header has been shortened, and some tags has been omitted.

Email about the report will be generated:

From: Awesome Newsletter To: me@example.net 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; h=Content-Type:Subject:From:To:Message-ID: CFBL-Feedback-ID:CFBL-Address; This is a super awesome newsletter. ]]>

Resulting ARF report:

From: Awesome Newsletter To: me@example.net 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; h=Content-Type:Subject:From:To:Message-ID: CFBL-Feedback-ID:CFBL-Address; This is a super awesome newsletter. ------=_Part_240060962_1083385345.1592993161900-- ]]>

Email about the report will be generated:

From: Awesome Newsletter To: me@example.net Subject: Super awesome deals for you CFBL-Address: fbl@example.com; report=arf Message-ID: CFBL-Feedback-ID: 111:222:333:4444 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. ]]>

Resulting ARF report contains only the CFBL-Feedback-ID:

Email about the report will be generated:

From: Awesome Newsletter To: me@example.net Subject: Super awesome deals for you CFBL-Address: fbl@example.com; report=arf Message-ID: CFBL-Feedback-ID: 3789e1ae1938aa2f0dfdfa48b20d8f8bc6c21ac34fc5023d 63f9e64a43dfedc0 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. ]]>

Resulting ARF report contains only the CFBL-Feedback-ID:

Technical and editorial reviews and comments were provided by the colleagues at CleverReach, the colleagues at Certified Senders Alliance and eco.de, Arne Allisat and Tobias Herkula (1&1 Mail & Media) and Sven Krohlas (BFK Edv-consulting).

Abusix In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature.This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK] This document defines an extensible format and MIME type that may be used by mail operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used in Internet email. [STANDARDS-TRACK] Complaint Feedback Loops similar to those described herein have existed for more than a decade, resulting in many de facto standards and best practices. This document is an attempt to codify, and thus clarify, the ways that both providers and consumers of these feedback mechanisms intend to use the feedback, describing some already common industry practices.This document is the result of cooperative efforts within the Messaging Anti-Abuse Working Group, a trade organization separate from the IETF. The original MAAWG document upon which this document is based was published in April, 2010. This document does not represent the consensus of the IETF; rather it is being published as an Informational RFC to make it widely available to the Internet community and simplify reference to this material from IETF work. This document is not an Internet Standards Track specification; it is published for informational purposes. This document describes a method for signaling a one-click function for the List-Unsubscribe email header field. The need for this arises out of the actuality that mail software sometimes fetches URLs in mail header fields, and thereby accidentally triggers unsubscriptions in the case of the List-Unsubscribe header field. The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server. IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244. IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821. [STANDARDS-TRACK] The Post Office Protocol - Version 3 (POP3) is intended to permit a workstation to dynamically access a maildrop on a server host in a useful fashion. [STANDARDS-TRACK] This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.