Prev: Posfix Address Rewriting
Next: If a message is destined for a content_filter, must we reallycheck the transport map?
From: Michael Alan Dorman on 11 Mar 2010 14:50 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.
From: Wietse Venema on 11 Mar 2010 14:58
Michael Alan Dorman: > 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. The transport map can reject a recipient at SMTP RCPT TO time, by resolving the recipient to the error(8) or retry(8) transport. The transport map must therefore be searched BEFORE the filter. Wietse |