Wei Chuang wrote in <CAAFsWK0hJFRXwCw=mntooo5yb__fr3re+cxqpd2kk95kbvu...@mail.gmail.com>: |On Tue, Feb 4, 2025 at 12:33 PM Dave Crocker <d...@dcrocker.net> wrote: ... |> 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. |> |> I think 1) and 2) are exactly right and email receivers' spam filters can |make use of that more precise attribution information. Each originator or |forwarder has to own the entire message that leaves its system. Forwarders |facilitate reversing their changes to recover any prior hop's message |that can then be verified. To your point below, we might say that |the receiver has some sort of history mechanism where that attribution is |used. 3) is likely true. I've heard that there are ideas around UIs |proposals that might be able to distinguish the different contributions. |-Wei
If it comes to the human behaviour you are at loss anyway, i would think. I had now added multiple "O"rigin flags, so that "anyone who changes MAIL FROM" claims the origin of the message. (A mailing-list, say.) Still, there are elder "origins". (In this case myself.) I would not know what to do, except maybe adding words to hint user interfaces giving extra penalties for any modification other than MIME "additions" -- ie stuff that is appended, ie what *would* be covered by DKIM's l= *if* that would allow the MIME structure changes that can happen by mailing-lists (like wrapping a multipart/alternative into a multipart/mixed in order to be able to append the footer, etc). But for this the parser of the restored differential data needs to be able to analyze and understand MIME content... --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | |In Fall and Winter, feel "The Dropbear Bard"s pint(er). | |The banded bear |without a care, |Banged on himself for e'er and e'er | |Farewell, dear collar bear _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
