On 27/09/2026 4:16 am, Richard Clayton wrote:
I think that there is (a) a strong case for removing "donotmodify" from
the DKIM2 spec itself and -- simultaneously -- (b) a strong case for
senders to be able to signal that they think that intermediaries should
not make particular types of change to their email (and if they feel
that it unacceptable, that they should reject the email).
Since some modifications are more benign than others there is a case for
attempting to define a new LimitModification: header field (the header
field name is a strawman) for discussion.
I would broadly support the idea of allowing senders to explicitly allow
modifications if it extended to restricting such modifications to
designated domains. This addresses the issue with marketing platforms in
particular needing to have keys for the customer's domain in order to
insert tracking links, as they could explicitly be permitted to make
changes.
Only allowing specific domains to modify e-mail and limiting those
modifications would be a reasonable compromise that might reduce some of
the opposition to the current proposals, while preserve some degree of
implementation flexibility.
Continuation of transit for mailing lists that modify, would require the
sender to identify lists and approve changes based on recipient
addresses. This could be manually managed by senders or automated by way
of an RBL-like registry of reputable mailing lists or other means.
Regards,
R. Latimer
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
