Re: [Ietf-dkim] DKIM-FBL
I'm betting the chairs would want this not to consume any of the so-far-meager energy this WG is showing. I can imagine that ietf-smtp would be a reasonable place to at least announce that you're working on this. I don't know that that's a good home for ongoing discussion either though. We don't really have a venue that talks about feedback loops that I can find, which seems to me to be the primary thing here. It almost seems like the old MARF list (if it's still open) might be, though I don't know who might be paying attention. Or you could always use the ART list. If you're trying to identify a venue for processing it, there's no WG that comes to mind. You could take it to DISPATCH and see what they recommend. But unless lots of people show up and want this to happen inside the IETF, I would consider using the ISE route. -MSK On Wed, Sep 27, 2023 at 4:37 AM Brotman, Alex wrote: > 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 > > > ___ > Ietf-dkim mailing list > Ietf-dkim@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-dkim > ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM-FBL
Some senders use a different selector when sending from different ESPs while they use the same d= in the DKIM signature. Good point on that usage. That should be "report generator(s)". -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -Original Message- > From: Ietf-dkim On Behalf Of Alessandro Vesely > Sent: Wednesday, September 27, 2023 10:07 AM > To: ietf-dkim@ietf.org > Subject: Re: [Ietf-dkim] DKIM-FBL > > On 9/27/23 13:36, Brotman, Alex wrote: > > 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. > > I'm not clear why would DKIM selectors (s=) be involved in the DNS name > generation. There are people who change selector for each message. In > general, selectors play no role in identification and are solely used for key > rotation. I guess your spec derives from seeing per-campaign selectors, but I > doubt it is a common habit. I'd suggest using subdomains for such purpose. > > > For a nit, consider the term "reporter" in the last paragraph of the > introduction: > > By allowing reporters to discover the destination on their own, this > should make getting FBLs to the original DKIM signer(s) easier. > > As you hold that FBLs are reports from users to their MBPs, which only in > some situations are forwarded to the original sender, the term may sound > ambiguous. I'd suggest "reporting MBPs" instead. > > > For discussion, it'd be interesting to analyze similarity and differences > with List- > Unsubscribe:, for FNs. How would a MBP decide whether to make use of one, > the other, or both methods to signal its user's reaction? > > > Best > Ale > -- > > > > > > ___ > Ietf-dkim mailing list > Ietf-dkim@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ietf- > dkim__;!!CQl3mcHX2A!ApmZ1rxxcG68FfqEf2KUszsYyF4WU2VxYQOtHvXbzW > xc7ZRZo_WqUAY2kwKTPx7qgia63h0pSQTfUpJQUwE$ ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM-FBL
On 9/27/23 13:36, Brotman, Alex wrote: 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. I'm not clear why would DKIM selectors (s=) be involved in the DNS name generation. There are people who change selector for each message. In general, selectors play no role in identification and are solely used for key rotation. I guess your spec derives from seeing per-campaign selectors, but I doubt it is a common habit. I'd suggest using subdomains for such purpose. For a nit, consider the term "reporter" in the last paragraph of the introduction: By allowing reporters to discover the destination on their own, this should make getting FBLs to the original DKIM signer(s) easier. As you hold that FBLs are reports from users to their MBPs, which only in some situations are forwarded to the original sender, the term may sound ambiguous. I'd suggest "reporting MBPs" instead. For discussion, it'd be interesting to analyze similarity and differences with List-Unsubscribe:, for FNs. How would a MBP decide whether to make use of one, the other, or both methods to signal its user's reaction? Best Ale -- ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
[Ietf-dkim] DKIM-FBL
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
