On Sun 20/Apr/2025 17:42:58 +0200 Allen Robinson wrote:
On Sun, Apr 20, 2025, 7:09 a.m. Alessandro Vesely <[email protected]> wrote:
In practice, what should I do in such a scenario when I receive a message From:
[email protected] whose author domain signature is not verified because the
message has been modified, considering that google.com has p=reject?
1) I accept because I trust the verified signature of ietf.org,
2) I undo the changes made by ietf.org, check that the original signature then
verifies and pass the message because I trust that the changes made by ietf.org
are acceptable, or
3) as in (2) but, instead of trusting, I implement an AI visual engine to
determine whether the final appearance is still consistent with the original
message.
I'd propose 2b) instead of trusting ietf.org, you evaluate the changes
performed to determine whether they are acceptable for the purposes of
allowing DKIM2 to satisfy the requirements of DMARC authentication.
That's also what I'd like.
I do not have a strong position for what this looks like yet, and I could
see the DMARC decision being that only a subset of DKIM2's modifications
are acceptable, but I don't think that means only DMARC-compatible
modification can be supported in DKIM2.
There's no DMARC-compatible transformation. DMARC reporting provides a
"mailing_list" policy override type, which is described as "local heuristic".
DKIM2 could standardize that concept.
Or maybe that's what you meant by 3 but immediately jumped to the most
expensive possible implementation. HTML rendering has been done without AI
for decades. Text rendering even longer than that.
My point is that a simple algorithm cannot determine whether a change respects
the original message. What can be done is to categorize the transformations
actually performed by (user respecting) mailing lists. If the design of the
modification algebra already recognizes the category, the task of the verifier
will be much easier.
[...]
This was one of the motivations for having some sort of mechanism by which
domains could declare support for DKIM2. A DKIM2 mailing list system that's
sending towards another DKIM2 system would be able to skip DMARC-mandated
From rewriting (assuming we figure out how to make that work) but would
need to continue to do From rewriting for other systems. Without that, yes,
mailing lists likely can't stop rewriting From.
A rude method, using Mailman, could be to setup an umbrella list with two
sibling sub-lists, one configured with From: munging, the other one without.
(Both sub-lists refuse all posts, and advertise the umbrella list as the post
address. The umbrella list accepts posts according to site and list policy. It
has the sibling sub-lists as its only subscribers, and won't accept more.)
Initially, all are in the first sub-list. Then, periodically try and send to
each subscriber a test message from a domain that publishes p=reject. Until it
bounces, keep the subscriber in the first list.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
