Re: all gmail bad signature data

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

hi murray


Murray S. Kucherawy wrote:
> On Wed, 10 Sep 2014, shmick_at_riseup.net wrote:
>> _FFR_REPLACE_RULES
>
> 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]: : mail-qc0-f202.google.com [209.85.216.202] 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 d=google.com 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 gmail.com 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
standard
# 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 example.com with key in /etc/mail/dkim.key using
# selector '2007' (e.g. 2007._domainkey.example.com)
Domain example.net
KeyFile /etc/opendkim/keys/example.net/mail.private
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)

#ATPSDomains example.com

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/opendkim.pid

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

AuthservID ns1.example.net

KeepTemporaryFiles yes

TemporaryDirectory /opendkim

BaseDirectory /opendkim

Statistics /opendkim/statistics

On-Default accept

On-BadSignature accept

On-PolicyError accept

RedirectFailuresTo postmaster_at_example.net

ReportBccAddress postmaster_at_example.net

Quarantine yes

MTACommand /usr/sbin/sendmail -C /etc/postfix/main.cf -vv -t -f
postmaster_at_example.net

>
>> postfix/sendmail[9018]: fatal: postmaster_at_example.net(123): 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/main.cf -vv -t
> -fpostmaster_at_example.net
>
> 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 gmail.com 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