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 https://www.ietf.org/mai
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