Hey, all, I manage a high-volume mail installation, using an after-queue content filter for spam filtering.
We use an ldap transport map (actually a couple of them) to direct each recipient's email to it's appropriate final destination. I recently got some errors about timeouts in the transport map lookup, which seemed weird, since we're really not delivering all that much mail---95%+ of the stuff that comes in goes into the filter and never comes back out. I was startled (make fun of me if you wish :) when I realized that each accepted message is causing a lookup on the transport_map, *even though* the system knows it's just going to send them to the after-queue content filter. This seems counter-intuitive to me: if the nexthop (content_filter) for that message has already been determined for all practical purposes, why bother to consult the transport map? I looked around for a way to turn off transport map consultation just for the externally-facing smtpd instances, but since it happens in the trivial-rewrite stage, that seems a non-starter, though I might have missed something. So, is there any way, short of running multiple instances---the solution I will undertake should no one have other suggestions---that I can have my transport map ignored for emails destined for the after-queue content filter? Many thanks, Mike.
