RE: smtpd ldap query causes session to hang with postfix 2.6.2

From: Charles Account (no email)
Date: Mon May 03 2010 - 12:05:32 EDT

  • Next message: Trier, James: "Postfix inbound message configuration"

    > Date: Fri, 30 Apr 2010 01:04:41 -0400
    > From:
    > To:
    > Subject: Re: smtpd ldap query causes session to hang with postfix 2.6.2
    >
    > On Thu, Apr 29, 2010 at 01:53:37PM +0000, Charles Account wrote:
    >
    >> We have a situation where LDAP query is resulting in a LDAP 80 level
    >> errorduring a domain lookup. Yes I understand we need to fix this problem.
    >
    > I've mentioned a number of times on this list that it is unwise to
    > make the trivial-rewrite service dependent on LDAP or other services
    > that may not always be reliable.
    >
    > Postfix cannot continue to function when
    >
    > address -> (transport, nexthop, normalized-address)
    >
    > lookups fail, there is no sensible recovery path. The lookups must
    > loop until the transport table works again.
    >
    > DO NOT use potentially unreliable LDAP sources for the following tables:
    >
    > - transport_maps
    > - mydestination
    > - relay_domains
    > - virtual_mailbox_domains
    > - virtual_alias_domains
    > - relocated_maps
    > - sender_dependent_relayhost_maps
    > - sender_dependent_default_transport_maps
    >
    >> However, the side effect we see is the client's SMTP session hangs.
    >> Over a period of time all SMTPD sessions are consumed and no mail is
    >> processed.The only solution was to stop postfix and restart to free up
    >> the processes.
    >
    > No mail can be processed anyway, as the queue manager is completely
    > unable to function when transport resolution is down.
    >
    >> I have looked for a patch but I have not found one. Does one exist?
    >
    > No patch exists, as this is not a bug. Transport lookups MUST work.
    > If LDAP is not reliable, don't use LDAP.
    >
    > --
    > Viktor.

    Viktor,
    Thanks for the response. Our LDAP service front ends a distributed cache based directory service. This means that there are failure scenarios whereby some small number of directory entries are unavailable while the majority of the directory is still available.

    I noticed in my testing, where an LDAP front end server is brought down on purpose, the connection
    service returns a RESOLVE_FLAG_FAIL and the client MTA returns a 451 error code (Temporary lookup failure).
    We cannot always guarantee a specific directory entry will be available, therefore, we coded our LDAP interface to
    return the appropriate LDAP level error code. Having resolve_clnt_addr() retry several time before giving up
    seems to be an appropriate behavior, thereby allowing the entire complex to continue to handle mail.
    I've included a patch based on 2.6.2 release as a suggested solution. Feed back is always welcome.
    Charles
    _________________________________________________________________
    Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox.
    http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1




  • Next message: Trier, James: "Postfix inbound message configuration"





    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs



    Powered By FreeBSD   Powered By FreeBSD