On Tue, 3 Jun 2014, Julien PL?E wrote:
> The problem of my specific case comes up since my account manager
> automatically declares a factice domain named ? ALL ?. Consequently this
> domain has no DKIM data and this really troubles OpenDKIM which won?t
> even initialize.
What error does it give you?
Could you add a KeyTable entry matching "ALL" that will make the
SigningTable entry resolve?
> In the past days, I resolved this situation by adding a filter to the DSN :
>
> SigningTabledsn:mysql://<user>:<pswd>_at_<host>/<db>/table=domain?keycol=domain?datacol=dom
> ain?filter='`private_key` NOT LIKE ""'
> KeyTable dsn:mysql://<user>:<pswd>_at_<host>/<db>/table=domain?keycol=domain?datacol=dom
> ain,selector,private_key
>
> This prevented OpenDKIM to prefetch unsupported domains.
>
> Unfortunately, after a system upgrade from Ubuntu 13.10 to 14.04, this
> support has been broken and OpenDKIM (now v2.9.1-1) fails to initiate and run
> again.
>
> In my SQL logs, I can see that ? filter ? is not applied to SigningTable :
> SELECT domain,domain FROM domain
> SELECT domain,selector,private_key FROM domain WHERE domain = 'ALL'
>
> Then I tried to add the same filter sequence to the KeyTable string and this
> shows up in the logs (but this is not where I want it applied?) :
> SELECT domain,domain FROM domain
> SELECT domain,selector,private_key FROM domain WHERE domain = 'ALL' AND
> '`private_key` NOT LIKE ""'
I'd have to see this in action to be able to debug it. As described, it
shouldn't be possible because the KeyTable and SigningTable settings are
processed separately, so it shouldn't ever be the case that one database
uses the other database's filter string.
You might try removing the various quotes, thus:
SigningTable dsn:mysql://<user>:<pswd>_at_<host>/<db>/table=domain?keycol=domain?datacol=domain?filter=private_key NOT LIKE ""
...or possibly:
SigningTable dsn:mysql://<user>:<pswd>_at_<host>/<db>/table=domain?keycol=domain?datacol=domain?filter=private_key <> ''
OpenDKIM's config file parser doesn't treat those quotes in any special
way so they should be copied to the filter verbatim and used when building
a SELECT command.
> I sure could trick the whole think by pretending ALL is a valid domain
> with DKIM data but this is truly ugly.
I think that's actually the simpler solution. Putting an SQL exception in
your DSN to work around what your account system is doing seems like the
less desirable path.
If the above suggestions don't work, please send me your entire (unedited,
please) opendkim.conf file and I'll try to reproduce it. I don't need
your database entries for this.
-MSK
Received on Tue Jun 03 2014 - 18:00:58 PST