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.
|>>> 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.
Nicely said.
|> 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. As in "*if* a A-R was generated,
include it in the DKIM signature".
You know, it really does not matter *to me*.
But if "you" want to "generate reputation" in a completely
automated fashion, then this makes sense:
- Intermediates which modify messages, like mailing-lists, place
original data in a DKIM-Store: (at their position in the email
header stack).
- (Their) DKIM-Signature: includes this DKIM-Store:.
Each SMTP host along the chain to the final recipient can
completely restore all appearances of the message back to its
origin, and verify it to the byte. Together with other data
points of interest like "did ever sent spam" you can automatically
create a picture of sobriety.
This could be used (i am phantasizing) eg to start trusting the
A-R of some host in that, if you see the host while walking the
stack, and it included an A-R, you simply stop verifying, and keep
that A-R "for granted". Only not each 10th, 100th, 1000th
... where you verify yourself again.
This would minimize cost, CPU time, memory, electricity usage etc.
It is naive as it could be a malicious reputation-build-up.
It is dangerous as an attacker could succeed in breaking into the
infrastructure of some "fully trusted" host, and then 999 things
may happen undetected.
A nice Sunday i wish, greetings from Germany.
--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
