gmail dkim=neutral (no signature)

Question

After testing much and retracing my steps, I still cannot get google mail to validate.

My mail server is Debian 5.0 with exim

Exim version 4.72 #1 built 31-Jul-2010 08:12:17
Copyright (c) University of Cambridge, 1995 - 2007
Berkeley DB: Berkeley DB 4.8.24: (August 14, 2009)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS move_frozen_messages Content_Scanning DKIM Old_Demime
Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite
Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
GnuTLS compile-time version: 2.4.2
GnuTLS runtime version: 2.4.2
Configuration file is /var/lib/exim4/config.autogenerated

My remote smtp transport configuration:

remote_smtp:
  debug_print = "T: remote_smtp for $local_part@$domain"
  driver = smtp
  helo_data = mailer.mydomain.com
  dkim_domain = mydomain.com
  dkim_selector = mailer
  dkim_private_key = /etc/exim4/dkim/mailer.mydomain.com.key
  dkim_canon = relaxed

.ifdef REMOTE_SMTP_HOSTS_AVOID_TLS
  hosts_avoid_tls = REMOTE_SMTP_HOSTS_AVOID_TLS
.endif
.ifdef REMOTE_SMTP_HEADERS_REWRITE
  headers_rewrite = REMOTE_SMTP_HEADERS_REWRITE
.endif
.ifdef REMOTE_SMTP_RETURN_PATH
  return_path = REMOTE_SMTP_RETURN_PATH
.endif
.ifdef REMOTE_SMTP_HELO_FROM_DNS
  helo_data=REMOTE_SMTP_HELO_DATA
.endif

The path to my private key is correct.

I see a DKIM header in my messages as they end up in my gmail account:

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mydomain.com; s=mailer;
    h=Content-Type:MIME-Version:Message-ID:Date:Subject:Reply-To:To:From; bh=nKgQAFyGv<snip>tg=;
    b=m84lyYvX6<snip>RBBqmW52m1ce2g=;

However, gmail headers always report dkim=neutral (no signature):

dkim=neutral (no signature) [email protected]

My DNS results:

dig +short txt mailer._domainkey.mydomain.com
mailer._domainkey. mydomain.com descriptive text "v=DKIM1\; k=rsa\; t=y\; p=LS0tLS1CRUdJ<snip>M0RRRUJBUVV" "BQTRHTkFEQ0J<snip>GdLamdaaG" "JwaFZkai93b3<snip>laSCtCYmdsYlBrWkdqeVExN3gxN" "mpQTzF6OWJDN3hoY21LNFhaR0NjeENMR0FmOWI4Z<snip>tLQo="

Note that the base64 public key is 364 chars long so I had to break up the key using bind9.

$ORIGIN _domainkey. mydomain.com.
mailer                  TXT     ("v=DKIM1; k=rsa; t=y; p=LS0tLS1CRUdJTiBQVUJM<snip>U0liM0RRRUJBUVV"
                                "BQTRHTkFEQ0JpUUtCZ1<snip>15MGdLamdaaG"
                                "JwaFZkai93b3lDK21MR<snip>YlBrWkdqeVExN3gxN"
                                "mpQTzF6OWJDN3hoY21L<snip>Ci0tLS0tRU5E"
                                "IFBVQkxJQyBLRVktLS0tLQo=")

Can anyone point me in the right direction? I would really appreciate it.

Solution 1

Don't break the key. Just add it as a single string. It will wordwrap in most editors. My key looks like the following.

rsa1._domainkey                 IN      TXT     "v=DKIM1; t=s; p=MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKq2Ul9a5ixDPQm9WMoPI9fUEZU8FZwfux/O9Sl5+GDCR4rt0CsBzyZj4PY5DTtVHix++EZkR5rVdM4W59DtweKCK6XVntq4Y4GSm+gfZkf/fq45BSCQNilbYux4xqsHQIDAQAB"

I don't believe DKIM supports reassembling strings. If you are using a multi-line format verify it is reassembled into one piece. If it is served with the extra quotes, it will likely break. Your DNS lookup shows that this is the case.

All to often I see SPF records showing up as "v=spf1" "a" "-all", which is read as vspf1a-all. This record should be delivered as v=spf1 a -all but would work as "v=spf1 " "a " "-all". SPF does specify support for quoted parts by concatenates the parts as is without introducing extra spaces. This allows lines to be broken mid-word.

EDIT: I am testing using a key formatted in multiple strings. However, I will need to wait until DNS updates. [email protected] tells me my new key does not exist.

The format I get from bind does not match the format the documentation leads me to believe I should get. The documentation indicates that I should see a single string concatenating the fragments I entered. Instead I see the fragments as entered in the zone file.

Testing with bind indicates the text fragments can be as large as 255 characters. Anything over that needs to be split. In any case two such fragments will likely exceed the capacity of a UPD packet.

A review of the RFC indicates a 2048 bit key size is likely the practical limit. There is a warning to implementers that the may have to deal with TXT fragments and reassemble them in order.

Solution 2

You obfuscate data which is public anyway, which doesn't help us help you.

Eg, we can't check to make sure that you updated the SOA serial number and that the change made it out to all the NS servers and that this was done with a negative TTL in the SOA low enough that Gmail's not reasonably seeing no data.

Using multiple "..." sequences in DNS TXT records does not combine into one string, it provides multiple strings. It's then up to the application / protocol / specification to say how to deal with the strings; eg "join with space between them", "directly join", "only use first".

The DKIM spec says to join directly, but this is directly into the sort of area which tends to get overlooked by implementors. I encourage you to provide one string as the only string within the TXT record and see if that changes things.

I use Exim with DKIM and Gmail always validates it; your Exim configuration is correct. So either your DNS isn't visible or Gmail dislikes the multiple strings in the TXT record.

You can also try some of the DKIM test services:

• Sender Auth Test Service <[email protected]>
• [email protected]
• The three addresses at: http://www.port25.com/domainkeys/

Comments

[Buzzwilder]

Was able to get this working after building a smaller key that does not make my TXT record longer than 255 chars. I followed the instructions at systemajik.com/blog/implementing-dkim-with-exim

[Buzzwilder]

Yeah, there's no need for obfuscation than perhaps public humiliation. :) Thanks for your answer. How do you get around the bind error? named-checkzone olwm.com olwm.com.zone dns_rdata_fromtext: olwm.com.zone:31: ran out of space zone olwm.com/IN: loading from master file olwm.com.zone failed: ran out of space zone olwm.com/IN: not loaded due to errors.

[Buzzwilder]

I snipped the key because it's very long. In your example, is that a real public key, and if so, how many bits?

[Phil P]

Find the line with unbalanced double-quotes; probably around line 31. Fix it, so that bind can load the zone. Gmail should then see the new data, not the last data which successfully loaded into your nameserver and verification should work.