Hey folks,
I'm not entirely sure this is the right place for this. Someone else suggested
the DMARC list, and I thought perhaps the "smtp" list might make more sense.
If I'm shuffled off to one of those lists, I'll let this thread know.
I've attached a draft that uses attributes of a passing DKIM signature to
create a DNS label that can be used to discover an FBL address. This feedback
address can be used by message receivers to provide a copy of FN (and
potentially FP) (Spam/Not-Spam) reports to the DKIM signers. This allows for
entities to perhaps sign with more than one signature, and provide feedback to
each signer if desired (or each can list multiple rcpts if desired). With
traditional FBLs, the lookup is likely based off the final sender IP address,
which could be the original sender, or an intermediary. This DKIM-based method
could aid both MBPs and ESPs in fighting outbound abuse from their platforms.
There are also methods in the document to attempt to do more to make reports
smaller, aiding storage and PII concerns. Thanks for your time and feedback.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
Network Working Group A. Brotman
Internet-Draft Comcast, Inc
Intended status: Standards Track 22 September 2023
Expires: 25 March 2024
Email Feedback Reports for DKIM Signers
draft-brotman-dkim-fbl-00
Abstract
Mechanism to discover a destination used to deliver user-supplied FBL
reports to an original DKIM signer or other interested 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 March 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 March 2024 [Page 1]
RFC draft-brotman-dkim-fbl-00 DKIM-FBL September 2023
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. DNS Record Location . . . . . . . . . . . . . . . . . . . . . 2
3. DNS Record Format . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Samples . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Report Contents . . . . . . . . . . . . . . . . . . . . . . . 3
5. Verifying External Destinations . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6.1. Feedback to Malicious Senders . . . . . . . . . . . . . . 4
6.2. Report Contents for ARF . . . . . . . . . . . . . . . . . 5
7. Other Considerations . . . . . . . . . . . . . . . . . . . . 5
7.1. Supplying FP Reports . . . . . . . . . . . . . . . . . . 5
7.2. Site Requirements . . . . . . . . . . . . . . . . . . . . 5
7.3. Report Delivery . . . . . . . . . . . . . . . . . . . . . 5
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 5
9. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
11. Normative References . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
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. DNS Record Location
The record will combine a label with the "d" value from the DKIM
signature in the message being sent, as well as the selector. Such
as the case where "d=example.org", and "s=contact":
_feedback.contact._domainkey.example.org
The DNS entry will contain a TXT record described below. By
including the selector, this allows a domain to send feedback to be
able to segment the feedback to various sources.
Brotman Expires 25 March 2024 [Page 2]
RFC draft-brotman-dkim-fbl-00 DKIM-FBL September 2023
3. 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 "DKIMRv1"
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 reporter 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 reporter 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.
3.1. Samples
_feedback.contact._domainkey.example.org TXT
"v=DKIMRv1;ra=report...@feedback.example.org"
_feedback.contact._domainkey.example.org TXT
"v=DKIMRv1;rfr=_feedback._domainkey.example.org"
_feedback.contact._domainkey.example.org TXT
"v=DKIMRv1;ra=f...@example.org;rfr=_feedback._domainkey.example.org"
_feedback._domainkey.example.org TXT
"v=DKIMRv1;ra=other_...@example.org"
4. Report Contents
When the report format is specified as "arf", the report contents
should adhere to [RFC5965].
Brotman Expires 25 March 2024 [Page 3]
RFC draft-brotman-dkim-fbl-00 DKIM-FBL September 2023
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)
5. 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:
_feedback.foo._domainkey.example.org TXT
"v=DKIMRv1 ; ra=report...@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=DKIMRv1"
foo.example.org._report._feedback.othersite.com TXT "v=DKIMRv1"
If the receiving site is comfortable with such a configuration, they
may wish to use a wildcard at "*._feedback.othersite.com" so that all
lookups for the verification record would pass.
6. Security Considerations
6.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.
Brotman Expires 25 March 2024 [Page 4]
RFC draft-brotman-dkim-fbl-00 DKIM-FBL September 2023
6.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.
7. Other Considerations
7.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.
7.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.
7.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.
8. Contributors
9. Notes
10. References
11. Normative References
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>.
[RFC5965] 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>.
Author's Address
Brotman Expires 25 March 2024 [Page 5]
RFC draft-brotman-dkim-fbl-00 DKIM-FBL September 2023
Alex Brotman
Comcast, Inc
Email: alex_brot...@comcast.com
Brotman Expires 25 March 2024 [Page 6]
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
