|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Ian Macdonald (postfix-users
linuxcare.com)Date: Wed Apr 25 2001 - 13:58:41 CDT
Hi,
I migrated our production e-mail system over to postfix 20010228pl01
last week and am generally very happy with the performance of the
system.
However, there are a couple of annoying problems that I'm seeing,
namely the delivery of duplicate e-mails and the frequent failure of
LDAP look-ups.
Now, all of our local delivery occurs by querying an OpenLDAP 2.0.7
server. The mail system is running its own slave instance for the
purpose of redundancy.
The LDAP configuration section of main.cf looks like this:
alias_ldap_server_host = localhost ldap1sj.linuxcare.com ldap.i.linuxcare.com
alias_ldap_server_port = 389
alias_ldap_search_base = ou=people, dc=linuxcare, dc=com
alias_ldap_timeout = 60
alias_ldap_query_filter = (|(mailAlias=%s)(mailGroup=%s)(uid=%s))
alias_ldap_result_attribute = uid
alias_ldap_bind = no
alias_ldap_cache = yes
alias_ldap_cache_expiry = 900
alias_ldap_cache_size = 1048576
and the relevant section of the person's LDAP entry might resemble
something like this:
uid: ianmacd
mailAlias: ian
mailAlias: ian_macdonald
mailAlias: imacdonald
mailGroup: sysadmins
mailGroup: allhands
mailGroup: mis
Now, if a message is to be delivered to ianmacd (the uid) or ian (a
mailAlias), the delivery goes fine. The uid and mailAlias is
guaranteed to be unique across the LDAP directory.
However, if the message is destined for a mailGroup such as mis or
allhands (which attributes feature, by definition, in multiple
persons' LDAP entries), duplicate delivery to each person seems to
occur in some instances.
For example, there are about 10 people with 'mailGroup: mis' in their
LDAP entry. If I send an e-mail to mis
linuxcare.com, sometimes up to
three or four copies (with an identical Message-ID) are received by
those people.
If sending to allhands -- to which every single employee is
subscribed) -- the effects are worse, with nine or ten duplicates
being received by everyone in the company.
I wonder if this is somehow related to an error I am seeing with
disturbing frequency in the log:
Apr 25 11:38:26 mail postfix/local[3199]: warning: dict_ldap_lookup: Search error 81: Can't contact LDAP server
Apr 25 11:38:26 mail postfix/local[3199]: 02FAF27CE71: to=<mbixby
linuxcare.com>, relay=local, delay=0, status=deferred (alias database unavailable)
I have no idea why the LDAP look-up often runs aground like this. At
the very least, it results in the slower delivery of mail.
Tests have revealed that the LDAP look-up fails instantly, not after a
time-out.
The LDAP slave on the mail server is serving no other clients, and I
have raised the number of threads that OpenLDAP is providing to 64,
but to no avail.
This box is running Linux 2.4.3, and I have taken the step of
increasing the number of available file handles to 16384, but that
doesn't seem to help either.
Does anyone have an inkling of what is happening here?
Ian
--
Ian Macdonald | Feeling amorous, she looked under the
Senior System Administrator | sheets and cried, "Oh, no, it's Microsoft!"
Linuxcare, Inc. |
Support for the Revolution |
|
-
To unsubscribe, send mail to majordomo
postfix.org with content
(not subject): unsubscribe postfix-users
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]