Hi, I have a "simple" question:
Why should an intermediary that has not been authorized by either the sender (e.g., an authorized outbound gateway) or the recipient (e.g., a recipient-controlled security gateway) be allowed to modify a message while preserving an authentication result attributed to the original From domain for the modified, delivered content? A recipient may choose to trust its own intermediaries and accept their modifications. That is entirely legitimate. But such local trust should not be confused with authorization from the original sender, nor should it imply that the original domain authenticated content modified by an unrelated third party. IMHO an unknown or unauthorized intermediary should not receive the same treatment as a gateway explicitly trusted by the sender or the recipient. Pietro -----Messaggio originale----- Da: Vittorio <[email protected]> Inviato: venerdì 6 novembre 2026 21:19 A: Ietf Dkim <[email protected]> Oggetto: [Ietf-dkim] Re: R: Re: DKIM2 / DMARC Sender Policy Proposal Hello Wei, Il 2026-11-06 07:50 Wei Chuang ha scritto: >> 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. A clarification first. My point was not that senders should control the identity they assume during forwarding. My position is the opposite: the forwarder signs as itself and the change it makes is attested in its own name, so there is no identity for the original domain to grant or withhold. What that domain needs is not a permission it issues but the assurance that no change made by someone else is attested in its name. >> 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. The observation that these domains are not monolithic is right and the two kinds of traffic you describe do travel under one name. Inside the corporate environment the node that modifies the message is the domain itself. Its own gateways and list managers can sign the modified message under the same domain, wherever they run, since what signing requires is access to a key for that domain and not a particular position in the path. The domain then answers for its own changes and has nothing to authorize. This covers delegation too. Where the list manager or the gateway is run by a vendor, the domain can delegate a selector to it and the vendor signs under the domain's own name. That is a domain-level arrangement, made once, and it needs no per-message signal. Outside that environment the flag does not protect the domain. Whoever receives any message signed by the domain can rewrite its body and subject with recipes, keep the From and send it on. The result still passes in the domain's name. The sender marks the messages it considers sensitive, but the attacker uses one of the others, as Emanuel noted for okaytomodify. On the marked ones the flag is still only a request that each receiver may or may not honor. So the per-message flag is not needed inside the environment and it doesn't seem to me that protect the domain outside it. Regards, Vittorio Moccia _______________________________________________ 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/4jLr9y39k3zGxSb/report-as-bad _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
