Network Working Group A. Brotman Internet-Draft Comcast, Inc Intended status: Standards Track 23 October 2023 Expires: 25 April 2024 Email Feedback Reports for DKIM Signers draft-brotman-dkim-fbl-01 Abstract Mechanism to discover a destination used to deliver user-supplied FBL reports to an original DKIM signer or other responsible parties. This should allow the reporting entity to deliver reports via email for each party which has affixed a validating DKIM signature. The discovery is made via DNS and the record is constructed using items within the DKIM signature in the message. 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 25 April 2024. 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 (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 include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Brotman Expires 25 April 2024 [Page 1] RFC draft-brotman-dkim-fbl-01 DKIM-FBL October 2023 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Discovery using DNS . . . . . . . . . . . . . . . . . . . . . 2 3. DNS Record Location . . . . . . . . . . . . . . . . . . . . . 3 4. DNS Record Format . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Samples . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Report Contents . . . . . . . . . . . . . . . . . . . . . . . 5 6. Verifying External Destinations . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7.1. Feedback to Malicious Senders . . . . . . . . . . . . . . 6 7.2. Report Contents for ARF . . . . . . . . . . . . . . . . . 6 8. Other Considerations . . . . . . . . . . . . . . . . . . . . 6 8.1. Supplying FP Reports . . . . . . . . . . . . . . . . . . 6 8.2. Site Requirements . . . . . . . . . . . . . . . . . . . . 6 8.3. Report Delivery . . . . . . . . . . . . . . . . . . . . . 6 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 10. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 12. Normative References . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Historically, Feedback Loops (FBL), typically comprised of False Positive (FP) and False Negative (FN) reports, have allowed users the ability to inform their Mailbox Provider (MBP) that they disagree with a message's placement in the Inbox or Spam folder. In some situations, a MBP may then forward that complaint directly, or via an intermediary, to the original source system of that message. Additionally, these complaints reach the source system via a registration system, typically tying a set of IPs or DKIM-based domains to a specific reporting address. By allowing reporters to discover the destination on their own, this should make getting FBLs to the original DKIM signer(s) easier. 2. Discovery using DNS There are alternative approaches for discovering the feedback information proposed. Particularly, by adding a new header to every outbound message to define the feedback address. The advantage of the DNS approach is that it can be changed after messages are delivered, allowing for old reports to be processed after migrating to a new report receiving endpoint. It also avoids common problems with modifying headers of messages that are already signed by another DKIM signature. Brotman Expires 25 April 2024 [Page 2] RFC draft-brotman-dkim-fbl-01 DKIM-FBL October 2023 Email service providers and intermediaries, which have a shared responsibility with an upstream sender, will commonly add their own DKIM signatures to the messages; thus resulting in the message having two signatures in different DKIM d= domains. Dual-signed messages will result in feedback going to the location specified in the DNS for both domains. Thus there is no reason to modify any message headers and potentially breaking the original DKIM signature. 3. DNS Record Location The record will combine a label with the "d" value from the DKIM signature in the message being sent, optionally using a DNS wildcard (* character). Such as the case where "d=example.org", the record would be located at: _feedback._domainkey.example.org or *._feedback._domainkey.example.org If the reporting destination needs to be different for individual DKIM selectors, each selector will need a DNS record with a value combined with a label with the "s=" value from the DKIM signature in the message being sent. Such as the case where "d=example.org", and "s=contact": contact._feedback._domainkey.example.org By including the selector, this allows a domain to be able to segment the feedback to various report processing providers, but a wildcard can no longer be used as a catch-all and an individual record must be created for each selector in use. DKIM selectors are not supposed to be used for identification purposes, and they should change frequently to facilitate key rotation. The need for selector level feedback still needs to be assessed. All domain owners that want to ensure they receive all feedback should, at a mimimum, publish a record at the following location as a catch-all: _feedback._domainkey.example.org The DNS entry will contain a TXT record described below. Brotman Expires 25 April 2024 [Page 3] RFC draft-brotman-dkim-fbl-01 DKIM-FBL October 2023 4. DNS Record Format The DNS record should contain the information necessary for a report generator to send the feedback to the proper location. v: A string identifying the record. The value must be "DKIMRFBLv1" ra: An email address destination for reports. The address should match the format defined in [RFC5321]. If there is a "rfr" entry, the "ra" may be omitted. If there is more than one target address, the entries must be separated by a comma (","). rfr: An optional field to refer the report generator(s) to another DNS entry. c: Content flag. If set to 'n', the reporting entity SHOULD remove all content beyond the headers of the original message that is being reported. h: The header by which the signer can identify the recipient, sender, and campaign. If a report generator is trying to create a minimalistic report, this would be the minimum amount of information to properly act to the report. This field is OPTIONAL, and may contain only one attribute. f: Format requested by report receiver. Options are "arf" and "xarf". Default is "arf", and multiple values may be separated by a comma (,). If a report sender is unable to generate a report in a requested format, they SHOULD NOT send a report. 4.1. Samples _feedback._domainkey.example.org TXT "v=DKIMRFBLv1;ra=reporting@feedback.example.org" contact._feedback._domainkey.example.org TXT "v=DKIMRFBLv1;rfr=_feedback._domainkey.example.org" contact._feedback._domainkey.example.org TXT "v=DKIMRFBLv1;ra=fbl@example.org;rfr=_feedback._domainkey.example.org " *._feedback._domainkey.example.org TXT "v=DKIMRFBLv1;ra=other_fbl@example.org" Brotman Expires 25 April 2024 [Page 4] RFC draft-brotman-dkim-fbl-01 DKIM-FBL October 2023 5. Report Contents When the report format is specified as "arf", the report contents should adhere to [RFC5965]. When the report format is chosen as "xarf" [XARF], the report generator should reference the materials below as to the format. XARF follows a JSON format and the format may change over time to match that specification. The current format can be referenced: https://github.com/abusix/xarf/blob/master/schemas/3/spam.schema.json (https://github.com/abusix/xarf/blob/master/schemas/3/ spam.schema.json) 6. Verifying External Destinations In order to limit the possibility of misdirected reports, if the receiving entity domain does not match the d= of the DKIM signature, there must be a DNS record to verify the external destination. Consider the record: foo._feedback._domainkey.example.org TXT "v=DKIMRFBLv1 ; ra=reporting@othersite.com" In order for "othersite.com" to receive reports for this DKIM signature, a record must exist at specified location, and contain a specified value. 1. Using the domain of the destination 2. Prepend "_report._feedback" 3. Prepend the values from d= and s= from the original signature. 4. Ensure the value is set to "v=DKIMRFBLv1" foo.example.org._report._feedback.othersite.com TXT "v=DKIMRFBLv1" If the feedback receiver is comfortable with receiving feedback for all selectors within a domain, then they may omit the s= value from the DNS record location. The record would be named: example.org._report._feedback.othersite.com TXT "v=DKIMRFBLv1" 7. Security Considerations Brotman Expires 25 April 2024 [Page 5] RFC draft-brotman-dkim-fbl-01 DKIM-FBL October 2023 7.1. Feedback to Malicious Senders There is some concern that a MBP may provide some advantage or useful information to a malicious entity by providing them with FBL data. Each MBP should use their own judgement when deciding where to send reports. It is possible that an attacker could use this information to attempt to bypass anti-spam filters, or to validate a recipient at a given site. 7.2. Report Contents for ARF Noting in [RFC5965] section 2.g, there should be enough information for most senders to process a complaint without the content of the message. While the c flag allows the report receiver to state that they do not wish to receive content, the report generator, as per [RFC5965] does not need to include that information, regardless of the flag settings. 8. Other Considerations 8.1. Supplying FP Reports It is at the discretion of the report generator as to whether they supply False Positive reports to the report requester. 8.2. Site Requirements A report generator may place some requirements on the sender in order to be eligible to receive reports. This could include something such as a DMARC policy requirements, TLS usage, or some level of reputation. 8.3. Report Delivery In this document, only delivery via SMTP is specified. However, a separate document could be created to allow for feedback via HTTPS, UDP, or something yet to be defined. 9. Contributors 10. Notes 11. References 12. Normative References Brotman Expires 25 April 2024 [Page 6] RFC draft-brotman-dkim-fbl-01 DKIM-FBL October 2023 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . [RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, DOI 10.17487/RFC5965, August 2010, . Author's Address Alex Brotman Comcast, Inc Email: alex_brotman@comcast.com Brotman Expires 25 April 2024 [Page 7]