1

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 <alice.a@mydomain.com>,
        Bob B-B <b-b@mydomain.com>,
        "'Charlie C'" <charlie@theirdomain.com>

and the actual header cc was reported as:

cc: Alice A <alice.a@mydomain.com>,
        Bob B-B <b-b@mydomain.com>,
        "'Charlie C'"
        <charlie@theirdomain.com>

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 <alice.a@mydomain.com>,
        Bob B-B <b-b@mydomain.com>,
        'Charlie C' <charlie@theirdomain.com>

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.

kubanczyk
  • 13,812
  • 5
  • 41
  • 55

1 Answers1

2

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' <charlie@theirdomain.com> 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 a quoted-string. You should try using double quotes ("Charlie C" <charlie@theirdomain.com>) instead.

Community
  • 1
user228011
  • 226
  • 1
  • 2
  • I'll try to verify whether it's opendkim's bug or other software's. I've confirmed this happens on my infrastructure (outgoing mail is already broken to `"'something'"`). I'll accept your answer in a couple of weeks max. – kubanczyk Feb 11 '16 at 15:50
  • In my case it seems that Sendmail 8.14 rewrites `'sth'` to `"'sth'"` before passing it to the DKIM milter. The respective config is `MustQuoteChars` which defaults to `.'`. Apparently, Gmail rewrites too but after the DKIM test. – xebeche Oct 17 '16 at 12:39
  • @xebeche do you happen to know what you have currently set MustQuoteChars to? = ? – Henk Poley Aug 17 '22 at 11:43
  • @HenkPoley Can't say why or how much I tested it but in 2016 I had changed it from `.'` to `.` and I can't remember I had problems since then. – xebeche Aug 17 '22 at 20:30
  • Ah, I had someone come by that RFC 5322 (from October 2008) defines that the dot also shouldn't be quoted (e.g. `MustQuoteChars=`). Do you expect mailservers to be compatible with this 'new' standard by now? The dot was probably kept 'manually' configured for a long time not to break mail-address autodetection too much. – Henk Poley Aug 19 '22 at 14:17