On Wed 26/Mar/2025 20:09:33 +0100 Richard Clayton wrote:
In message <ec30d504-c5e8-4742-ad42-2d5f3af1e...@tana.it>, Alessandro Vesely
<ves...@tana.it> writes
On Mon 24/Mar/2025 20:19:29 +0100 Richard Clayton wrote:
Of course, If I trust the signer of the last signature, it would be fine to
check only that. Bat that would be too similar to ARC...
you don't need to trust, you need to validate
Validate must mean to verify every signature until I get to the author.
If you want to do forensics you can check more, but that's all that a
receiver is likely to care about.
It ought to be not very hard to check all signatures, reversing the changes.
It's not a question of hardness -- if you check more signatures than you
need to then you are heating up the planet unnecessarily. Note that you
DO need to reverse changes to check the signature of the original sender
of the email but you can just use the change info without checking if it
is signed (if it doesn't work out then you're back in the world of forensics)
If I trust the change info without verifying the signature, what is my trusting
based upon? Reputation? Agreements?
There needs to be a way to tell what changes are tolerated. For example, I'd
accept a plain text footer of a few lines, but not html inserts that could
completely replace the original content in the end recipient's eyes.
"a way to tell" would be local decisions, not something in the protocol
A careless mailing list operator might just think that HTML footers look nicer.
Then I'll start rejecting their posts because my simple verifier can't judge
the resulting look.
(and see my other message about the very small changes I see that
completely change the meaning of a message to a recipient ... so if you
are very cautious, you might want to have a local policy about angle-
brackets!)
To actively discourage HTML insertion I'd need more than a private policy.
Simple mailing list transformation can be undone even without much change info.
IME, footers are always text/plain. If the changes involve, for example,
rewriting every URL, the receiver needs to deeply trust that forwarded in order
to accept it. They are clearly two different kinds of changes.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
