On 7/2/25 12:46 PM, Rich Kulawiec via NANOG wrote:
On Sun, May 25, 2025 at 11:20:16AM +0200, Tom Ivar Helbekkmo via NANOG wrote:
First: SPF/DKIM/DMARC are not about spam, so that part is irrelevant. Perhaps you don't remember this, but when SPF was announced, its home page read:
"Spam as a technical problem is solved by SPF."
Sorry, I don't know about the SPF folks, but nobody that I know of thought that for DKIM, so this just looks like cherry-picking to make a point. That is to say, a strawman.
I've never considered email forgery to be a significant problem -- not when compared to the other problems we face. Huh. Reports of spear-phishing and how easy it was to do scared the hell out of us at Cisco.
But let's put my opinion aside for a moment, and let's presume that email forgery really is a significant problem -- one so serious that it's worth adding an enormous amount of fragile complexity to an ecosystem already under serious stress from spam and other attacks/abuse. Let's assume that it's worth breaking email forwarding (working fine for decades) and mailing lists (working fine for decades, and clearly the best mass collaboration/communication mechanism we have) and adding enormous cost, effort, and complexity to every email system.
DKIM doesn't break forwarding. And it is a *vast* overstatement about "enormous cost". Indeed, compared to all of the other things that happen in the mail pipeline, signing and verifying signatures is completely in the noise, and the complexity is minimal. Mailing lists are a different matter, but the amount of traffic generated by them is a rounding error on the total traffic. Old school geeks care about them, but the rest of the world has moved on.
There's a problem with that: email forgery can't be solved.
If the implication here is that DKIM/SPF claim to "solve" email forgery, that is another strawman. They are tools that can help with various tasks in the email infrastructure, but they alone don't purport to solve the whole problem, since it obviously has human factors considerations which a standards body like IETF doesn't do. Pointing at one mistaken marketing blurb (most likely) from 20 years ago that was taken down as evidence to the contrary is really weak.
Even if if these byzantine hacks [...]
Which "byzantine hacks" might those be? Sorry, I can't go on because I don't even know which windmill you seem to tilting at. I assume it has something to do with SPF/DKIM/DMARC, given the title, but I can't tell for sure. Given the strong smell of straw in the lead up, wading through the rest doesn't seem promising. Mike