On Thu, Sep 17, 2026, at 12:08, Emanuel Schorsch wrote: > My main question though is how do you know which part of the content is > malicious? That’s the part that seems non trivial.
You aren't the only person who has raised this. I'm surprised that people stumble on it, because it seems pretty tractable to me. It's RARE that you get two modifications on good mail, so multiple body modifications is already probably a signal to be suspicious. But if you did have modifications on a bad message, then you'd generate each previous instance and feed it into your classifier. Either they're all bad -- case (i) below, or the first bad message is the source of the badness! The one thing that I think would be valuable for clients is a: "this message has altered body content". Particularly if the recipe includes lines which were removed from the other message rather than just wraps - but a legitimate security risk is also a wrapper creating a multipart/alternative which convinces clients to display something totally different rather than the source message. Bron. > Also I realized I forgot to cc the mailing list on my original message. Mind > if I resend it so the convo is on the list? No problem at all. I have CC'd the list with this message. Bron. (rest of thread below) > On Thu, Sep 17, 2026 at 11:31 AM Bron Gondwana <[email protected]> wrote: >> __ >> >> >> On Thu, Sep 17, 2026, at 11:20, Emanuel Schorsch wrote: >>> On Wed, Sep 16, 2026 at 5:14 PM Bron Gondwana >>> <[email protected]> wrote: >>>>> > You can decide to do them synchronously (as we will do probably), >>>>> > asynchronously (e.g. for >>>>> > assessing whose reputation you need to take into account), or not at >>>>> > all. >>>>> The last case places the chain of custody outside verification, which >>>>> returns those properties to trust. >>>>> >>>>> My position is that a one-step rollback to i-1 is sufficient: it detects >>>>> a predecessor that misdeclared its header modifications, and each honest >>>>> hop performing the same check makes the chain self-validating in >>>>> transit, without any node reconstructing the full history. End-to-end >>>>> reconstruction (as advocated on this list) is the expensive path, >>>>> because it requires decoding and holding every recipe in the chain and >>>>> reconciling them together, back to i=1. With tag-value the full >>>>> traversal would be inexpensive either way; the question is what the >>>>> format costs when someone does want it. >>>> >>>> Assuming all hops are honest is a chump's game, see ARC. Every sensible >>>> site is going to follow the same basic pattern I suspect. >>>> >>>> 1) is the content objectionable? >>>> 2a) if not, assume mostly goodness, scan changes for weirdness, deliver to >>>> user. >>>> 2b) if unwanted, figure out who did the bad, and add them to your naughty >>>> list. >>> >>> Hi Bron, can you elaborate on 2B for me. I have been thinking about this >>> because it seems non trivial. “Who did the bad”, how do you know, do you >>> always assume it was the most recent hop that made text changes? Otherwise, >>> if the spam report is for whole thing, how do you know which part was >>> malicious? >> >> The good thing about Message-Instance headers, you can see exactly who made >> which changes. >> >> There's a bunch of possible nonsense which doesn't really make sense, so we >> can ignore it, e.g a message going A => B => C => D where it starts good at >> A, gets turned bad at B, changed AGAIN and made good by C, and you receive >> it at D and it's good. That seems like some bullshit that would never >> happen. >> >> So there's three cases I think really happen. >> >> i) message starts bad >> ii) message starts good, gets turned bad along the way >> iii) message starts good, stays good >> >> Case (ii) is the interesting one for us. That's where somebody changes an >> invoice to have a different bank details, for example. You don't assume >> which hop made the changes, you examine the Message-Instances, and see which >> one changed that line. >> >>> Right now in DKIM1 replay the spammer can’t modify the content and so they >>> can’t inject malicious content into general marketing mail when replaying >>> it. Body recipes change that. A spammer could take any benign domains >>> message, adds a spam link in the body and bulk spam it out. This provides a >>> much stronger incentive than under dkim1. On the plus side the >>> amplification factor would only be as great as the limit enforced by >>> recievers for the messageId. But this would still be a challenge as >>> marketing email is not had to get ones hands on. >> >> Sure, but they spammer would have to sign that change record with their own >> domain - so it would be very clear to everyone receiving the message that >> the spammer domain added the spam link. >> >> The point is - you don't give any reputation to to the benign domain, >> positive or negative, for the content the spammer created - only for the >> content originated by that domain itself. >> >> Bron. >> >> -- >> Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC >> [email protected] >> -- Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
