Re: How is LDAP used with OpenDKIM?

From: Sistemisti Posta <>
Date: Wed, 15 Jun 2016 16:09:10 +0200

Il 05/01/2016 21:43, Patrick Ben Koetter wrote:
> It queries a database via LDAP to find out if it should apply a DKIM
> signature. If it should, it searches the database via LDAP for the DKIM
> key(s).

Hello OpenDKIM users,

  I would ask some hints on OpenDKIM LDAP setup in multidomain environment.

Let suppose a provider is a maintainer of many domains.
For each domain the customer is not interested on DKIM setup, which is
totally automagically done.

To achieve this, first I modified the LDAP schema: I don't know why
DKIMKey is mandatory. Since query for SigningTable and KeyTable are
separated, I would have many Identities (AUIDs) for a single key. So in
schema I modified DKIMKey to "MAY" in place of "MUST".

I have two category of MSA sending mails, so I think to use separate
keys for each MSA. Every domain use separate keys too. Finally I have
selectors like these:

(<msa1>-<timetag>; --> privkey1
(<msa1>-<timetag>; --> privkey2
(<msa2>-<timetag>; --> privkey3
(<msa2>-<timetag>; --> privkey4

I also though to keep a single key for all domains and MSAs.
Is it advisable? Such as:

(<msa1>-<timetag>; --> privkey1
(<msa1>-<timetag>; --> privkey1
(<msa2>-<timetag>; --> privkey1
(<msa2>-<timetag>; --> privkey1

I suspect the first choice is at least preferred, for various reasons
(to keep auth separated and for security reasons). But if I well
understood the standard doesn't say that every domain must have a
distinct key.

Second question is about the above <timetag>. The keys should expire,
anyway it is suggested to change the keys periodically.
Is there a best practice about how long a pair of key should live?

I think to keep old public key for few days after rotation, only to deal
with deferred mails. But I could keep the old key for a living period to
be sure. Do you have any hints about public key retention?

I very appreciate any consideration on this kind of setup.
Thank you very much
Best Regards
Received on Wed Jun 15 2016 - 14:09:31 PST

This archive was generated by hypermail 2.3.0 : Wed Jun 15 2016 - 14:18:00 PST