Summary
Simple Java Mail currently accepts a DKIM header-exclusion setting that lists From. The underlying signer keeps From mandatory and silently ignores that exclusion, so the configuration is misleading rather than effective.
The public DKIM examples made the problem worse: the primary Java example and its property equivalent included From, and enabled the body-length (l=) parameter even though the runtime default is safely false.
Expected behavior
- Reject a case-insensitive
From header exclusion with a clear configuration error.
- Preserve the existing safe runtime defaults: no exclusions,
l= disabled, relaxed canonicalization, and RSA-SHA256.
- Keep other exclusions and
l=true available for explicit interoperability exceptions, with clear documentation of their trade-offs.
- Correct Java, property, Spring-alias, configuration-reference, and migration guidance.
Compatibility impact
Applications that list From among exclusions now fail configuration or message construction instead of silently continuing with From still signed. No valid DKIM signing behavior is removed.
Historical context
- #344 introduced header exclusions for relays that rewrite fields such as
Message-ID and Date; its discussion identifies From as mandatory.
- #499 exposed finer-grained DKIM configuration and changed the
l= default to false in 8.8.0. Its From example was documentation, not a stated interoperability requirement.
- RFC 6376 §5.4 requires the
From header field to be signed.
Acceptance criteria
Summary
Simple Java Mail currently accepts a DKIM header-exclusion setting that lists
From. The underlying signer keepsFrommandatory and silently ignores that exclusion, so the configuration is misleading rather than effective.The public DKIM examples made the problem worse: the primary Java example and its property equivalent included
From, and enabled the body-length (l=) parameter even though the runtime default is safelyfalse.Expected behavior
Fromheader exclusion with a clear configuration error.l=disabled, relaxed canonicalization, and RSA-SHA256.l=trueavailable for explicit interoperability exceptions, with clear documentation of their trade-offs.Compatibility impact
Applications that list
Fromamong exclusions now fail configuration or message construction instead of silently continuing withFromstill signed. No valid DKIM signing behavior is removed.Historical context
Message-IDandDate; its discussion identifiesFromas mandatory.l=default tofalsein 8.8.0. ItsFromexample was documentation, not a stated interoperability requirement.Fromheader field to be signed.Acceptance criteria
Fromis rejected case-insensitively in every DKIM configuration path.Fromexclusions remain supported.l=trueappears only in a clearly labelled advanced exception with its integrity consequence first.Frommust remain signed.