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]
