> -----Original Message-----
> From: opendkim-users-bounce_at_lists.opendkim.org [mailto:opendkim-users-
> bounce_at_lists.opendkim.org] On Behalf Of Todd Lyons
> Sent: Sunday, May 23, 2010 7:16 PM
> Cc: opendkim-users_at_lists.opendkim.org
> Subject: Re: Using KeyTable
>
> I set up a test list. The first thing I did was look at the headers
> being signed and then omitted almost all of the headers except for
> From, To, Message-Id and one other I can't recall. The DKIM signature
> passed! Yay! I kept dropping one header at a time off the OmitHeader
> list and I resent many messages until I finally isolated which header
> was causing the dkim signature to fail: the Sender header. By
> omitting the Sender header from being used as part of the hash, dkim
> signatures on emails that go through the mailing list now pass.
> Again...Yay!
>
> So _something_ is changing that Sender header after the signature is
> generated. I have not been able to isolate where the change is
> occurring, but I didn't really do much beyond getting it to work.
> Since it works, I'm done with it for now.
Good sleuth work. It would be interesting to know which piece of software is making that change, especially post-signing. This would be useful for our README.
> Also, SM asked if the description for SigningTable wasn't clear. I
> have to say that it was not clear, but that is partly because my
> understanding of the KeyTable was muddled from prior experience with
> dkim-milter. An email from the archive didn't help, it made it worse.
> SM's description definitely cleared up my misunderstanding. It
> wasn't clear to me that:
>
> 1. KeyTable - the key/value pair consisted of a key, such as "example"
> or "example.com", and that the value was
> "domain:selector:private_key_or_private_key_file", as in:
> example example.com:key1:/path/to/key1.private
> 2. SigningTable - ties email senders to entries in the KeyTable (the
> not-clear part is that in the description, the word "key" sometimes
> means the key part of the key/value pair, and in other places means
> the signing key). The final format that resulted in the daemon not
> puking was:
> *_at_example.com example
> *_at_mailman.example.com example
> etc
Right, that is indeed how it works and what the documentation tries to get across. Having seen someone struggling with that in a chat room (was that you?), I wrote up a segment of our installation guide that contains an example of this which will appear in 2.1.0. If you'd like a preview to provide feedback about whether or not it's better, visit:
http://www.opendkim.org/INSTALL
Toward the end there's a new section called "COMPLEX SIGNING CONFIGURATIONS".
> 3. If you define KeyTable but not SigningTable, it just won't start.
That's intentional.
> A more explicit description of the format of the key and values for
> both the KeyTable and SigningTable would probably solve future
> questions for new users like myself.
Well the format can change. The right side of the KeyTable, which actually contains three fields, is only colon-separated for text files, regex files and DBs. If it's LDAP or SQL, they come from different fields.
The description for each type of supported database method is described in the opendkim(8) man page under DATA SETS. Then you apply whichever one you're using to generate the KeyTable, which is expected to be a multi-value database.
> I also wanted to point out that the ResignAll and ResignEmailsTo are
> mentioned in the opendkim.conf manpage, but are not in the
> opendkim.conf.sample configuration file.
Ah, thanks. I'll add those for 2.1.0.
> Thanks for all the help guys, some of this might make a good FAQ item
> WRT mailing lists.
I absolutely agree. And it's also useful for consideration in some DKIM working group work that's being done right now with respect to re-signing list traffic.
Thanks for providing us with your experiences!
-MSK
Received on Mon May 24 2010 - 05:21:08 PST