Murray beat me to this... I think that the purpose of being able to reconstruct and verify messages before modification is to give us the option to be more nuanced than attributing badness to both the original and modifying entity.
This is probably a feature some systems choose to not use, since knowing that B modified the message beyond A's control is sufficient. But this gives an interesting option, where a system can determine what part of the chain added the spammy content and who did not. /E On Tue, Feb 4, 2025 at 7:30 PM Murray S. Kucherawy <superu...@gmail.com> wrote: > On Tue, Feb 4, 2025 at 12:33 PM Dave Crocker <d...@dcrocker.net> wrote: > >> Premise: We have a capability for 'preserving' a DKIM signature, by >> being able to reverse out changes made by mailing lists, and the like. So >> a final receiver's filtering engine can validate the author's originating >> DKIM signature. >> >> The nature of reversing means taking away changes made along the extended >> path. It means that there are portions of the message -- presumably >> including portions of the body -- that are not covered by the original DKIM >> signature. >> >> This opens the door for that mediating platform to add stuff -- outside >> of what is covered by the signature -- that counts as spam or worse. >> >> Presumably, the benefit of recovering the original signature is for the >> purpose of applying that original signer's reputation to the message >> analysis. But there is new content they had nothing to do with. >> >> So at least two items flow from this: >> >> 1. Any site that modifies the substance of a message(*) must add its >> own signature and facilitate determining what the changes are it made. >> 2. Any mechanism that does the desired reversals needs to work across >> a series of changes, so that each change agent can be identified and their >> changes attributed to them. Nested accountability. >> 3. Recipients are still going to blame the original author for the >> problematic content. >> >> OK. Fire away. >> > I'm aware of the rest of the thread, but I wanted to get my thoughts out > before tainting them with other input. Sorry if there's any repetition. > > There's an attraction to the notion of confirming the original signature > somehow. Let's focus on the case where the original signature's domain and > the From domain match. If I can recover the message to the point where > that signature verifies, I know something about the message's true origin. > > Yes, the actual message I have in hand might be spammy now given the > mutations. But I actually have two messages in hand now: (a) the original, > thanks to the mechanism available in your premise, and (b) the final. It > would be easy to compute and express their delta (e.g., a UNIX context > diff) and show the viewing user what parts were added/modified in transit, > marking that stuff somehow so the user can clearly see what changed. For a > legitimate MLM, those mutations won't be surprising, but anything malicious > would also be clearly separate from the original and could be cleaned or at > least subject to additional scrutiny. > > Also if for some reason the message went from A to B to me, and B did > something spammy, but B's signature validates, then I can be sure of what > parts of the message were in the original and which bits were added by B; > an analysis of the delta would let me decide how to adjust B's reputation, > if I'm tracking that sort of thing. > > And being able to recover the original signature greatly increases the > potential for DMARC to do less harm than it does as defined today as it > would significantly decrease at least the false negatives that result from > passage through lists. > > So "yes" to your (1) and (2), but I can do something a little more robust > versus what you claim in (3). > > Of course, all of this is mainly attractive to operators that lack the > benefit of a reputation system and broad visibility into their mail > streams. For instance, if I know where well behaved lists are, the need to > recover the original signature to solve the list transit problem is less > urgent. This sort of capability benefits operators that don't have access > to such data to mine. > > -MSK > _______________________________________________ > Ietf-dkim mailing list -- ietf-dkim@ietf.org > To unsubscribe send an email to ietf-dkim-le...@ietf.org >
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
