On Sat 19/Apr/2025 18:51:38 +0200 Allen Robinson wrote:
On Sat, Apr 19, 2025, 9:02 a.m. Alessandro Vesely <[email protected]> wrote:
[...]
* I base64 decoded this MIME part.
* I inserted bytes N-M
* I trimmed the text "foobar" starting at byte N
* I base64 encoded the MIME part
I would prefer to use a class of "good" transformations, such as the subject,
footer, mimeify, add-part and mime-wrap of draft-kucherawy-dkim-transform, and
one "complex" transformation to be defined on a byte-by-byte basis.
[...]
If verifiers can't judge how acceptable a change is, change tracking will be
relegated to forensic analysis. That means we won't be able to distinguish
mailing lists from spammers and replayers, and we won't have solved anything.
I disagree, or maybe I'm working with a different idea of what forensic
analysis means. Doing content filtering at SMTP transaction time based on
the results of authentication checks is certainly possible without the
authentication mechanism being able to decide whether the content is
malicious or not.
"Malicious" is a misnomer here. The characteristic of the "good"
transformations above is that they are attributable to a typical mailing list
transformation; that is, non-invasive and respectful of the original content.
If the verifier can determine this, it can override dmarc=fail.
If the transformation is a complete replacement of the body, a dmarc=fail
deserves to be rejected, according to policy.
For a DKIM2 message with modifications, evaluating the delivered message is
probably sufficient as a first pass, potentially with some metadata about
the modifications (location, edit distance). In the event that the first
pass has some suspicion of being unacceptable, unwinding the modifications
and doing further checks may be necessary to apply checks based on
finer-grained reputation.
What's being solved is not that changes can be classified, but that changes
can be verifiably attributed to the domain performing them.
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.
IMHO, (1) and (2) are not that different, since they both require trusting the
forwarder. This can already be done with DKIM1 or ARC, and experience shows
that ietf.org needs to munge From:.
As for (3), I don't know how to find the right software, and even if I did, my
oldish server wouldn't be powerful enough to run it. So, in any case, ietf.org
would continue to modify From:.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
