On Sun, Apr 20, 2025, 7:09 a.m. Alessandro Vesely <[email protected]> wrote:
> 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. > 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. 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. 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. > 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:. > 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. Even with the From there would still be a DKIM2 chain, so the value in tracing content back to the system that introduced it is still possible. > > Best > Ale > -- > > > > > > > > _______________________________________________ > Ietf-dkim mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
