Philip,
Thanks for the reply, here are the transport and director I use (if you
need the entire config file, let me know and I will send it off list)...
vmail_ldap:
driver = accept
condition = ${lookup ldap {user="****" pass=****
ldap://localhost:389/dc=uc,dc=com?mail?sub?(mail=${local_part}@${domain})}{es}{no}}
retry_use_local_part
transport = vmail_delivery
transport_home_directory = ${lookup ldap {user="****" pass=****
ldap://localhost:389/dc=uc,dc=com?homeDirectory?sub?(mail=${local_part}@${domain})}{${value}/Maildir}fail}
vmail_delivery:
driver = appendfile
check_string = ""
create_directory
current_directory = /
directory = ${home}
directory_mode = 0700
envelope_to_add
group = vmail
maildir_format
maildir_tag = ,S=$message_size
message_prefix = ""
message_suffix = ""
quota = "${lookup ldap {user=**** pass=****
ldap://localhost:389/dc=uc,dc=com?quota?sub?(mail=${local_part}@${domain})}{${value}}fail}"
quota_size_regex = S=(\d+)$
quota_warn_threshold = 80%
return_path_add
user = vmail
The change works for me, but I appreciate that it might be more luck
then judgment in this case!
Jason
On Thu, 2002-03-21 at 16:36, Philip Hazel wrote:
> On 20 Mar 2002, Jason Stratford wrote:
>
> > The problem is that when sending a message to one user that is CC'd to
> > another in the same domain, the first message gets delivered, but the
> > second one is deferred due to a failed LDAP lookup during the delivery
> > phase.
>
> Could you send me the configuration of your transport, please?
>
> > I have tracked this down to the search_tidyup() function being called at
> > the end of the delivery fork code, which appears to be clearing the
> > connection to the LDAP before the second delivery has finished using it,
> > but _after_ the second delivery has determined that it is using a pooled
> > connection. Result, second delivery goes bang.
>
> It isn't quite like that, but I can see where there might be a problem,
> which is why I'd like to see your transport.
>
> > The following patch appears to fix this problem, but I do not have
> > enough working knowledge of the code yet to know if this breaks
> > anything, or introduces leaks.
>
> It isn't right, because it leaves open any connections that the
> transport establishes in the subprocess. (This may not be the case in
> your configuration, but it is in some.)
>
> I think the fix might be to call search_tidyup() just before the fork(),
> but I want to be sure (by looking at your transport) before recommending
> that you try that.
>
> Philip
>
> --
> Philip Hazel University of Cambridge Computing Service,
> ph10@??? Cambridge, England. Phone: +44 1223 334714.
>
