Re: [Ietf-dkim] DKIM-FBL
Per Dave's suggestion, I'll take this to the M3 Technical list. When we believe we're well-situated, we'll come back to ietf-smtp or marf. FWIW, Dispatch suggested the dmarc or dkim lists. Thanks folks, we'll be back. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -Original Message- > From: Dave Crocker > Sent: Thursday, September 28, 2023 1:05 PM > To: Brotman, Alex > Cc: ietf-dkim@ietf.org > Subject: Re: [Ietf-dkim] DKIM-FBL > > On 9/27/2023 7:41 PM, Murray S. Kucherawy wrote: > > We don't really have a venue that talks about feedback loops that I > > can find, > > I strongly suggest pursuing this first in a group devoted to anti-abuse > email, with a > range of software developers and platform providers. > > This will ensure both subject matter expertise and operational interest. > > If there is enough interest and productivity there, then when the work gets > to a > degree of maturity, pursuing enhancements and formal status, via the IETF, > will > make sense. > > d/ > > -- > Dave Crocker > dcroc...@gmail.com > mast:@dcrocker@mastodon.social > 408.329.0791 > > Volunteer, Silicon Valley Chapter > Information & Planning Coordinator > American Red Cross > dave.crock...@redcross.org ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM-FBL
On 9/27/2023 7:41 PM, Murray S. Kucherawy wrote: We don't really have a venue that talks about feedback loops that I can find, I strongly suggest pursuing this first in a group devoted to anti-abuse email, with a range of software developers and platform providers. This will ensure both subject matter expertise and operational interest. If there is enough interest and productivity there, then when the work gets to a degree of maturity, pursuing enhancements and formal status, via the IETF, will make sense. d/ -- Dave Crocker dcroc...@gmail.com mast:@dcrocker@mastodon.social 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM-FBL
On Wed, Sep 27, 2023, at 9:06 AM, Alessandro Vesely wrote: > 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'm with Ale's thought process on using d= instead of s=. Briefly, I thought that putting the DNS label under the selector would be great for situations when the selector is delegated via CNAMEs (and hence any subdomains would also be delegated), but I was conflating CNAME delegation with NS. The domain owner would have to publish the label in DNS in addition to the CNAME, and we know how difficult it is for most domain owners to modify their DNS. As discussed in the other thread, it is common for messages to carry signatures for multiple domains (not all are rfc5322.From aligned), indicating a shared responsibility. The responsible party(ies) capable of receiving FBLs would publish the DKIM-FBL label in DNS under their signatory domain and not depend on a different domain owner (bad senders would not want feedback to go to the ESP/intermediary) > 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. I think adding a third signature in a subdomain, with a name that has some meaning (campaign, category, etc) would be an alternative to how the non-standard Feedback-Id header is in use today. > For discussion, it'd be interesting to analyze similarity and > differences with List-Unsubscribe:, for FNs. It seems logical that List-Unsubscribe could have supplanted FBLs in some ways. Is there hope for that? I don't think it's common for MBPs to post an unsubscribe when users report spam. So, I think the only way this discussion idea has merit is if everyone starts treating spam complaints and unsubscriptions the same way. If the sender doesn't add a List-Unsubscribe header, does that mean the ESP/intermediary should add one in order to get this "FBL equivalent" event stream for the messages it is partially responsible? Can there be two of these headers for situations when the unsubscribe, spam complaint, bounce suppression, compromised credential detection, DKIM replay detection, etc, processes are a shared responsibility between the sender and the ESP/intermediary? I assume that would introduce risk of DKIM signature breakage. This is one of the reasons why I like this DKIM-FBL approach of using DNS for discovery rather than the other idea to use headers to specify the complaint address. I think any situation involving intermediaries or delegated sending of existing headers should not depend on adding headers that may or may not already exist. > How would a MBP decide > whether to make use of one, the other, or both methods to signal its > user's reaction? I think the logic/situation would be: 1. The user doesn't like this message 2. The message may or may not have a List-Unsubscribe header - which may or may not have a functioning unsubscribe process. The MBP may or may not treat spam complaints as equivalent to unsubscribe requests, and vice versa. 3. The message is DKIM signed by two different domains, which indicates there are multiple authenticated parties responsible for the message being sent. The delineation line for the responsibilities and capabilities of each party will be highly inconsistent and unknown to the MBP. 4. If one or both of these parties publish the label in DNS under their respective d= domains, this indicates that they are capable of receiving the feedback, and the MBP can/should send feedback to each responsible party to indicate that the user didn't like the message 5. Each report receiver incorporates the feedback into appropriate action pertaining to their area of responsibility. Jesse___ Ietf-dkim mailing list Ietf-dkim@ietf.org
Re: [Ietf-dkim] DKIM-FBL
On 9/27/23 16:47, Brotman, Alex wrote: Some senders use a different selector when sending from different ESPs while they use the same d= in the DKIM signature. Don't same d= mean they don't want to differentiate? Using a different selector is an a artifact of keys distribution; it doesn't really substantiate a will to keep settings apart. Best Ale -- ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
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
