On Thu, Mar 11, 2010 at 02:50:49PM -0500, Michael Alan Dorman wrote:
> 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.
SMTP server access control requires that each user be resolvable to an
an address class, transport, nexthop and standard-form email address.
For example, even with content filters, recipients that resolve to the
"error" transport are rejected even if the message may be subject to a
content filter.
The resolving of addresses to an address class and related data is done
by the trivial-rewrite service. The trivial-rewrite service only sees
the address in question.
> 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?
The Postfix internal design is more intricate than your mental model of it.
> 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?
If possible, don't use LDAP for the transport table. And do use
"proxy:ldap:" rather than "ldap:" for virtual_alias_maps, and other
tables that are used by smtpd and cleanup. Maintain a simple (indexed
file) transport table that routes domains, not users.
If you must use LDAP for transport lookups, consult a highly available
low latency LDAP service, a dedicated replica if necessary.
--
Viktor.
P.S. Morgan Stanley is looking for a New York City based, Senior Unix
system/email administrator to architect and sustain our perimeter email
environment. If you are interested, please drop me a note.
