You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
opendkim errors when DKIM-Signature: headers contain UTF-encoded strings:
May 27 20:40:08 marc1 opendkim[13384]: E5ED79C600B0: syntax error: syntax error in \
signature data (ASCII 0x3d at offset 1)
May 27 20:40:12 marc1 opendkim[13384]: 0C5509C600B0: syntax error: syntax error in \
signature data (ASCII 0x3d at offset 3)
May 27 20:40:35 marc1 opendkim[13384]: 149A89C600B0: syntax error: syntax error in \
signature data (ASCII 0x3d at offset 1)
[3.2]. Tag=Value Lists
DKIM uses a simple "tag=value" syntax in several contexts, including
in messages and domain signature records.
...
INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text" defined
below (as "tag-value") only includes 7-bit characters, an
implementation that wished to anticipate future standards would be
advised not to preclude the use of UTF-8-encoded ([RFC3629]) text
in tag=value lists.
So it would be nice if opendkim supported these, or if not, recognized the =?charset?Q? syntax and gave a more specific error message.
Some quick stats for MARC:
From a corpus of 224,820 emails from the last couple weeks,
240,893 DKIM-Signature: lines (yes some have multi)
Where webkit.org runs off of apple.com mailservers. It seems they started emitting UTF8 DKIM-Signature: values around 2024-05-23, IBM and Oracle both around 2024-05-25, first seen from Meta on 2024-05-27. Common thread, all four use ProofPoint in some way or another (pphosted.com, and/or have X-Proofpoint-... headers). So maybe PP rolled out an update or config change that started doing this.
The text was updated successfully, but these errors were encountered:
As far as I read RFC 2047 and RFC 6376, as a body field of DKIM-Signature: header is not defined as '*text' and does not contain any phrase , encoded-word cannot be used with in it (RFC 2047 section 5 (1)-(3)).
It seems the phrase "UTF-8-encoded([RFC3629])text" in the quote above does not point encoded-word in RFC2047, but points an encoding mapping Unicode character into octet stream.
So I think those DKIM-Signature: headers are broken.
So I think those DKIM-Signature: headers are broken.
They might be, but I think OpenDKIM needs to handle them anyway. ...Do you think we have much chance convincing Apple, Oracle, IBM, Meta to change their ways?
...Do you think we have much chance convincing Apple, Oracle, IBM, Meta to change their ways?
Probably no in directly, but it is enough to reject mails like those if they don't pass domain verification because of those broken DKIM-Signature, regardless of that they really come from those domains or not. webkit.org, ibm.com, meta.com declare DMARC policy as 'reject' and oracle.com does as 'quarantine'. Otherwise what is the mean of existence of RFC standards?
opendkim
errors whenDKIM-Signature:
headers contain UTF-encoded strings:Here's the header from one of those:
I had only noticed plain ASCII
DKIM-Signature:
values, but maybe it's permitted? In https://datatracker.ietf.org/doc/html/rfc6376#section-3.2:So it would be nice if opendkim supported these, or if not, recognized the
=?charset?Q?
syntax and gave a more specific error message.Some quick stats for MARC:
DKIM-Signature:
lines (yes some have multi)=?UTF-8?Q?...
sequencesTop
d=
mentioned:Where
webkit.org
runs off ofapple.com
mailservers. It seems they started emitting UTF8DKIM-Signature:
values around 2024-05-23, IBM and Oracle both around 2024-05-25, first seen from Meta on 2024-05-27. Common thread, all four use ProofPoint in some way or another (pphosted.com
, and/or haveX-Proofpoint-...
headers). So maybe PP rolled out an update or config change that started doing this.The text was updated successfully, but these errors were encountered: