On Sat 12/Aug/2023 21:52:13 +0200 Steffen Nurpmeso wrote:
Alessandro Vesely wrote in <f94adbe3-f77f-c8ed-97fd-ea4f9c4f9...@tana.it>:
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.
Indeed, including and signing Authentication-Results is one of the two
relevant differences between DKIM and ARC.
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.
That is not my desire. All i would ask for is that the (older
than ARC) DKIM signature a host generates is used to protect the
A-R that the host generated.
You may encounter a couple of problems signing A-Rs. First, software that
treats those fields probably removes or renames them on ingress, thereby
breaking the signature. To cope with that, you may want to slightly alter the
header field name before signing it. How about Original-Authentication-Results:?
Second, in case of multiple forwards, matching an A-R (or O-A-R) with the
corresponding signature may become hazy. Trace fields are always added at the
top of the header and DKIM signs from the bottom up, but is it safe to rely on
that for attributing reputation? How about adding an explicit index?
That's what I called reinventing.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
