> "with DKIM" is the part of your argument you've failed to back up. Yes, you have a counter-example that requires authenticated emails. You don't have one that requires authenticating emails with DKIM.

That's because we aren't discussing a proposal to switch from DKIM authentication to a different method of authentication. We're discussing a proposal to abandon the partial non-repudiation property that's accidentally provided by DKIM, and replacing it with nothing.

I'd argue that we currently have that "nothing" and are just trying to be explicit about it.

> I'd argue that we currently have that "nothing" and are just trying to be explicit about it.

If you want concrete examples of how the partial non-repudiation property provided by DKIM is not "nothing", you have to look no further than the examples provided in OP.

And yet all of those examples go poof very, very easily, based on something that's not in your control. So yeah, I think they're nothing.

Let me give you a scenario to consider. At my old company, there was a mail server that would DKIM-sign everything that was passed through it. Anybody who wanted to on the internal network could write an email with tampered headers (say, backdated, or "From:" someone else) and send it through this server. This was acceptable because the SOLE PURPOSE of this signing was improving SMTP deliverability. It tells other mail servers "yes, this SMTP payload actually originated from this company. Please do not treat it as spam." So given one of these signed messages, what can you argue about the contents? Nothing, other than "these did not come from a random spammer posing as this company."

You run risks when you assume a signature means something that the signer does not actually intend it to mean.