On Thu, Nov 5, 2026 at 1:44 AM Vittorio <[email protected]> wrote: > Pietro, Emanuel, Wei, > > Pietro's distinction between verifying that a modification occurred and > establishing that the owner of the original From domain authorized it is > the right place to look. > > With recipes the signature of the original domain is verified against > the header fields and the body it signed, rebuilt from the ones > delivered, so the message keeps a pass in that domain's name over a > state that is not the state delivered. This holds whenever > reconstruction succeeds, which is the normal case. >
I agree that giving senders control over the identity they assume during forwarding modification is helpful. It's very likely that in general government e.g. IRS and financial senders are likely much more restrictive about the identities they assume than typical consumer mailbox users. > Emanuel's second concern already shows why a message-level flag cannot > bound that pass. What an attacker needs is not the content of a message > but a valid signature from a domain worth impersonating. Any recipient > of such a message can rewrite the body and the subject with recipes > while leaving the From untouched, so the message a sender judges > harmless enough to mark okaytomodify is exactly the one that hands over > its domain's authenticated identity. A flag of the donotmodify kind is > in any case a request that any hop on the path can ignore and whose > effect is whatever each receiver decides. Its inverse okaytomodify > inherits the same property. > I differ here. While generally restrictive, those government or financial senders are not monolithic. They have corporate mail traffic that, AFAIK, uses mailing lists and sender and security gateways. My guess is that they may feel tolerating message modifications is more important as long as that traffic stays within their trusted corporate environment. When traffic goes outside, they will likely want to be more restrictive about content modifications to messages identified as coming from their domain. Hence I think a per message flag is more useful because it allows that hybrid traffic to co-exist in the same domain. -Wei > The Domain Policy Record of draft-ietf-dkim-dkim2-dns-03 shows what a > DNS-published restriction can do. Its strict flag withholds from > subdomains the authorization to make a From in the parent domain > Authentic and it is opt-in, because the default authorizes them. > Withholding authorization from modifications is a different matter. A > record that did so would bring back through DNS the DMARC failures on > mailing list traffic that DKIM2 is meant to end, as Pietro himself > notes. > > In my view each pass should be tied to the intermediary at the hop it > refers to. A change to the header fields at a hop can significantly > affect how the message is attributed and disposed of. A change to its > content is attested by a hash, unless its forensic reconstruction is > required through a body recipe. What a node signs attests the passage of > the message through that node: on one side its own verification of what > it received, on the other the sealed attestation and attribution of the > changes it made. No claim can stand that a pass for the original From > attests what that domain never signed. Changes are attested by the nodes > that make them. > > Regards, > Vittorio Moccia > _______________________________________________ > 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]
