RE: Debugging DKIM verification failures

From: Murray S. Kucherawy <msk_at_cloudmark.com>
Date: Thu, 4 Nov 2010 17:23:02 -0700

> -----Original Message-----
> From: opendkim-users-bounce_at_lists.opendkim.org [mailto:opendkim-users-bounce_at_lists.opendkim.org] On Behalf Of Yang Zhang
> Sent: Thursday, November 04, 2010 4:27 PM
> To: opendkim-users_at_lists.opendkim.org
> Subject: Debugging DKIM verification failures
>
> I'm using opendkim-2.0.2+dfsg-0ubuntu1 with postfix 2.7.0-1 (all from
> apt) on a current Ubuntu 10.04, and I'm getting a bunch of syslog
> messages like the following:
>
> <<<
> opendkim[664]: A522C4E379 s=gamma d=gmail.com SSL error:04077068:rsa
> routines:RSA_verify:bad signature
> ...
> opendkim[664]: CFB494E4B6 s=salesforce.dkim d=salesforce.com SSL
> error:04077068:rsa routines:RSA_verify:bad signature
> ...
> opendkim[664]: B78CF4E88C s=081107 d=returnpath.net SSL
> error:04077068:rsa routines:RSA_verify:bad signature
> >>>

Those all mean the message was signed and all the syntaxes looked valid, and a key was retrieved, but the signature didn't validate. This means the message was altered someplace between signing and verifying. At that point we can't tell you why; all we know is that the RSA_verify() function returned a "false" result.

> opendkim[664]: 7B8C44E4BF smtp.corp.returnpath.net [38.109.196.7] not internal
> opendkim[664]: 7B8C44E4BF not authenticated

These have to do with whether or not the filter will sign the mail. They don't tell you anything about verification failure reasons.

> opendkim[664]: 7B8C44E4BF s=gamma d=gmail.com SSL error:04077068:rsa routines:RSA_verify:bad signature
> opendkim[664]: 7B8C44E4BF: bad signature data
>
> with opendkim outputting 'neutral' this on the corresponding email:
>
> <<<
> Authentication-Results: destination.com; dkim=neutral
> (verification failed; insecure key) header.i=_at_gmail.com;
> dkim-adsp=none (insecure policy)

"dkim=neutral" here means the key was marked as being in test, like so:

% host -t txt gamma._domainkey.gmail.com.
gamma._domainkey.gmail.com descriptive text "k=rsa\; t=y\; p=MIG ..."

Note the "t=y" there.

> Authentication-Results: destination.com; dkim=fail
> (verification failed; insecure key) header.i=_at_returnpath.net;
> dkim-adsp=none (insecure policy)

That one gets "fail" instead of "neutral" because the returnpath.net key doesn't have "t=y" (test mode) in it.

> According to http://tools.ietf.org/html/rfc5451:
>
> <<<
> fail: The message was signed and the signature or signatures were
> acceptable to the verifier, but they failed the verification
> test(s).
>
> neutral: The message was signed but the signature or signatures
> contained syntax errors or were not otherwise able to be
> processed. This result SHOULD also be used for other failures not
> covered elsewhere in this list.
> >>>
>
> Shouldn't both examples above have resulted in neutral, given that
> both had what opendkim identifies as bad signatures?

"neutral" is used here in accordance with the last sentence in that definition.

> Why is the gmail-via-returnpath email getting a bad signature, when
> emails directly from gmail are getting verified fine? (The
> gmail-produced DKIM-Signatures seem formatted identically in both.)

Something in the path between the signer and the verifier (you) is altering the message in a way that invalidates the signature.

> Are there simple ways I can verify independently or manually that the
> signatures are bad (e.g. on the command line)?

opendkim has a "-t" flag you can use to feed input to it from an input file and observe the results. See the opendkim(8) man page for details.

> Or otherwise gather
> more information on what precisely is bad about the signatures?

There are several features you can use, but the more useful they are, the more they also require participation from the signer. I don't think you're going to get Gmail to change their signing format, so you might need to check out other options.

The filter has two diagnostic features you can try:

- set TempDirectory to some directory to which the filter process has write access (defaults to /var/tmp)
- set KeepTemporaryFiles to "True"
- restart the filter
- send mail to yourself so that it will be returned to you through that returnpath.net route

When it comes back to you, you'll see there are four files in that directory. (Maybe others if there's other mail flying around too; if so, find the four you need.) Two will represent the message when it was sent (header and body) and two will represent the message you received. A "diff" of the two pairs should reveal how it was altered such that the signature was rendered invalid. If there's no difference at all, the signature should have passed.

You can also look at the "Diagnostic" and "DiagnosticDirectory" settings, which do something similar but a slightly different way (i.e. using "z=" tags).

There's some additional discussion of debugging verification failures in opendkim/README in the source tarball.

> As another data point, I tried another DKIM implementation
> (http://hewgill.com/pydkim/), and while it doesn't complain about the
> signatures being bad (it might just be incapable of doing that), it
> also fails the gmail-via-returnpath example and the returnpath
> example, while passing the gmail example. I'm mainly wondering if
> there's something I'm misconfiguring either in Postfix or in OpenDKIM
> that may be causing this mayhem.

Doesn't sound like it to me. The evidence points pretty strongly at some issue in the "via returnpath.net" message handling, since gmail.com signatures verify when they go directly.

-MSK
Received on Fri Nov 05 2010 - 00:23:14 PST

This archive was generated by hypermail 2.3.0 : Mon Oct 29 2012 - 23:19:49 PST