Re: Signing problems with OpenDKIM on Ubuntu

From: Jim Fenton <>
Date: Sat, 20 Apr 2013 15:23:10 -0700

Thanks, SM and Scott. Inline:

On 04/20/2013 12:12 AM, SM wrote:
> Hi Jim,
> At 23:11 19-04-2013, Jim Fenton wrote:
>> 5. Changed Domain to Then I do get messages in
>> syslog, e.g.:
>> Apr 19 22:30:30 kernel opendkim[14486]: r3K5UTNM014503: no signing
>> domain match for ''
>> So it must be intending to sign, but not going through with it.
> OpenDKIM attempted to sign but there wasn't a match for the signing
> domain. That is why the message was not DKIM signed. Are you using
> SigningTable in your configuration.

I wasn't expecting this message to be signed; I messed up Domain in the
config to see if I got an error as expected, and I did. This was mostly
to make sure that opendkim was getting the message in the first place.
I have since changed that back, and now it's not producing the error any

One other interesting result was that with the Domain specification
intentionally misconfigured, it verifies the message. I thought that it
should be signing rather than verifying based on the IP address and/or
MTA specified (as below), but it seems to be making some sort of a
sign/verify decision based on the domain matching or not.

>> Also, I'd like to check my understanding of InternalHosts. Is there a
>> way to always consider a message coming through the submission port
>> (587) to be something to sign rather than verify, regardless of source
>> IP address? How would I specify this, or is it automatic?
> You can do that with the MTA [1] setting in your configuration file.
> Regards,
> -sm
> 1. A set of MTA names (a la the sendmail(8) DaemonPortOptions Name
> parameter) whose mail should be signed by this filter. There is no
> default, meaning MTA name is not considered when making the
> sign-verify decision.

This is very helpful; I didn't see that option. One thing that isn't
clear is what happens if both MTA and InternalHosts is specified; is it
an "or" or an "and" relationship? But it looks like it does the right
thing already, since the OPERATION section of opendkim(8) says that it
signs if the submission of the message was authenticated.

Based on the documentation, I was expecting LogWhy to make logging much
chattier. But I'm not getting any syslog information at all from
opendkim when I send one of these message that I think it should be
signing but isn't.

One other thing I tried was to switch sendmail from the IPv6 family MSA
and MSP (which also speak IPv4) to the IPv4-only flavor, in case there
was some incompatibility there. No difference seen.

Here's my opendkim.conf:

# debugging stuff: log a lot, and try to sign everything
LogWhy yes
# 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

KeyFile /etc/mail/dkim/buttered.key.pem
Selector buttered


# Commonly-used options; the commented-out versions show the defaults.
Canonicalization relaxed
Mode sv
#SubDomains no
#ADSPDiscard no

# 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)


#Accept messages regardless
On-Default accept

Received on Sat Apr 20 2013 - 22:23:08 PST

This archive was generated by hypermail 2.3.0 : Sat Apr 20 2013 - 22:27:02 PST