On Fri, 5 Feb 2010, SM wrote:
>> What I have ended up doing is loading the entire KeyTable into memory so it
>> can be searched quickly and cheaply and private keys don't need to be
>> re-read repeatedly. The SignTable though will be queried for each message.
>
> I would have done the same or else implemented some caching mechanism.
> A DB should be able to do 2000 queries per second. Let's assume that
> the system is not optimized. We should at least be able to do 200
> queries per second (read operations). What's the maximum number of
> messages we can sign? if it is below the number of reads, we don't need
> a cache.
On second thought we can't do this because then adding a new signing key
means a reload or a restart, something we specifically wanted to avoid.
We'll have to read the keys on the fly.
> As we are ordering the results, we will get the domain's private key
> before the catch-all in our results. We can have more than one result.
> The first one should be the narrowest match. The second one, if
> present, will be the catch-all private key. I'll need to test the
> example to expand that to include user_at_host. If the database supports
> stored procedures, we can do the sorting for the more complex case where
> we have hostname, domain name, etc. If we don't hardwire the logic in
> OpenDKIM, a wider range of cases can be supported.
We'd need to come up with similar logic for cases like LDAP and BDB where
that level of control is not necessarily possible.
> So we should avoid signing with the same selector/domain more than once.
> We already know that the data may not be valid if there is more than one
> match. The selector/domain is used as a composite index in a SQL DB.
> The LDAP case is be different.
To stick to our goal though, those differences need to be hidden from the
user.
Received on Sat Feb 06 2010 - 05:53:01 PST
This archive was generated by hypermail 2.3.0
: Mon Oct 29 2012 - 23:32:52 PST