Re: Signing multiple domains via wildcard (fwd)

From: Murray S. Kucherawy <msk_at_blackops.org>
Date: Fri, 28 May 2010 10:24:58 -0700 (PDT)

Kudos to Daniel for suggesting the idea that a Lua script could be invoked
in place of a database. Here's a case I handled offlist where adding that
in v2.1.0 made it possible to do something someone needed that we
currently can't do. What he would otherwise need to do is have a
SigningTable entry and a KeyTable entry for every domain he supports, even
if they all use a single key file and selector name, and those would need
to be updated every time a domain was added or removed.

----- 8< -- snip -- 8< -----

>> Are you trying to use one key file for all domains, each using its own
>> value of "d="?
>
> Yeah, I'm trying to do exactly this. Sign with a single key file and
> use the individual domain name (based on the sender address) as the
> signing domain (d=).

Please open a feature request for this on the SourceForge tracker. It's
something for which we should have direct support. This should be fairly
easy to do for v2.2.0, though that's a few months away. And I imagine
you'd be interested in testing a patch in the interim... :-)

opendkim-genzone won't be able to support this though, as it would need to
know all of the domains that might be signed.

Here's what I think will work until we get something more formal added:

v2.1.0 contains the ability for a Lua script to act as a database. That
is, you can write a Lua script that's invoked in place of a database
lookup, with the key of the lookup passed to you as a variable, and then
your script just returns the result you want to give. Remember that the
first query goes to the SigningTable with the address of the sender, and
it expects the name of a key back, and then that key name is fed as a
query to the KeyTable and it wants back a domain, selector and key data.

So you write two scripts, which will pretend to be those databases. For
the SigningTable script, you receive as the variable "query" the user_at_host
of the sender. Using Lua (you'd have to read how to do this in Lua, but
the language is well-documented online), write a script that tears off the
"user_at_" part and just returns the "host". This will, presumably, be one
of the domains for which you want to sign. opendkim will then pass that
as the query to the KeyTable, which is your second script. It has to
return three values, so you just return the query itself as the first
value (which will become the signing domain), the name of your selector as
the second value, and the path to your signing key as the third value.

The configuration would be:

         KeyTable lua:/path/to/keytable/script
         SigningTable lua:/path/to/signingtable/script

Note that I have not tried this, but it seems like it'll work, and it
makes me enormously glad we added Lua support in v2.0.0. :-)

The reason this should get direct support is that Lua invocation is
reported to be somewhat expensive (though I've not verified this either).
If this is potentialy a popular feature, we should have support for it
that doesn't require a Lua script to implement.
Received on Fri May 28 2010 - 17:25:14 PST