> On 11 Dec 2022, at 20:52, Murray S. Kucherawy <superu...@gmail.com> wrote: > > On Sun, Dec 11, 2022 at 12:34 PM Michael Thomas <m...@mtcc.com > <mailto:m...@mtcc.com>> wrote: > Re: stripping signatures, all the attacker needs to do is either send it to a > service that doesn't strip signatures or use their own MTA. Trivially > avoidable, and a Maginot Line of epic narrowness. > > Right, I think this is an aspect of that proposal that warrants further > debate. I think the argument is compelling, but it's clearly not bulletproof. > > As for resolution: the first obvious one is to not send spam in the first > place. That is the root of the problem. The second is that Bcc's can be > treated with more suspicion. Neither of these needs the working group to do > anything. > > I think this is easier said than done. In the example I gave, "don't send > spam in the first place" reduces to "make sure your users are 100% > trustworthy or that your outbound spam filters are 100% accurate", which > strikes me as an impossible bar to meet.
Also, in the case of replay attacks, we’re redefining spam to a point of uselessness. Spam is mail that users didn’t ask to receive. But the initial message that’s being signed is an opt-in message. The sender knows the recipient address wants the message. We’ve spent 25 years trying to block spam, I’m not sure that this is even a solveable problem. Even if you made COI the default and could only send mail with an actual confirmation message in hand, that’s a trivially jumpable hoop for the spammer to negotiate. > The alternative is to say: Well, if you can't make at least one of those two > quantities bulletproof, then don't sign your mail. That, though, sounds a > lot to me like tossing DKIM in the bin Agreed. laura -- 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
