Re: Signing problems with OpenDKIM on Ubuntu

From: Scott Kitterman <ietf-dkim_at_kitterman.com>
Date: Sat, 20 Apr 2013 18:42:21 -0400

On Saturday, April 20, 2013 03:23:10 PM Jim Fenton wrote:
> 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 xbluepopcorn.net. Then I do get messages in
> >> syslog, e.g.:
> >> Apr 19 22:30:30 kernel opendkim[14486]: r3K5UTNM014503: no signing
> >> domain match for 'bluepopcorn.net'
> >>
> >> 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
> more.
>
> 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
> InternalHosts 0.0.0.0/0
> # 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
>
> Domain bluepopcorn.net
> KeyFile /etc/mail/dkim/buttered.key.pem
> Selector buttered
>
> MTA MSP-v6,MSP-v4
>
> # 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)
>
> #ATPSDomains example.com
>
> #Accept messages regardless
> On-Default accept

You might try adding:

AlwaysAddARHeader yes

The header might yield some useful information if added.

I'd also double check permissions on both /etc/mail/dkim/buttered.key.pem and
the directories above it. On Debian/Ubuntu, the milter runs as the opendkim
user and it needs to be able to read the key file.

Scott K
Received on Sat Apr 20 2013 - 22:42:35 PST