In the long-running battle against a considerable percentage of the DKIM failures for the signatures generated on my servers, I've noted an interesting occurence. Today I've got this DKIM failure report:
User-Agent: OpenDKIM-Filter/2.10.3
Version: 0.1
...
Delivery-Result: other
Feedback-Type: auth-failure
Auth-Failure: signature (signature verification failed)
DKIM-Failure: signature
...
DKIM-Canonicalized-Header: (base64 string)
DKIM-Canonicalized-Body: (another base64 string)
I've noted that DKIM-Canonicalized-Header
contained in turn this:
cc: Alice A <[email protected]>,
Bob B-B <[email protected]>,
"'Charlie C'" <[email protected]>
and the actual header cc
was reported as:
cc: Alice A <[email protected]>,
Bob B-B <[email protected]>,
"'Charlie C'"
<[email protected]>
Luckily enough, I've been able to exactly discover what caused the failure. My signing server retained the temporary file /tmp/dkim.* which says the same header was canonicalized a bit differently:
cc: Alice A <[email protected]>,
Bob B-B <[email protected]>,
'Charlie C' <[email protected]>
Now the fun part. My signing server runs a very similar build (opendkim-2.10.3-1.el6.x86_64.rpm) to the verifying remote server and I've been unable to cause it to repeat this buggy behavior, that is to cause canonicalization "'something'"
. So how could a remote server arrive at such canonicalization? How could the real header (which I don't have archived on my servers), be such a string that it somehow decoded&canonicalized to "'something'"
at the remote server and to 'something'
on my server? Or maybe some additional software tends to alter these quotes during MTA processing? Educated guesses are welcome.
There are two canonicalization algorithms specified in the DKIM specs. The "simple" algorithm doesn't change the header at all, an the "relaxed", besides converting the header field names to lowercase, only affects white space.
Because of this, I find it very unlikely to have something to do with OpenDKIM.
I looked into RFC 5322. Although
'Charlie C' <[email protected]>
seems to be allowed, it is marked as obsolete (following the ABNF:address-list
->address
->mailbox
->name-addr
->display-name
->phrase
->obs-phrase
). That is probably the reason something changes it into aquoted-string
. You should try using double quotes ("Charlie C" <[email protected]>
) instead.