Rob Sayre wrote in <CAChr6SyBQCZ4P8QGczG9w88CpwObRVKAsLQ4HUYuTEvtpf2QqA@xxxxxxxxxxxxxx>: |On Wed, Mar 26, 2025 at 4:36 PM John R. Levine <johnl@xxxxxxxx> wrote: |> On Wed, 26 Mar 2025, Rob Sayre wrote: |>> On Wed, Mar 26, 2025 at 4:01 PM John R. Levine <johnl@xxxxxxxx> wrote: |>> |>>> signing as good guys, perhaps better. DKIM doesn't belong in this part |> of |>>> the A/S and I don't think it belongs in the A/S at all. |>> |>> It's in rfc5321bis, not the A/S: |>> |> https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-rfc5321bis-42\ |> #section-7.1 |> |> Oh, right. DKIM doesn't belong there either. | |I write this as a disinterested party. I don't get it. We have a Here i agree. DKIM cryptographically verifiable bundles at least the original message and the sender domain. Potentially this is true for all hops a message passes. With an iterated DKIM it gets even better, as SMTP envelope data is included in the verifiability (in at least the direct route of hops from sender to receiver), and that hardens SMTP as such. |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? And with the iterated DKIM it gets even better. (If DKIMACDC would be selected as DKIM2 the d= of RFC 6376 remains exactly the same. Like anything else of 6376. Ie, all the configurations in use remain intact, and a hop can place multiple d= to create relations. Dunno what the other DKIM2 does.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
