Open hlein opened 2 months ago
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.