Complaint Feedback Loop Address Header
draft-benecke-cfbl-address-header-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9477.
|
|
|---|---|---|---|
| Author | Jan-Philipp Benecke | ||
| Last updated | 2021-07-01 | ||
| RFC stream | (None) | ||
| Formats | |||
| IETF conflict review | conflict-review-benecke-cfbl-address-header, conflict-review-benecke-cfbl-address-header, conflict-review-benecke-cfbl-address-header, conflict-review-benecke-cfbl-address-header, conflict-review-benecke-cfbl-address-header, conflict-review-benecke-cfbl-address-header | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Became RFC 9477 (Experimental) | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-benecke-cfbl-address-header-01
Network Working Group J. Benecke
Internet-Draft CleverReach GmbH & Co. KG
Intended status: Experimental July 01, 2021
Expires: January 2, 2022
Complaint Feedback Loop Address Header
draft-benecke-cfbl-address-header-01
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 January 2, 2022.
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 January 2, 2022 [Page 1]
Internet-Draft CFBL Address Header July 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 . . . . . . . . . . . . . . . . . . . . . . 6
5.1. XARF compatible report . . . . . . . . . . . . . . . . . 6
6. Header Syntax . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Complaint-FBL-Address . . . . . . . . . . . . . . . . . . 6
6.2. CFBL-Feedback-ID . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7.1. Attacks on the FBL address . . . . . . . . . . . . . . . 7
7.2. Automatic suspension of an account . . . . . . . . . . . 7
7.3. Enumeration attacks / provoking unsubscription . . . . . 7
7.4. GDPR and other data-regulation laws . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8.1. Complaint-FBL-Address . . . . . . . . . . . . . . . . . . 8
8.2. CFBL-Feedback-ID . . . . . . . . . . . . . . . . . . . . 9
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Simple . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.2. GDPR safe report . . . . . . . . . . . . . . . . . . . . 10
9.3. GDPR safe report with HMAC . . . . . . . . . . . . . . . 11
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction and Motivation
For 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".
Benecke Expires January 2, 2022 [Page 2]
Internet-Draft CFBL Address Header July 2021
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
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.
Benecke Expires January 2, 2022 [Page 3]
Internet-Draft CFBL Address Header July 2021
o Provide a GDPR compliant way for a complaint feedback loop
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 a valid
[DKIM] signature. The aforementioned valid DKIM signature MUST cover
at least the Complaint-FBL-Address header domain. It is RECOMMENDED
that the DKIM signature aligns with the Complaint-FBL-Address header
domain and the From header [MAIL] domain where possible. The
Complaint-FBL-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.
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 SHALL NOT process this email.
Benecke Expires January 2, 2022 [Page 4]
Internet-Draft CFBL Address Header July 2021
It is highly RECOMMENDED that the mail sender does further
plausibility checks.
4. Implementation
4.1. Mail senders
A mail sender that wishes to receive complaints about their mailings
MUST place a Complaint-FBL-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 [ARF] compatible reports.
The mail sender can OPTIONAL request, as described in Section 5.1, a
[XARF] compatible report. The MBP MAY send a [XARF] compatible
report, if it is technical possible, otherwise a [ARF] compatible
reports will be sent.
It is highly RECOMMENDED processing these reports automatically.
Each mail sender MUST decide on their own which measure they take
after receiving a report.
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.
By default, 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] and [POP3] movements.
The MBP SHALL NOT send any report when an automatic decisions has
been made, e.g. spam filtering.
The MBP SHOULD send a [XARF] compatible report, if the mail sender
requests it as described in Section 5.1. If this is not possible a
[ARF] compatible report MUST be sent.
The MBP MUST validate and take action to address the described
requirements in Section 3.
Benecke Expires January 2, 2022 [Page 5]
Internet-Draft CFBL Address Header July 2021
5. Complaint report
The complaint report (sent by MBP to mail sender) MUST be an [ARF]
report by default. The complaint report MAY be an [XARF] report, if
the mail sender requests it, and the MBP can send it.
The report MUST contain at least the Message-ID [MAIL]. 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 [HMAC] using a secret key,
instead of a plain-text string.
5.1. XARF compatible report
A mail sender that wishes to receive a [XARF] compatible report, MUST
append "report=xarf" to the Complaint-FBL-Address header
(Section 6.1). The resulting header would be the following:
Complaint-FBL-Address: fbl@example.com; report=xarf
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
[";" 0*1WSP report-format] CRLF
report-format = "report=" ("arf" / "xarf")
6.2. CFBL-Feedback-ID
The following ABNF imports fields, WSP, CRLF and atext from [MAIL].
fields /= cfbl-feedback-id
cfbl-feedback-id = "CFBL-Feedback-ID:" 0*1WSP fid CRLF
fid = 1*(atext / ":")
Benecke Expires January 2, 2022 [Page 6]
Internet-Draft CFBL Address Header July 2021
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. Automatic suspension of an account
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 a
invitation to his friends. For somewhat reason someone marks this
mail as spam. Now, if there is an 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.
7.3. 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/CFBL-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.
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, CFBL-Feedback-ID uses a hard to forge component such as an
Benecke Expires January 2, 2022 [Page 7]
Internet-Draft CFBL Address Header July 2021
[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.4. 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 CFBL-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:
Header field name: Complaint-FBL-Address
Applicable protocol: mail
Status: experimental
Author/Change controller: Jan-Philipp Benecke <jpb@cleverreach.com>
Specification document: this document
Benecke Expires January 2, 2022 [Page 8]
Internet-Draft CFBL Address Header July 2021
8.2. CFBL-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: CFBL-Feedback-ID
Applicable protocol: mail
Status: experimental
Author/Change controller: Jan-Philipp Benecke <jpb@cleverreach.com>
Specification document: this document
9. Examples
For simplicity the DKIM header has been shortened, and some tags has
been omitted.
9.1. Simple
Email about the report will be generated:
Return-Path: <sender@mailer.example.com>
From: Awesome Newsletter <newsletter@example.com>
To: me@example.net
Subject: Super awesome deals for you
Complaint-FBL-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;
h=Content-Type:Subject:From:To:Message-ID:
CFBL-Feedback-ID:Complaint-FBL-Address;
This is a super awesome newsletter.
Resulting ARF report:
Benecke Expires January 2, 2022 [Page 9]
Internet-Draft CFBL Address Header July 2021
------=_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
Complaint-FBL-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;
h=Content-Type:Subject:From:To:Message-ID:
CFBL-Feedback-ID:Complaint-FBL-Address;
This is a super awesome newsletter.
------=_Part_240060962_1083385345.1592993161900--
9.2. GDPR 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
Complaint-FBL-Address: fbl@example.com; report=arf
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
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:Complaint-FBL-Address;
This is a super awesome newsletter.
Benecke Expires January 2, 2022 [Page 10]
Internet-Draft CFBL Address Header July 2021
Resulting ARF report contains only 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: 192.0.2.1
------=_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--
9.3. GDPR 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
Complaint-FBL-Address: fbl@example.com; report=arf
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
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:Complaint-FBL-Address;
This is a super awesome newsletter.
Resulting ARF report contains only the CFBL-Feedback-ID:
Benecke Expires January 2, 2022 [Page 11]
Internet-Draft CFBL Address Header July 2021
------=_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-headers; charset=UTF-8
Content-Transfer-Encoding: 7bit
CFBL-Feedback-ID: 3789e1ae1938aa2f0dfdfa48b20d8f8bc6c21ac34fc5023d
63f9e64a43dfedc0
------=_Part_240060962_1083385345.1592993161900--
10. Acknowledgments
Technical and editorial reviews and comments were provided by the
colleagues at CleverReach, the colleagues at Certified Senders
Alliance, Arne Allisat and Tobias Herkula (1&1 Mail & Media) and Sven
Krohlas (BFK Edv-consulting).
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,
<https://www.rfc-editor.org/info/rfc5965>.
[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>.
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
Benecke Expires January 2, 2022 [Page 12]
Internet-Draft CFBL Address Header July 2021
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[XARF] Abusix, "eXtended Abuse Reporting Format",
Web https://github.com/abusix/xarf.
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,
<https://www.rfc-editor.org/info/rfc2104>.
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<https://www.rfc-editor.org/info/rfc3501>.
[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996,
<https://www.rfc-editor.org/info/rfc1939>.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
DOI 10.17487/RFC3864, September 2004,
<https://www.rfc-editor.org/info/rfc3864>.
[RFC6449] Falk, J., Ed., "Complaint Feedback Loop Operational
Recommendations", RFC 6449, DOI 10.17487/RFC6449, November
2011, <https://www.rfc-editor.org/info/rfc6449>.
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 January 2, 2022 [Page 13]