On Sat, Nov 06, 2010 at 10:04:57AM -0400, Wietse Venema wrote:
> > Due to the DNS lookup latency inherent in incoming DKIM checks, doing
> > DKIM in post-queue content-filters is somewhat unattractive, as typically
> > one wants low-latency, modest concurrency in a post-queue filter.
>
> Another way to avoid post-queue filter DNS latency is to preload
> the DNS cache before the message hits the queue, perhaps with a
> header_checks rule (instead of switching to a before-queue filter).
I also entertained thoughts along these lines, but with smtpd either
doing or explicitly requesting the lookup. This would be the minimal
DKIM footprint for smtpd in front of a DKIM-enabled post-queue filter.
Just prefetch the signing keys for the "d=..." domains, to prevent
content filter pipeline stalls. This works reasonably well, provided
the pre-filter active queue delay is low (which is a reasonable
assumption in most cases).
I understand your reluctance to bolt in not yet particularly
mature RFCs, but doing the full signature evaluation and adding an
Authentication-Result header in smtpd is I think more attractive, and
I am not a milter fan. So for inbound DKIM checks I'm not opposed to
adding the small amount of code necessary to validate message signatures
and insert an Authentication-Result header.
http://tools.ietf.org/html/rfc5451
One can then apply policy in either pre or post queue filters based
on the contents of the header.
Given John Levine's reply to my recent message, should the Postfix
documentation for "rhswl" lookups specifically instruct users to
not use this for the SpamHaus DNSWL, whose domain keys are all
DKIM domains, not PTR domains?
--
Viktor.
