On Thu, Aug 3, 2023, at 15:50, Michael Thomas wrote: > Barry Leiba <barryle...@computer.org> Tue, 01 August 2023 18:40 UTC > > As someone who has, as an AD, questioned the publication of such > background documents, even in working groups I chartered, I can give a > related opinion about this one: > > I do think the background is important to publish separately for this > work, however easy the problem is to describe. I think it's important > that those interested have access to the problem description, reasons > that it wasn't solved in the original DKIM specification > > -- > > > > It's because "replay" is a bogus concept and was discussed and rejected long > ago. There is no solution. "Replay" is just a normal consequence of the email > architecture. > This is just a plea for absolution by senders to send spam with impunity > under the cover of IETF blessing. > > If you don't want a bad reputation for spam, don't sign spam. It's really > that simple. The "replay" problem is a feature, not a bug. DKIM is working as > intended. > I have no sympathy for spam senders. Why should anybody else? Why are we > trying to accommodate sites that send spam? Why are we paying attention to > spam sending sites > and their whining about getting penalized? Spend some money on your spam > filters instead of trying to lobby for a legislative fix to push the problem > onto others. > > There is far too much financial interest going on here at the expense of > ordinary users of email and the profiteers in the industry and their > consultants. Don't send > spam. Spend your money figuring that out. Problem solved.
"Problem solved." As someone who has, as a person running a service with a large number of customers who can send email, ... If you can provide me an accurate definition of spam which is not recipient specific and is actionable, I'd love to see it. Even if we could, theoretically, vet every single customer sufficiently to make sure they're all well behaved people who never send spam, the probability that we can also ensure that their accounts are never compromised, their devices are never compromised, such that they never send anything spammy. It's quite intractable, broad dismissive claims nonwithstanding. 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. </whine> Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd br...@fastmailteam.com
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
