DKIM keys stored in sql?

[Mark Martinec via amavis-users]

Tom,

> We would like to provide DKIM signing for a large number of customer
> domains (many thousand) - loading them from the conf file isn't very
> practical.  We prefer to load them from a sql table.
> 
> We are currently using opendkim for this purpose, but would prefer to
> consolidate this into amavisd-new.
> 
> Is there some way to do this in amavisd- new that I am missing? Or is
> it a planned feature ?

Currently I don't have a satisfying answer to this question.
There are some tools in place, but some customization is still needed.

The main reason why amavisd does not take private signing keys from
an SQL or LDAP database is privilege separation. An application
(amavisd) that is regularly processing untrusty information should
better not have a direct access to secret information (signing keys),
if at all it can be avoided.

For this reason amavisd supports a protocol to talk with an external
application: amavisd would compute a message digest, send it over
to this dedicated application, receive back the signed digest,
and insert it in a DKIM signature of a mail message.

There is currently a demo signer included in the amavis package,
it is called amavisd-signer. In its present form is implements
the same logic with the same source of private keys as the
amavisd itself. One could take this demo signer, keep the
protocol handling and DKIM signing code that it implements, and
add any suitable remaining code to collect public keys from
a suitable source.

There are actually two independent functions that the signer process
implements:

- based on the given information from the mail header (From, Sender)
   it must decide which d (domain) and i (identity) to use for signing
   (if signing at all). The d and i tags thus chosen then uniquely
   identify the signing key;

- given the d and i tags (chosen in a previous step or in some other
   way), pick a private signing key and sign the provided message digest
   with it, returning the item that amavisd will then insert into a
   DKIM signature.

The first step (choosing a signing key) can even be implemented by
amavisd itself, as it does not involve any secret information. Search
for 'q_sql_s' in release notes and see the example there involving
the @dkim_signature_options_bysender_maps setting. So the choosing
of d and i tags can already come from an SQL or LDAP database, or be
delegated to the signer program.

For the second step (the actual signing), I'm afraid that currently
you will need to adapt the amavisd-signer program to your needs.

Search for:
   'a new program is included with a package: amavisd-signer'
in release notes. It is documented there.

   Mark