> On 10 Nov 2022, at 12:42, Scott Kitterman <skl...@kitterman.com> wrote: > > I agree that we don't want too much detail in the charter about the technical > nature of the problem, but I would like to understand it in more detail in > order to better assess the appropriateness of what is there. > > If a domain is signing spam and their reputation suffers as a result, isn't > that the system working as designed?
No. Because the domain signing the spam is not the domain sending the spam. What’s happening is that people are sending a single message through a system, getting it signed with a different domain’s DKIM key and then taking that message to a third party platform (or botnet) and sending it out. In many cases, the reason the mail isn’t going out through the signing domain is because the signing domain’s anti-spam heuristics are good enough that the sender couldn’t maintain an account there long enough to send out any volume of email. That’s why the domain has a good reputation - because they block spam off their network. This is a way to steal the good reputation from the good ESP. > I would like to understand what is the technical characteristic of these > messages that is distinct from the non-bad ones. As far as I can tell (and > this isn't the first time I've run across these discussions), there isn't > one. > If that's the case, then I don't think there's an actual technical solution > to > this problem. > > Once work is chartered in the IETF, it tends to get a certain momentum toward > producing a result. Before agreeing that we have a charter to solve a > problem, I'd like to understand we have a problem that can be solved, even > though that requires a bit of discussion at a more detailed level than what > eventually goes in the charter. > Leaving aside algorithms and processes for a moment, could someone describe > how an technically proficient human would examine one of these messages and > determine they are "bad"? There are a couple of characteristics that stand out. 1) They’re coming through infrastructure distinct from the infrastructure that normally sends those signed messages out. So, someone will open up a trial account at a ESP, send one message with the spam content they want to themselves and get the ESPs signature on it. Then they’ll take that message and send it out through a different sending system that does not change any of the signatures. 2) The messages often have two different To: lines laura > > I'll think about what else needs to be there from a compatibility > perspective. > I need to re-read the drafts and think about it first. > > Scott K > > On Thursday, November 10, 2022 5:35:08 AM EST Barry Leiba wrote: >> We could add a sentence or two that says we’re seeing increasing spam >> campaigns that use DKIM replay to get their spam sent out, taking advantage >> of — and subsequently damaging — the reputation of the domain that signed >> the original message. Do you think that would be useful? >> >> More detail than that doesn’t belong in the charter. I would expect to put >> more detail in the Introduction section of the document we come up with. >> >> The “compatibility” part of the charter, and the discussions of what the >> ultimate solution will be, will be what handles the “not breaking email >> architecture” and minimizing damage to legitimate email flows. I don’t >> think more of that detail needs to be in the charter either, but if you >> disagree please suggest specific text you’d like to see. >> >> Barry >> >> On Wed, Nov 9, 2022 at 7:56 PM Scott Kitterman <skl...@kitterman.com> wrote: >>> I think having a precised understanding of the problem that the charter is >>> meant to address is important. I am having a hard time finding a >>> technical >>> distinction between a "replay attack" and the, by design, nature of DKIM's >>> independence from transport details. >>> >>> I have not read all the drafts, but the ones I have looked at seem to want >>> to >>> tie some aspect of a DKIM signature to something in the envelope. I think >>> that would be a 5321/5322 layering violation that would make such >>> proposals >>> difficult for protocol based systems to implement. >>> >>> I think there needs to be something about not breaking the architecture of >>> email in the charter based on what I've read so far, but I don't think I >>> have >>> a fine enough understanding of the problem yet to propose words. >>> >>> Understanding and bounding the problem is, I think, an essential >>> prerequisite >>> to the charter. We've seen efforts fail before due to a lack of consensus >>> on >>> the exact problem (DBOUND comes immediately to mind). >>> >>> Even if there's no report, I think we should make sure we understand the >>> problem first. >>> >>> Would someone who's pushing for a solution please describe what's being >>> done >>> that's technically distinguishable from something like traditional email >>> forwarding (e.g. using may alumni.example.edu address and then >>> alumni.example.edu forwards it to my current "real" address). By design, >>> DKIM >>> has no problem with this behavior, so I'd like to understand how to >>> distinguish good from bad in this space. >>> >>> Scott K >>> >>> On Wednesday, November 9, 2022 12:43:35 PM EST Barry Leiba wrote: >>>> Is this relevant to the charter? Do you doubt the attacks >>>> sufficiently that you would want to object to chartering a working >>>> group to address the issue? >>>> >>>> Barry >>>> >>>> On Wed, Nov 9, 2022 at 4:54 PM Alessandro Vesely <ves...@tana.it> wrote: >>>>> On Wed 09/Nov/2022 13:08:15 +0100 Barry Leiba wrote: >>>>>> [...] >>>>>> >>>>>> Current proposals include the following drafts: >>>>>> - draft-bradshaw-envelope-validation-extension-dkim >>>>>> - draft-chuang-replay-resistant-arc >>>>>> - draft-gondwana-email-mailpath >>>>>> - draft-kucherawy-dkim-anti-replay >>>>>> >>>>>> The working group will start by considering those proposals; other >>>>>> proposals remain welcome. >>>>> >>>>> Isn't there a report on relevant replay attacks? All the above I-D >>>>> say >>>>> that replay attacks are a problem. Bron adds that the attack was >>> >>> widely >>> >>>>> seen in early 2022. However, there's not a panoramic view of the >>>>> problem, mentioning volume, scope, targets and such. >>>>> >>>>> I know replay attacks are possible, but I never saw one. >>>>> >>>>> >>>>> Best >>>>> Ale >>>>> -- >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> _______________________________________________ >>> 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 -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
