-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <[email protected]>, Vittorio
<[email protected]> writes
>the current dkim2 specification excludes all X-* headers from the signed
>header set. I would like to propose a refinement.
>X-* headers fall into two categories with different security properties.
you should think more carefully and precisely about what those
properties are since I think two does not cover it
>Vendor diagnostic telemetry (X-MS-*, X-GM-* and similar) is legitimately
>stripped at domain boundaries and should remain excluded.
I don't think many systems strip X- headers .. with the exception of
security systems which remove X- headers on outgoing email in the (vain)
hope of hiding what software is in use.
>Operational
>metadata (antispam scores, authenticated user identities, compliance
>annotations) carries security-relevant information that an attacker can
>inject or manipulate without invalidating the DKIM2 signature under the
>current blanket exclusion.
yes ... but who is relying on an X- header placed into an email anywhere
other than at the previous hop ?
you will note in this context that most of the X- headers placed into
emails by large providers are cryptographically secured (and often
encrypted as well) within the header field itself (this allows
automation of abuse reports, identification of abusive flows &c)
you may believe that you understand the syntax and meaning of headers
written by an entity you have no direct contractual relationship with
but you will, sooner or later, be seriously disappointed.
That's why we use RFCs to document what can be relied upon because
interworking is otherwise impossible at scale
>The proposed change: replace the blanket X-* exclusion with prefix-based
>exclusion. Headers matching well-known vendor diagnostic prefixes are
>excluded.
please provide the exact list you have in mind -- and please indicate
the extent to which you have worked down the list of major email
providers in (for example) CN, IN, ID, RU, SU, CO, BR ...
>All other X-* headers are included in the signed set. The list
>of excluded prefixes SHOULD be operator-configurable.
and how does that interwork ... if I think you should sign X-Vanity1 and
you don't then I am going to reject all your email
>This is documented in more detail in Section 7.5.1 of
>draft-moccia-dkim2-deployment-profile-04 (2026-05-23).
I don't think that is true ... there is no more useful detail there
- --
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBahjTa2HfC/FfW545EQJ0sQCg1zntGCllLdlF3Ij+3HoKIg3jf6sAoIpz
bZIoo+AdzdkwMq3Jg7R/5Cn+
=49GV
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
