On Wed, Mar 26, 2025 at 5:00 PM Rob Sayre <sayrer@xxxxxxxxx> wrote:
On Wed, Mar 26, 2025 at 4:47 PM John Levine <johnl@xxxxxxxxx> wrote:It appears that Rob Sayre <sayrer@xxxxxxxxx> said:
>I write this as a disinterested party. I don't get it. We have a
>standards-track RFC:
>https://datatracker.ietf.org/doc/html/rfc6376
>
>RFC 5321 and RFC 5322 are normative references. Why cite PGP and S/MIME but
>not this one?
Please reread Dave's and my messages. They don't do even sort of
the same thing.I read them. Ekr offered concrete text that those messages did not address.I agree that it's not the same thing. On the other hand, people use it, in contrast to PGP and S/MIME.
I think "people" is the interesting word here. People sign with these technologies. Domains sign with DKIM. This is an important difference in that you are unlikely to sign spam or malware with your own personal keys, but at large scales, domain operators are tricked into DKIM-signing spam or malware all the time. The DKIM WG has rechartered to try to tackle these sorts of problems, but whatever comes out of that is likely to be a new technology rather than extensions to DKIM.
Message-level authentication systems like DKIM, SPF, DMARC, etc., have not, in my opinion, managed to provide the kind of protection that we'd originally hoped they could. They're functional building blocks to a solution that hasn't yet materialized. But the industry is coming to want them more and more anyway, in the sense that encouraging use of the building blocks is better than nothing.
That DKIM achieved Internet Standards status is only a testament to its interoperability and apparent broad use. That doesn't mean it's a complete solution to email security that this body should mandate.
-MSK
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
