RE: async resolver

From: Murray S. Kucherawy <msk_at_cloudmark.com>
Date: Tue, 20 Oct 2009 15:03:33 -0700

> -----Original Message-----
> From: opendkim-dev-bounce_at_lists.opendkim.org [mailto:opendkim-dev-
> bounce_at_lists.opendkim.org] On Behalf Of Murray S. Kucherawy
> Sent: Tuesday, October 20, 2009 9:55 AM
> To: Daniel Black; opendkim-dev_at_lists.opendkim.org
> Subject: RE: async resolver
>
> It's hard to tell whether or not that scenario is really something
> about which we should be concerned, though, without more data. The
> only other concern I have is the amount of code that would have to
> change. Not a bad thing, just thinking out loud for planning purposes.

More of that out-loud thinking:

If there's no callback facility in the underlying resolver selected by the administrator, we can't do any of this. That would mean libopendkim has two basic DNS structures, one that can initiate queries and come back to them later and one that has to block at the same time the query is sent because the callback facility isn't available. That's a lot of cpp fun, more than is already there, which makes the code a pain to manage.

Just using the ADSP part: With a callback facility, the ADSP query could be started in dkim_eoh_verify() and then evaluated (which could block) all the way down in dkim_eom_verify(); but without, we would do it in one place or the other and block every time.

For the DKIM part, we could launch the queries in dkim_eoh_verify(), one for each signature seen. If we want to do the body optimization, we have to complete the DNS query and do the verification prior to returning from that function; if we want to risk unnecessary body I/O then dkim_eoh_verify() can return and then in dkim_body() we would check for responses to each of the key queries and run the verifications of them once they've arrived. Then, if all of those verifications fail, we can tell the filter to stop sending us message body because we know it won't be useful. In this case we've wasted some hash cycles and I/O, but it's possible the optimization is an overall gain for an average mail stream. However, without the callbacks, the key retrieval will have to block entirely either in dkim_eoh_verify() or in dkim_eom_verify().
Received on Tue Oct 20 2009 - 22:03:42 PST