Alessandro Vesely wrote in <76cede70-0558-ed62-7420-97e2e899e...@tana.it>: |On Fri 11/Aug/2023 00:33:46 +0200 Steffen Nurpmeso wrote: |> Murray S. Kucherawy wrote in <CAL0qLwaLuNbwbnB4NLrMbqxP=QdiSRvNXVpRjF8P+\ |> dkgjtw...@mail.gmail.com>: |>> On Wed, Aug 9, 2023 at 3:14 PM Steffen Nurpmeso <stef...@sdaoden.eu> \ |>> wrote: |>>> And couldn't it become standardized that verification results then |>>> must be included in future DKIM signatures? |>>> So then a verifier inserts a RFC 7001 header, and that will be |>>> covered by a further DKIM signature. |>> |>> Aren't you basically describing ARC here? |> |> I am only talking DKIM. |> If you DKIM sign a message and have an authentication result |> (made) available (yourself), anything but not including it in your |> own signature seems senseless. | |Indeed, including and signing Authentication-Results is one of the \ |two relevant |differences between DKIM and ARC. The other is chaining existing signat\ |ures. |I don't think considering DKIM plus A-R, that is ARC minus chaining \ |makes any |sense at this point.
To me only relevant is one thing, and i can show you with an ietf.org mail i got from this list (shortened .. of course). So here is an extract of a mail header stack, and when you refer to ARC, i want to make that "stack" bold, as it is how i --- who would rather like email being an endless wrapture of MIME structures to mimic what our forefathers did with their sealed-envelope-in-sealed-envelope etc. --- understand email headers (with some noticeble exceptions like RFC 6783 mailing-list headers, which instead "unshift the stack"): DKIM-Signature: [.] h=In-Reply-To:References:Date:From:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe[.] X-Original-To: ietf-d...@ietfa.amsl.com Delivered-To: ietf-d...@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782ACC1527A6 for <ietf-d...@ietfa.amsl.com>; Thu, 10 Aug 2023 21:14:55 -0700 (PDT) ... Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b="PTllFt48"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="1IRMwJ9b" Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwzGu5MRNMu5 for <ietf-d...@ietfa.amsl.com>; Thu, 10 Aug 2023 21:14:50 -0700 (PDT) I think DKIM underspecifies which headers should be covered by the signature. This is all i want to say. If in this example ietfa.amsl.com spends expensive CPU cycles to generate an authentication result, why is that not covered by the latter generated DKIM signature? (Letting aside that de facto, in this example, ietfa.amsl.com/IPv4 sends to ietfa.amsl.com/IPv6, and both create DKIM signatures from this short glance --- luckily not two Authentication-Results:.) This is especially true for the eventually possible "smart" (heh) DKIM with DKIM-Store, where recipient-domain DKIM implementations would be enabled to verify all message permutations along the way. I have no idea of other aspects of AR©. --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) _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
