libopendkim: accept UTF-8 in header bodies and DKIM-Signature i= values (RFC 8616)#404
Merged
thegushi merged 6 commits intoJun 6, 2026
Conversation
…= values (RFC 8616) dkim_header() rejected any byte > 0x7E in a header field body, making it impossible to sign or verify EAI messages (RFC 6532) whose headers contain UTF-8. Relax the check to allow high bytes; canonicalization already handles non-ASCII octets correctly. dkim_process_set() unconditionally rejected non-ASCII bytes, causing a valid DKIM-Signature with a UTF-8 local-part in i= (permitted by RFC 8616 section 4) to be treated as malformed. Restrict the non-ASCII rejection to tag-name context (states 0-1); allow high bytes through in value context (states 2-3). Add t-test209 and t-test210 to exercise both changes at the library level.
A U-label domain in SigningTable, KeyTable, or Domain will silently fail to produce a signature: the SigningTable ASCIIONLY flag returns not-found without any log output, and DNS lookups for a U-label domain in KeyTable will fail. Emit a LOG_WARNING at the two query sites so operators see actionable guidance rather than unexplained missing signatures.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
dkim_header()rejected any byte > 0x7E in a header field body, making it impossible to sign or verify EAI messages (RFC 6532) whose headers contain UTF-8. Relax the check to allow high bytes; canonicalization already handles non-ASCII octets correctly.dkim_process_set()unconditionally rejected non-ASCII bytes, causing a DKIM-Signature with a UTF-8 local-part ini=(permitted by RFC 8616 section 4) to be treated as malformed. Restrict the non-ASCII rejection to tag-name context (states 0-1); allow high bytes through in value context (states 2-3).t-test209andt-test210to exercise both changes at the library level.No new dependencies.
d=values remain ASCII (A-label), as required by RFC 6376. This change covers the signing/verification path for EAI mail; U-label-to-A-label translation in configuration is out of scope and would require libidn2.Test plan
t-test209passes:dkim_header()returnsDKIM_STAT_OKfor a UTF-8Subject:headert-test210passes:dkim_eoh()returnsDKIM_STAT_OKfor a DKIM-Signature with a UTF-8i=local-part (signature parsed rather than discarded)make checkpasses on Linux CImake checkpasses on FreeBSD (quark)