#233 Inconsistent or invalid `Authentication-Results` headers
OpenDKIM can produce inconsistent Authentication-Results headers in the header.b field. When there are two preceeding DKIM-Signature headers OpenDKIM will copy only the first 8 bytes of the header.b in Authentication-Results if the DKIM-Signature headers differ but will copy the entire 174 bytes if they are the same. Note, that the DKIM-Signature headers can differ when the time changes. For example:
Authentication-Results: cauldrondevelopment.com;
dkim=pass (1024-bit key) header.d=cauldrondevelopment.com header.i=@cauldrondevelopment.com header.b=Zcq7EP68;
dkim=pass (1024-bit key) header.d=cauldrondevelopment.com header.i=@cauldrondevelopment.com header.b=M5Gfb4ll
vs.
Authentication-Results: cauldrondevelopment.com;
dkim=pass (1024-bit key) header.d=cauldrondevelopment.com header.i=@cauldrondevelopment.com header.b=qJVneN34hw2tMOy6++jymzgWxLStNSFp5jsZq6CX5JRYQL9H2nCxmAPwUa/tN2nK2NdaWbfnzlYYLJ6Mrdg3iDvBPmyY6b6IimgPnNnyrB9l1UFZX05xlJJvHPBOx0PFMgkUhMY8zADwTZY1nEXqCs2foIKhlfQF2DBFEOlPIAE=;
dkim=pass (1024-bit key) header.d=cauldrondevelopment.com header.i=@cauldrondevelopment.com header.b=qJVneN34hw2tMOy6++jymzgWxLStNSFp5jsZq6CX5JRYQL9H2nCxmAPwUa/tN2nK2NdaWbfnzlYYLJ6Mrdg3iDvBPmyY6b6IimgPnNnyrB9l1UFZX05xlJJvHPBOx0PFMgkUhMY8zADwTZY1nEXqCs2foIKhlfQF2DBFEOlPIAE=
Both 2.9.2 and 2.10.3 have this inconsistency. I'm not sure which behavior is correct but OpenDMARC chokes on the longer headers. OpenDMARC may be at fault but I belive it is an error that OpenDKIM produces inconsistent headers.
The attached files show complete mail headers for both OpenDKIM versions. Note, that pass/fail in the file names refers to OpenDMARC.
The attached email headers from messages which I sent from my server to a GMail account which was configured to forward them back to the original server. So they are making a round trip.
Here's a patch which fixes the problem. Note, that I modified test137 where it checks for a length of 10 from
dkim_get_sigsubstring().dkim_get_sigsubstring()now always returns an 8 byte string.If by some chance two signatures are the same within the first eight bytes of the text version of the hash, we get a result collision; the caller can't tell two which signature the result applies.
I think the short cut here is that if the strings are the same all the way to the end, fall back to the minimum, but otherwise keep the current logic.
You should open a bug against OpenDMARC if the produced A-R fields cause it to fail.
As for OpenDKIM, I suggest that it's actually acting properly in response to that strange input. There's no legitimate reason for the very same DKIM-Signature to appear twice, but at any rate, OpenDKIM has no duplicate signature detection so it correctly determines that the only possibility to disambiguate the results two signatures is to include the entire "b=" value.
The simplest fix is to notice that the two signatures are the same and not bother trying to find a shortest match. That'll be in the next release.
That sounds like the right solution. I opened a OpenDKIM bug report as well. Thanks!