Re: all gmail bad signature data

From: <>
Date: Thu, 11 Sep 2014 11:03:46 +1000

hi murray

Murray S. Kucherawy wrote:
> On Wed, 10 Sep 2014, wrote:
> What changes are you making with ReplaceRules? This could be the problem.

actually i don't use it
ive installed directly from the debian jessie repos
i thought that was how it was compiled and with which options ?

>> opendkim[8332]: : [] not internal
> This might be a bug, but not related to verification problems. It looks
> as if postfix is giving us an empty queue ID. I'll have to adjust our
> code to accommodate that.
>> opendkim[8332]: 6956780003A: s=20120113 SSL
>> error:04091068:rsa routines:INT_RSA_VERIFY:bad signature
>> opendkim[8332]: 6956780003A: bad signature data
> This basically means the signature broke. The unfortunate thing is that
> the crypto function that decides this only returns 0 or 1; it doesn't
> tell us what changed.
> I just tried it and signatures pass arriving here, also with
> OpenDKIM 2.9.2, which suggests there's something in your message
> handling setup or your opendkim.conf that might be to blame.
> Can you post your entire configuration, without your private keys? The
> ReplaceRules is the most interesting thing at the moment.

everything added below LogWhy were my additions to the jessie default

for as long as i can remember installing dkim gmail always failed

# This is a basic configuration that can easily be adapted to suit a
# installation. For more advanced options, see opendkim.conf(5) and/or
# /usr/share/doc/opendkim/examples/opendkim.conf.sample.

# Log to syslog
# Syslog yes
# Required to use local socket with MTAs that access the socket as a non-
# privileged user (e.g. Postfix)
# UMask 002

# Sign for with key in /etc/mail/dkim.key using
# selector '2007' (e.g.
KeyFile /etc/opendkim/keys/
Selector mail

# Commonly-used options; the commented-out versions show the defaults.
#Canonicalization simple
#Mode sv
SubDomains no
#ADSPAction continue

# Always oversign From (sign using actual From and a null From to prevent
# malicious signatures header fields (From and/or others) between the signer
# and the verifier. From is oversigned by default in the Debian pacakge
# because it is often the identity key used by reputation systems and thus
# somewhat security sensitive.
OversignHeaders From

# List domains to use for RFC 6541 DKIM Authorized Third-Party Signatures
# (ATPS) (experimental)


AutoRestart Yes
AutoRestartRate 10/1h
UMask 002
Syslog yes
SyslogSuccess Yes
LogWhy Yes

Canonicalization relaxed/simple

ExternalIgnoreList refile:/etc/opendkim/trusted-hosts
InternalHosts refile:/etc/opendkim/trusted-hosts
KeyTable refile:/etc/opendkim/key-table
SigningTable refile:/etc/opendkim/signing-table

Mode sv

PidFile /var/run/opendkim/

SignatureAlgorithm rsa-sha256

UserID opendkim:opendkim

Socket inet:12301_at_localhost

TrustAnchorFile /var/lib/unbound/root.key

AddAllSignatureResults yes

AlwaysAddARHeader yes

SendADSPReports yes

SendReports yes

MilterDebug 3

RequestReports yes


KeepTemporaryFiles yes

TemporaryDirectory /opendkim

BaseDirectory /opendkim

Statistics /opendkim/statistics

On-Default accept

On-BadSignature accept

On-PolicyError accept



Quarantine yes

MTACommand /usr/sbin/sendmail -C /etc/postfix/ -vv -t -f

>> postfix/sendmail[9018]: fatal: No recipient
>> addresses found in message header
> This might be caused by your MTACommand setting, which you said is:
> MTACommand /usr/sbin/sendmail -C /etc/postfix/ -vv -t
> opendkim tries to build a complete command using its own arguments, so
> you should drop from "-vv" to the end and try it again. All it really
> needs to know is the path to the executable and the "-C' argument.

i will try with only -C

> Either way, it's essentially impossible for opendkim to hand it a
> message with no To: field or an empty To: field unless it's crashing.
> (Is it?)

not that im aware of !
nothing seems to suggest it in syslog or otherwise

 opendmarc could, but only if were advertising an
> empty "ruf=" tag in their DMARC record, which they are not.
> -MSK
Received on Thu Sep 11 2014 - 01:04:07 PST

This archive was generated by hypermail 2.3.0 : Thu Sep 11 2014 - 01:09:02 PST