On Sun, May 23, 2010 at 4:58 PM, Todd Lyons <tlyons_at_ivenue.com> wrote:
>
> > 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.
>
> not verify. I disabled that and then configured the SenderHeaders
> function, and it works, kind of. Again, it signs the emails that are
> processed through the MLM, but for some reason, the signature is
> failing. So far I have only seen it sign rejection notices to us
> admins, which seems to sign the email, then pass it through mailman
> once more as it sends out to us admins. Obviously something is
> getting changed, I just am not sure what that is. As always, locally
I figured it out...
> As part of testing the ResignMailTo, I excluded the Subject field from
> tests because we modify the subject by prepending the list name
> [OCLUG] in front of the subject. It did not help the emails to dkim
> verify.
>
> I am going to set up a test list with only a couple of email addresses
> and see what happens.
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.
My final config:
# egrep '^[^#]' /etc/opendkim.conf
Canonicalization relaxed/simple
Domain oclug.org
InternalHosts /usr/local/etc/dkim/local-ips
KeyFile /usr/local/etc/dkim/key1.private
LogWhy yes
Mode sv
OmitHeaders Sender
PidFile /var/run/opendkim/opendkim.pid
RemoveARAll No
RemoveOldSignatures No
ReportAddress oclug-owner_at_oclug.org
Selector key1
SenderHeaders Sender,From
Socket inet:49999_at_localhost
SubDomains Yes
Syslog Yes
X-Header Yes
In summary, I needed two things to make it work right:
1. SenderHeaders - to give opendkim another header that would contain
a local email address to apply the "should I sign" logic to my list
generated emails.
2. OmitHeaders - to skip the one header which was causing me much grief.
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
3. If you define KeyTable but not SigningTable, it just won't start.
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.
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.
Thanks for all the help guys, some of this might make a good FAQ item
WRT mailing lists.
--
Regards... Todd
I seek the truth...it is only persistence in self-delusion and
ignorance that does harm. -- Marcus Aurealius
Received on Mon May 24 2010 - 02:15:51 PST