> On 16 Aug 2023, at 09:57, Alessandro Vesely <ves...@tana.it> wrote: > > On Tue 15/Aug/2023 14:59:18 +0200 Laura Atkins wrote: >>> On 15 Aug 2023, at 12:36, Alessandro Vesely <ves...@tana.it> wrote: >>> On Tue 15/Aug/2023 08:10:23 +0200 Bron Gondwana wrote: >> >>>> "Problem solved." [...] > > > Hm.. More than defining the replay attack, we need to define what kind of > solution is acceptable. The Basic solution space the I-D proposes doesn't > include limiting what messages are signed by a domain. > > >>>> We've love to not sign spam at all, but short of never allowing users to >>>> send email, it's not actually possible. We're not trying to "accomodate >>>> sites that send spam", we're trying to minimise the blast damage of a >>>> message that a bad actor manages to get signed - because that reduces that >>>> value of getting such a message stamped with a signature, and that reduces >>>> the amount of spam. >>> Still, knowing that he's a bad actor, you could skip signing. Are there so >>> many new spammers every day? Or, rather, there is a bunch of professional >>> spammers who know how to hide? >> How do you know he’s a bad actor before he does a bad action? That’s the >> crux of the problem: > > > Very much agreed. > > >> the bad actor looks very much like a not-bad actor. You can’t generally tell >> the difference between the two until after the bad action has happened. In >> fact, the bad actor is often going to try and look as much like a not-bad >> actor as possible. That doesn’t mean they can’t be tracked. They are, and >> many of them get shut down based on patterns and vetting and a lot of things. > > > Tracking and shooting down is good. However, as you note, it is not enough. > > How about enacting common sense rules such as Never sign anything without > reading the small print? In the same way that users agree to any Terms & > Conditions without reading, domains sign any mail their users send without > knowing. Decadent practices, aren't they?
Can you expand on this? I’m not sure I understand how reading the content will fix the problem. Spam is an issue of volume mostly. > Does Google know the real ID of its users? I'd guess in many cases they do; > for example, Google does payments and bank stuff which do require real IDs (I > pay, therefore I am). Nevertheless, they sign all email messages with the > same d=gmail.com, irrespective of user reputation. > > I fully understand the right to anonymity. I know it's in the First > Amendment, in the US. However, I figure users should trust their mailbox > providers enough to disclose their real ID. The minority of people who > really need to care about that can always find a provider in countries where > ISPs cannot be forced to disclosure, or suffer sending lower grade mail. > > Would that be an acceptable kind of solution? I’m not sure I understand how this is a solution. As Evan and Emanuel have both said the bad actors have access to many thousands of accounts that look like real accounts. In my own experience, they have access to validating credit cards which is one of the most common ways to validate a real identity online. laura (participating) >> But the reality is: bad-actors are going to get through every process. If we >> could ID spammers up front and stop them from spamming we’d very likely have >> done it already. In this case, they’re using DKIM in a way that was foreseen >> by the original authors but not treated as something that needed to be >> addressed in the protocol. > > > Yes, replay was considered. Indeed, most protocol-change ideas being > proposed these days turn out to have been already drafted at the time. > Anyway, changing DKIM doesn't seem to be something that will have practical > effects in the short and medium term. Consider ed25519, which is so > straightforward to implement. -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
