Re: opendkim 2.1.3 and signing subdomains

From: Murray S. Kucherawy <msk_at_blackops.org>
Date: Thu, 26 Aug 2010 23:08:22 -0700 (PDT)

On Thu, 26 Aug 2010, Richard Rognlie wrote:
> using SigningTable and KeyTable, I've got opendkim 2.1.3
> happily signing subdomains.
>
> /etc/mail/siglist.txt
> =====================
> *_at_gamerz.net testdkim
> *_at_*.gamerz.net testdkim
>
> /etc/mail/keylist.txt
> =====================
> testdkim gamerz.net:testdkim:/etc/mail/dkim-keys/testdkim.private
>
> However, if I have the selector in question set up to declare
> that it is not valid for signing subdomains... it still signs
> them.

The filter doesn't verify that you're using your keys the way you've
restricted them, so that's normal.

> And those signatures happily verify

That part's a bit odd. What software is doing the verifying?

> Now, I know I could fix part of this (suppress the signing of the
> domain) by removing that 2nd line from the siglist.txt.
>
> But why is the signature validating at all?

Good question. We do have a unit test for this case and it passed at the
time of release (libopendkim/tests/t-test82), so I presume this is a bug
at the verifier.

> I note that there is no "i=" clause in the signature, and looking at
> the opendkim code, I see that the t=s check is done by comparing the
> d= and the i=. If either is NULL, it skips the check.

"d=" can't be NULL, but the absence of "i=" does mean the check gets
skipped because a missing "i=" has an inferred default value of
"_at_<domain>" where "<domain>" is the "d=" value.

> Shouldn't i= default to the sender domain if missing from the dkim-signature?

That would mean we're enforcing a default that's not present in the RFC.
Absent a reason for making tha tassertion, I don't think we should do so.

> I see mention of something in SignatureTable about the i= clause, but
> for the life of my I can't parse what it's saying, nor can I find an
> example anywhere...
>
> values in this data set should include one field that refers
> to a name found in the KeyTable (see above) that identifies
> which key should be used in generating the signature, and an
> optional second field naming the signer of the message that will
> be included in the "i=" tag in the generated signature.

So the SignatureTable might look like:

         *_at_gamerz.net testdkim:opendkim_at_gamerz.net

...and you'd always have "i=opendkim_at_gamerz.net" in your signatures.

> I've tried
>
> *_at_*.gamerz.net testdkim:%
>
> (hoping that the % would exhibit the same behaviour as mentioned in KeyTable)

That's not currently supported, but why would you want to do this when
it's the default anyway?

> but 1. I didn't get an i= flag at all, and
> 2. on inspection of the code, I can't find anything that appears to
> parse the key returned from the signature table for post processing.
>
> Or is there some option I'm not including in either the opendkim.conf or
> SignatureTable or KeyTable to turn that on?

The feature isn't actually available in 2.1.3. It's available in 2.2.0.
What documentation are you reading?

-MSK
Received on Fri Aug 27 2010 - 06:08:45 PST