Re: all gmail bad signature data
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
This archive was generated by hypermail 2.3.0
: Thu Sep 11 2014 - 01:09:02 PST