RE: Using KeyTable

From: Murray S. Kucherawy <msk_at_cloudmark.com>
Date: Thu, 20 May 2010 15:05:23 -0700

> -----Original Message-----
> From: opendkim-users-bounce_at_lists.opendkim.org [mailto:opendkim-users-
> bounce_at_lists.opendkim.org] On Behalf Of Todd Lyons
> Sent: Thursday, May 20, 2010 12:06 PM
> To: opendkim-users_at_lists.opendkim.org
> Subject: Using KeyTable
>
> 3. Emails run through mailman do not get signed.
>
> #3 seems obvious at first because the from address could be any of the
> few hundred participants of the list. I'm having trouble wrapping my
> head around what I need to do to make it sign all outbound list email.
> This is what I see in the logs when I send an email myself to the
> list:
>
> May 20 08:20:23 penguin opendkim[4008]: o4KFJava004024 no signing
> domain match for `ivenue.com'
> May 20 08:20:23 penguin opendkim[4008]: o4KFJava004024 no signing
> subdomain match for `ivenue.com'
> May 20 08:20:23 penguin opendkim[4008]: o4KFJava004024: no signature
> data

The filter will only sign for domains for which it is configured to sign. The determination of a message's domain for this decision comes from the SenderHeaders setting, which by default includes only "From". So mail that comes via an MLM that doesn't change From: will contain the original sender's address, which probably doesn't match your domains-to-sign list.

You have a couple of choices here:

1) Sign for all domains using "Domain *". Depending on what other work your mail server does, you may not want to do this.

2) If your MLM adds a particular header to identify the list (e.g. Resent-Sender or Resent-From), add that one earlier than From in your SenderHeaders list (e.g. "SenderHeaders Resent-Sender,From"). This has a possibly annoying side-effect though, in that ADSP evaluation, if you have that enabled, will also be done based on that setting. This is probably a bug we'll need to fix in some future version.

> My gut reaction is that the only thing I can do to make this work
> right is to export all of the subscribers into a text file and
> generate a KeyTable from it.

You could do that but it's almost certainly not necessary.

> The KeyTable configuration appears to be
> a little more complex than it was on dkim-milter.

Definitely, but it's far more flexible.

> I have a multi
> domain dkim signing process working on a server running dkim-milter,
> but on this server I cannot get opendkim to start if I uncomment the
> KeyTable line. It blurts out:
>
> # /etc/init.d/opendkim restart
> Stopping OpenDKIM Milter: opendkim [ OK ]
> Starting OpenDKIM Milter: opendkim: /usr/local/etc/opendkim.conf: at
> least one selector and key required for signing mode
> opendkim [FAILED]

This should only happen if you have not defined a KeyTable, and either or both of Selector and Domain are not set.

> Comment the line and it starts right up. Here is the keylist file:
> *_at_oclug.org:key1:/usr/local/etc/dkim/key1.private
> *_at_penguin.oclug.org:key1:/usr/local/etc/dkim/key1.private
> *_at_mailman.oclug.org:key1:/usr/local/etc/dkim/key1.private

"KeyList" was removed in v2.0.0. The new mechanism to do that is a mixture of SigningTable and KeyTable. The format for KeyTable is not the same as it was for KeyList. A conversion script is available in the "contrib" directory if you want to give that a try.

Basically, the KeyTable is a list of keys, which are tuples consisting of {key file, selector, domain}. The SigningTable maps senders to the KeyTable entries they should use.

> ...and setting the MTA setting to "MSA" just provided opendkim with
> one more setting to choose not to sign the email:
> May 20 08:12:39 penguin opendkim[3789]: o4KFCSdf003924 no MTA name
> match

You shouldn't need that. As long as you satisfy the domain match requirement (see above) and the connection comes from an internal source such as localhost, it should sign. What you're seeing is an acknowledgement that you set the MTA option, but the MTA names you listed didn't include the one that job used.
Received on Thu May 20 2010 - 22:05:32 PST