What about keeping the DKIM2 exclusion of X- header fields, and standardizing a new prefix for proprietary headers that can be optionally protected? The X- headers, as specified in the DKIM2 spec draft, are ignored by DKIM2 because they are for ephemeral fields generated and used in the ADMD. An optional header field prefix X-lhf- could also be used to protect proprietary header fields across the SMTP boundary. Domains that care can hash those header fields, store them in the DKIM2 header field tag-value upon outbound, and implement a validation method upon inbound. Such a feature would be completely optional in DKIM2 and can be safely ignored if another domain doesn't care. -Wei
On Tue, Jun 9, 2026 at 3:48 PM Vittorio <[email protected]> wrote: > Ross, to clarify: X-MS-, X-GM- and equivalent vendor diagnostic prefixes > were explicitly excluded in the proposal from the start. The suggestion > was to stop excluding all X-* headers indiscriminately. > > Regards > Vittorio Moccia > > Il 2026-06-09 20:00 Ross Adams ha scritto: > > Lots of threads on this and I think I agree with the team that the > > x-* headers are generally specific to the services and in some cases, > > we rename them, replace them etc. which will create a wave of problems > > with the unwinding. I would much rather stick with the general logic > > of not sign the x- headers or have some list somewhere that we have to > > maintain and read to make sure we are handling these headers > > differently. > > > > Keeping this simple seems like the right approach. > > > > Regards, > > > > Ross. > > _______________________________________________ > 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]
