CleverReach GmbH & Co. KG

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

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

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 () 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

• .  Introduction and Motivation
  • .  Scope of this Experiment
  • .  How CFBL Differs from One-Click-Unsubscribe
• .  Conventions Used in This Document
• .  Requirements
  • .  Received Message
    • .  Strict
    • .  Relaxed
    • .  Third Party Address
    • .  DKIM Signature
  • .  Multiple CFBL-Address Header Fields
  • .  CFBL-Feedback-ID Header Field
  • .  Receiving Report Address
  • .  Feedback Message
    • .  XARF Report
• .  Implementation
  • .  Message Originator
  • .  Mailbox Provider
• .  Header Field Syntax
  • .  CFBL-Address
  • .  CFBL-Feedback-ID
• .  Security Considerations
  • .  Attacks on the Feedback Loop Address
  • .  Automatic Suspension of an Account
  • .  Enumeration Attacks / Provoking Unsubscription
  • .  Data Privacy
  • .  Abusing for Validity and Existence Queries
• .  IANA Considerations
  • .  CFBL-Address
  • .  CFBL-Feedback-ID
• .  Examples
  • .  Simple
  • .  Data Privacy Safe Report
  • .  Data Privacy Safe Report with HMAC
• .  References
  • .  Normative References
  • .  Informative References
• Acknowledgments
• Author's Address

Introduction and Motivation This memo extends the CFBL recommendations described in 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 , 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 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 , 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 . 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.

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

How CFBL Differs from One-Click-Unsubscribe For good reasons, the One-Click-Unsubscribe 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.

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

Requirements

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.

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 signature. In this case, the DKIM "d=" parameter and the RFC5322.From field have identical domains. This signature MUST meet the requirements described in . 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.

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

Third Party Address If the domain in RFC5322.From differs from the domain in the CFBL-Address header field, an additional valid signature MUST be added that matches the domain in the CFBL-Address header field. The other existing valid 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 . 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.

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.

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.

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 using a secret key, instead of a plaintext string.

Receiving Report Address The receiving report address provided in the CFBL-Address header field MUST accept reports. It is OPTIONAL for the Message Originator to request a report, as described in .

Feedback Message The Feedback Message (sent by Mailbox Provider to the address provided in the CFBL-Address header field) MUST have a valid signature. This signature MUST match the RFC5322.From domain of the Feedback Message. If the message does not have the required valid signature, the Message Originator SHALL NOT process this Feedback Message. The Feedback Message MUST be an or report. If the Message Originator requests it (described in ) and it is technically possible for the Mailbox Provider to do so, the Feedback Message MUST be a report. Otherwise, the Feedback Message MUST be an report. The third MIME part of the or the "Samples" section of the report MUST contain the Message-ID 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 or to the "Samples" section of the 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 .

XARF Report A Message Originator wishing to receive a report MUST append "report=xarf" to the CFBL-Address header field (). 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

Implementation

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 .

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 and MUST take action to address the requirements described in when sending Feedback Messages.

Header Field Syntax

CFBL-Address The following ABNF imports the rules for fields, CFWS, CRLF, and addr-spec from . Implementations of the CFBL-Address header field MUST comply with . fields =/ cfbl-address cfbl-address = "CFBL-Address:" CFWS addr-spec [";" CFWS report-format] CRLF report-format = %s"report=" (%s"arf" / %s"xarf")

CFBL-Feedback-ID The following ABNF imports the rules for fields, WSP, CRLF, and atext from . 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.

Security Considerations This section discusses possible security issues of a CFBL-Address header field and their solutions.

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.

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.

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 . 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 with a secret key, instead of a plaintext string, to make an enumeration attack impossible.

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 , the Mailbox Provider can omit the entire body and/or header field and send only the required fields. As recommended in , 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 and , 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 that uses a secret key, rather than a plaintext string. See for an example.

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.

IANA Considerations

CFBL-Address IANA has registered a new header field, per , 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

CFBL-Feedback-ID IANA has registered a new header field, per , 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

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

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

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

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

References Normative References 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] 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] 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. Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [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] 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. Internet mail was originally limited to 7-bit ASCII. MIME added support for the use of 8-bit character sets in body parts, and also defined an encoded-word construct so other character sets could be used in certain header field values. However, full internationalization of electronic mail requires additional enhancements to allow the use of Unicode, including characters outside the ASCII repertoire, in mail addresses as well as direct use of Unicode in header fields like "From:", "To:", and "Subject:", without requiring the use of complex encoded-word constructs. This document specifies an enhancement to the Internet Message Format and to MIME that allows use of Unicode in mail addresses and most header field content. This specification updates Section 6.4 of RFC 2045 to eliminate the restriction prohibiting the use of non-identity content-transfer- encodings on subtypes of "message/". [STANDARDS-TRACK] This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner. 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. commit cc1a6e6 Informative References 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. Email messages often contain information that might be considered private or sensitive, per either regulation or social norms. When such a message becomes the subject of a report intended to be shared with other entities, the report generator may wish to redact or elide the sensitive portions of the message. This memo suggests one method for doing so effectively. [STANDARDS-TRACK] 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.

Acknowledgments Technical and editorial reviews were provided by the colleagues at CleverReach, the colleagues at Certified Senders Alliance and eco.de; , and (1&1 Mail & Media); and (BFK Edv-consulting).

Author's Address CleverReach GmbH & Co. KG

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