- Previous message: Gary Smith: "RE: mynetworks hash tables"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
|
|
|
From: Charles Account (no email)
Date: Mon May 03 2010 - 12:05:32 EDT
> 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
|
|
|