Hi all, I've been thinking a little more about the donotmodify discussion, especially Bron's invoice example, and I am starting to wonder whether we may be making this more complicated than necessary. Perhaps the more fundamental question is: why would a Domain Owner want an intermediary in transit to be allowed to modify the body of a message while that message continues to represent the original domain? I can understand modifications made within the sender's own infrastructure. For example, a corporate security gateway may add a disclaimer or otherwise modify the message before it actually leaves the organization. But in that case I would expect the modification to happen before the message is finally signed as i=1, with the gateway signing on behalf of the sender's domain. I can also understand modifications at the receiving side. A receiving security gateway may remove malicious content, sanitize a message, or perform some other destructive operation. But in that case the receiver has explicitly chosen and trusted that system, and can make a local policy decision to accept modifications made by it. In some sense, the receiving ADMD is taking responsibility for allowing that exception.
What I find harder to identify, and this may simply be because I am missing something here or not fully understanding some relevant use case, is the case in the middle: A -> B -> C -> Receiver From: A A signs i=1 B or C modifies the body message still represents A DKIM2 can of course authenticate that modification and tell the receiver who made it. That is extremely useful, but it does not by itself explain why A should be expected to accept arbitrary body modifications by intermediaries. This makes me wonder whether a simpler model would be a domain-wide sender policy saying, conceptually: Messages representing this domain must not have their body modified in transit, except by systems explicitly authorized by the receiving ADMD. DKIM2 would still do what it does best: record and authenticate what happened. If B modifies the body and signs the modification, the chain can remain perfectly valid and the receiver can see exactly what B changed. The separate policy layer can then determine whether that modification was acceptable. If the modification happens inside the sender's infrastructure, it can happen before i=1. If it happens inside the receiver's infrastructure, the receiver can explicitly authorize it by local policy. If an intermediary needs to make a destructive change that no longer preserves the original message/history, then I would expect that to become a re-originated message, with a new i=1 and the corresponding From/domain relationship. This seems simpler to me than having the sender express modification constraints separately for individual messages, unless there are real use cases where a Domain Owner actually wants intermediaries to be able to modify the body while the message continues to represent that domain. So I would be very interested in concrete examples of that case. What legitimate mail flow requires a third-party intermediary, which is neither acting on behalf of the sender before i=1 nor explicitly authorized by the receiving ADMD, to modify the body while preserving the original From identity? If there are common cases like this, then I agree that we need the additional flexibility. But if we cannot identify them, perhaps a domain-wide policy is both easier to understand and easier to enforce. Pietro -----Messaggio originale----- Da: Richard Clayton <[email protected]> Inviato: domenica 20 settembre 2026 17:11 A: [email protected] Oggetto: [Ietf-dkim] Re: Insisting that From is authentic -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <[email protected]>, Pete Resnick <[email protected]> writes >[Without my chair hat on. This is basically a technical comment, but I >do think this framing will get it through the process a bit easier.] > >On 31 Aug 2026, at 9:32, Richard Clayton wrote: > >> We update the spec to say that when a From field is first placed into >> a message (ie it sits alongside an i=1 DKIM2-Signature) or when it is >> changed by an intermediary (there is a recipe that shows that it has >> been changed at a particular hop) then DKIM2 will insist that there >> is match between the d= domain being used to sign and the domain in >> the >> RFC5322 From header field. > >If the group wants to go down this path (and it's sounding like it >does), I would very much suggest that the requirement gets put on the >generator and not on the interpreter: by which I assume you mean "Verifier" >Make the requirement that the >domain in the From: header field MUST sign the message. Then we don't >get into the business of telling receivers what they need to do with >the message. we could do this by making the requirement on a Verifier that they MAY reject the message and MUST NOT forward it outside their org. That way we have a place to specify a canonical rejection message (which assists with interworking / debugging etc) >Note that this is an explicit change from DKIM1: In DKIM1, but not from DMARC ... > the semantic >content of the message was explicitly ignored; the only thing it told >you is that some domain signed the message, and it acted strictly at >the SMTP layer. If we go down this path, in DKIM2 we would be saying >that the signature (or at least one signature) depends on the x22 >content of the message. I'm not saying that's wrong; I'm simply saying >that we should be explicit about that in the document if this is the >path we choose. ... and it is not a change from what pretty much all email with DKIM1 signatures does today; viz: this is going to actually affect almost no- one apart perhaps from really old systems which are not DKIM1 signing today -- if they are authenticating at all it is by using SPF - -- richard @ highwayman . com "Nothing seems the same Still you never see the change from day to day And no-one notices the customs slip away" -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBaq/3bWHfC/FfW545EQLExgCguJLQH30VBzlicofZpSy3WgPJ+kEAoNHl 9IirxRg1Wvulr629RllIdasl =3kgV -----END PGP SIGNATURE----- _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected] -- Questo messaggio e' stato analizzato con Libraesva ESG ed e' risultato non infetto. Seguire il link qui sotto per segnalarlo come spam: https://mail2.mcnsrl.it/action/4hnqbt3bh0zGptN/report-as-bad _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
