On Fri 11/Aug/2023 23:49:20 +0200 Steffen Nurpmeso wrote:
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?
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
signatures. >
[...]
I think DKIM underspecifies which headers should be covered by the
signature. This is all i want to say.
DKIM is very flexible by design.
If in this [elided] example ietfa.amsl.com spends expensive CPU cycles to
generate an authentication result, why is that not covered by the latter
generated DKIM signature?
Because A-R fields were conceived for internal consumption. Bastion hosts are
supposed to remove or rename existing A-R fields while they add their own ones,
so that downstream filtering modules can trustfully utilize the A-Rs they see.
The consideration you make, that A-Rs by a trusted forwarder can actually be
useful came later. Some experimented with Original-A-R fields. Then the idea
of DKIM-signing that stuff emerged, was discussed and resulted in ARC. It is a
perfect tool for trusted forwarding.
Reinventing it is not necessary.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
