• Article for your preferred language does not exist. Below is international version of the article.

Article ID: 113676, created on Apr 12, 2012, last review on Feb 20, 2015

  • Applies to:
  • Operations Automation 5.x

Symptoms

qmail bounces email sent to the existing mailbox mail@customer.com with the error message "user's homedir not found":
Hi. This is the qmail-send program at mail.provider.com.
I am afraid I was not able to deliver your message to the following addresses.
This is a permanent error; I have given up. Sorry it did not work out.
<mail@customer.com>: user's homedir not found

In the /var/log/maillog folder on the qmail MTA server, the following error message may be found:
Apr  12 22:52:28 mta1 splogger: 1333399948.387424 status: local 1/10 remote 0/120
Apr 12 22:52:28 mta1 qmail-lspawn: LDAPWARN: searchEmailInLDAP_: didn't find email mail@customer.com by filter '(&(objectclass=mailname)(|(mailname=mail@customer.com)(mailalias=mail@customer.com)(mailalias=mail@customer.com))(!(homedir=#)))': exit code -1
Apr  12 22:52:28 mta1 qmail-lspawn: LDAPWARN: searchEmailInLDAP_: didn't find email CATCH-ALL@customer.com by filter '(&(objectclass=mailname)(|(mailname=CATCH-ALL@customer.com)(mailalias=CATCH-ALL@costomer.com)(mailalias=CATCH-ALL@customer.com))(!(homedir=#)))': exit code -1
Apr  12 22:52:28 mta1 qmail-lspawn: LDAPWARN: lookupEmailInLDAP: email 'mail@customer.com' wasn't found and searchEmailInLDAP_(catchall=CATCH-ALL@customer.com) returns No such object
Apr  12 22:52:28 mta1 splogger: 1333399948.388056 delivery 82194: failure: user's_homedir_not_found/


At the first glance, it looks like the customer's email is absent from the LDAP database.

However, the entry for the problem mailbox exists in the LDAP database and appears to be correct:

dn: mailname=mail@customer.com,ou=mail,dc=pem,dc=swsoft,dc=com
objectClass: mailname
mailname: mail@customer.com
homedir: /usr/local/qmail/shared/mailnames/eb/l/-66/66/
login: mail@customer.com
password: $1$ZY9iRsUN$I/8EvvI1jL3neycEbZeYU0
passwordType: encrypted
servedBy: mail.provider.com
throttlingPerDay: 100000
throttlingPerHour: 10000
throttlingPerMinute: 1000
trafficConsumerID: 3
trafficConsumerTypeID: 0
trafficRTIID: 1594
structuralObjectClass: mailname
entryUUID: d2d94ebe-180c-1031-8d2c-dfdd00878152
creatorsName: cn=admin,dc=pem,dc=swsoft,dc=com
createTimestamp: 20120411102828Z
entryCSN: 20120411102828Z#000000#00#000000
modifiersName: cn=admin,dc=pem,dc=swsoft,dc=com
modifyTimestamp: 20120411102828Z



The homedir of the /usr/local/qmail/shared/mailnames/eb/l/-66/66/ mailbox exists; permissions on file system are correct; the NFS server is available; and the NFS share /usr/local/qmail/shared is mounted on all MTA servers in the qmail cluster.

Network monitoring tools do not show any packet loss on any servers in the qmail cluster, including the MTA, LDAP, WHOSON, and NFS servers. Routing is configured correctly as well, and all hosts are available to each other.

The problem is intermittent. It is not reproduced on a permanent basis; some emails may be delivered correctly to the mailbox, and then some emails may be bounced. The problem appears randomly and may affect different mailboxes hosted in the POA-managed qmail cluster.

Cause

A possible reason for the problem is an incorrectly configured LDAP server. It may close the established connection between qmail and the LDAP server after an idle timeout, while qmail still thinks that the connection is established and is trying to send the request to the LDAP server (to the closed connection). As a result, qmail does not get any reply from the LDAP server because the connection is already closed on the LDAP server side and incorrectly treats this situation as an attempt to send email to a nonexistent mailbox, bouncing the mail message.

The reason for the problem in this case is the idletimeout parameter in the LDAP server configuration file; its value is set to low, and as a result, the LDAP server closes the connection too early.

The full picture of the problem is demonstrated in the two screenshots below, which show the packets between qmail and LDAP servers captured by tcpdump and processed by WireShark.

Good situation:


The sequence of actions in the "good" case is as follows:
  1. qmail server 10.184.18.6 sends a bindRequest request to LDAP server 10.184.19.23 (packets #18, #19)
  2. LDAP server accepts the connection (packets #20, #21) 
  3. qmail server performs search requests (packets #22, #23, #24, #25)
  4. qmail sends an unbindRequest request to the LDAP server to close the connection (packets #26, #27)
  5. Finally, the LDAP server closes the connection correctly (packets #28, #29)

Bad situation:


The sequence of actions in the "bad" case is as follows:
  1. qmail server 10.184.18.6 sends a bindRequest request to LDAP server 10.184.19.23 to open the connection (packets #23194, #23195)
  2. LDAP server accepts the connection (packets 23196, #23197)
  3. qmail server performs search requests in LDAP database; they are successful (packets #23198-23515)
  4. After qmail performs the needed searches in the LDAP database, it keeps the connection open and does not send any requests for a certain period of time (because there is no need to ask the LDAP database)
  5. LDAP server closes the connection from its side after idle timeout (packet #24033)
  6. qmail server receives new incoming email and tries to send one more request to the LDAP database and to the existing connection (packets #24034, #24658, #24659)
  7. The last request from the qmail server to the LDAP server fails because the LDAP server already closed the connection from its side due to inactivity and idle timeout (packets #24660, #24661)
  8. qmail bounces incoming email message because attempt to find mailbox in LDAP database failed

Resolution


Set the parameter idletimeout in the LDAP server configuration file /etc/openldap/slapd.conf to 0 and restart LDAP service.

From man-page on slapd.conf:
idletimeout <integer>
              Specify the number of seconds to wait before forcibly closing an idle client connection.
              A idletimeout of 0 disables this feature.  The default is 0.

5356b422f65bdad1c3e9edca5d74a1ae 2554725ed606193dd9bbce21365bed4e caea8340e2d186a540518d08602aa065 e12cea1d47a3125d335d68e6d4e15e07

Email subscription for changes to this article
Save as PDF